←back to thread

167 points sunshine-o | 1 comments | | HN request time: 0s | source
Show context
exceptione ◴[] No.43572744[source]
The list of dropped components is quite large. The cryptsetup, cryptenroll, unified kernel images, kernel signing and systemd-boot work nicely together.

I think Systemd has a view that those things should reliably work together. I do not fancy a revival of the past where the user has to cobble a mesh of hopefully compatible libraries to achieve the same, taking weeks to study the Arch manual and resolving tons of gotcha's, all to be broken by next week's update.

The integration of all this stuff is now actively under test and maintenance with systemd.

And yes, the mentioned services also have an impact on the scope of service managing. Because if you have a unit that depends on a disk that needs to be unencrypted, this has to be resolved somehow in the right time.

I personally have had no need for systemd-resolved, but I think for *desktop* the list of droppable components is not large.

So maybe we should first have a conversation about the *desktop* vs *container-os* purpose?

replies(5): >>43573274 #>>43573308 #>>43573459 #>>43575409 #>>43576185 #
DrillShopper ◴[] No.43573459[source]
> The cryptsetup, cryptenroll, unified kernel images, kernel signing and systemd-boot work nicely together.

This has not been my experience across Debian and Arch

replies(3): >>43573589 #>>43574196 #>>43578459 #
donnachangstein ◴[] No.43574196[source]
That's because Debian 'stable' has a half-assed implementation of systemd, frozen in time on some ancient version. So you are stuck waiting years between upgrades. Bookworm finally supports the crypto functions.

Arch OTOH was where these functions first worked out of the box.

replies(1): >>43574966 #
bogantech ◴[] No.43574966{3}[source]
> frozen in time on some ancient version.

Yeah that's a feature of Debian stable

replies(2): >>43575746 #>>43581058 #
1. Vilian ◴[] No.43581058{4}[source]
A broken implementation?