15 ms·

Systemd 248

126 points by marcodiego 6y ago

deleted 6y ago
[deleted]
uncledave 6y ago
I can’t wait to have to debug that in production.
- mariusor 6y ago
  And by "that" you mean which, exactly, of the 77 bullet points in the release notes?
  - megous 6y ago
    That's hard to say upfront. Last time it was systemd-homed randomly blocking ssh access to remote systems where it was not even configured to be used, other than distro sticking its pam module to default pam config. What will be the killer future this time is yet to be seen.
    - kaba0 6y ago
      It sounds like either your distro f*cked up here, or you didn’t read the update notes, not sure what does it have to do with systemd..
      - megous 6y ago
        Why a disabled feature that should just do nothing even if its pam module is loaded, infinitely loops on D-BUS access in its pam module? Anyway, I reported it and it presumably got fixed. I wouldn't know, because systemd dev handling this didn't say a thing to me at all. Just closed the report after some seemingly not very related commits to what I saw in gdb. I just dropped the pam module from config anyway, and I'm not willing to lose access to my cluster again just to try. Not sure how distro fucked up in this case, when it's homed pam module going into infinite loop once in a while unpredictably blocking all processes that use pam naively, unless you mean that they fucked up by using systemd or pam at all. Edit: lol, I read through systemd release notes and there's no mention of new huge systemd-homed pam module at all. But good I looked, they're moving pam config for systemd to /usr/lib/pam.d and systemd-home pam module is again enabled there. So I'll have to check again all my systems if it's really disabled after upgrade.
    - tyingq 6y ago
      My last systemd mystery was nohup, tmux, etc, not being able to leave a process running. "Working as designed", sure, but it took a while for me to suspect systemd was involved and figure it out. Is there a document somewhere that shows what the systemd team thinks is a functional boundary? What things they don't plan on replacing?
      - uncledave 6y ago
        systemd is god now and he’s not benevolent. More lord cthulhu.
      - megous 6y ago
        Yes https://github.com/systemd/systemd/blob/main/TODO https://github.com/systemd/systemd/blob/main/TODO
Arnavion 6y ago
`ExtensionImages` (second bullet point) seems it would be essentially the same as having a regular Portable Service [1]. I get they needed the field for the system-level sysext service, so they just made it available to every other unit too. But is there any reason to use `ExtensionImages` instead of making a Portable Service? Edit: I guess if you have multiple services from multiple vendors that nevertheless agree to some common base image, it makes sense for those services to use `ExtensionImages`. Eg multiple services that all require a libglib base image. A Portable Service can expose multiple services from a single disk image, but that's the point - the vendors have to build a single disk image with their services. [1]: https://github.com/systemd/systemd/blob/main/docs/PORTABLE_SERVICES.md https://github.com/systemd/systemd/blob/main/docs/PORTABLE_S...
ohazi 6y ago
Is the use case desktops / servers, or embedded systems? There's a lot of crypto / secure boot stuff in there that looks complicated, but could be pretty neat if it works...
- rezonant 6y ago
  "The primary use case for system images are immutable environments where debugging and development tools shall optionally be made available, but not included in the immutable base OS image itself (e.g. strace and gdb shall be an optionally installable addition in order to make debugging/development easier). System extension images should not be misunderstood as a generic software packaging framework, as no dependency scheme is available: system extensions should carry all files they need themselves, except for those already shipped in the underlying host system image. Typically, system extension images are built at the same time as the base OS image — within the same build system." https://www.freedesktop.org/software/systemd/man/systemd-sysext.html https://www.freedesktop.org/software/systemd/man/systemd-sys...
  - totony 6y ago
    What's the difference between this and just adding an overlayfs mount to /etc/fstab?
- deleted 6y ago
  [deleted]
PurpleFoxy 6y ago
The main problem with systemd IMO is that it’s written in a critically insecure language. If they could rewrite it in something safe but keep the same design, that would be ideal.
- atoav 6y ago
  I would rather say, the main problem with systemd is, that it tries to solve to many things in a way that: 1. makes very common usecases needlessly hard for beginners (e.g. run something on boot) 2. is sometimes the opposite of self explainatory I use systemd and am OK with it and I aggree with the problems it is trying to solve. It is just a bit convoluted and intransparent even after years of using it.
  - genghizkhan 6y ago
    I'd say running something on boot tends to be similar for beginners with or without systemd. The support for drop-in configs, however, makes it easy to revert screw-ups without much effort. In addition, the fact that one does not have to write any bash to change the way a service is started is a godsend. Ini-files aren't perfect, I get that, but from the point of view of a beginner they're both easier to grok and modify as compared to bash scripts.
  - foobar33333 6y ago
    I had to find a way to start something on boot recently and I found it trivial. I just did a google search for starting thing on boot systemd, copied a 5 line service file, enabled it and it worked. And if you just want to start a gui, Gnome Tweaks has a page which is super simple.
  - deadbunny 6y ago
    > makes very common usecases needlessly hard for beginners (e.g. run something on boot) Ah yes, systemd unit files are well regarded as far more complex than shell scripts that are 99% boilerplate. /s
    - GordonS 6y ago
olau 6y ago
How efficient is overlayfs? Could you use this to build a regular packaging system where instead of installing .debs/.rpms directly, they come as extension images and you just mount them in? I sometimes wonder why we even install stuff - mount it it in from remote with some kind of caching system, and you'd always have the latest, like on the web. Slap a delta algorithm on top, and it could even be more efficient. This is not to say that there's no value in freezing stuff and staying in control - there is - but ideally we would be able to choose.
- unilynx 6y ago
  isn't this what things like flatpack/snap try to offer?
  - marcodiego 6y ago
    Flatpak/snap/AppImage have been a godsend for me. I can now finally have a satisfactory easy balance between security/maturity of my system and run the latest software without having to compile it, and sometimes some of its dependencies, myself.
  - vetinari 6y ago
    Flatpak/snap are other part of the same puzzle. Think of them as the "app" part similar to mobile OSes; fedora silverblue/rpm-ostree/systemd-extensions as the "system" part.
- Arnavion 6y ago
  Yes, that's been one of Poettering's long-term goals [1] [2], and what Fedora SilverBlue and OSTree are trying to achieve. systemd features like the ability to create users via installable files [3] are geared towards this goal. [1]: http://0pointer.net/blog/projects/stateless.html http://0pointer.net/blog/projects/stateless.html [2]: http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html http://0pointer.net/blog/revisiting-how-we-put-together-linu... [3]: https://www.freedesktop.org/software/systemd/man/sysusers.d.html https://www.freedesktop.org/software/systemd/man/sysusers.d....
- 6y ago
znpy 6y ago
* systemd-cryptsetup gained support for unlocking LUKS2 volumes using TPM2 hardware, as well as FIDO2 security tokens (in addition to the pre-existing support for PKCS#11 security tokens). that's really interesting. i'd have to look at the details, but it could mean we could have encrypted disks and have a machine boot unassisted.
- Arnavion 6y ago
  You've been able to do LUKS filesystems auto-unlocked by TPMs before; the new thing here is just that systemd-cryptsetup can do it.
  - mschuster91 6y ago
    I don't get why this is a feature that people want. In case of theft / loss it doesn't offer any security benefits over no encryption.
    - hlieberman 6y ago
      The main thing this is used for in the Linux world is as part of a trusted boot pathway. It allows you to use the TPM to perform measurements on the boot chain and refuse to decrypt the data on the encrypted filesystem if it fails those checks.
    - vladvasiliu 6y ago
      As the sibling has said, this is usually used with SecureBoot. The system won't unlock the drives if, for example, you attempt booting an unsigned kernel image, change the boot order or otherwise tamper with the system setup. Granted, in case of theft, the computer will boot up if nothing is done to it. But in the case of a "user" computer where no services are listening, the risk is relatively low. In order to get access to the decrypted disk contents you'd have to exploit some vulnerability in Linux and / or the login manager.
      - lmilcin 6y ago
marcodiego 6y ago
Most important part for me is: "systemd-oomd is now considered fully supported". Since most major distros use systemd by default, it is important that also most of them fix the same fundamental problems the same way; and I really hope this new oomd finally fixes thrashing behavior. I'm not a sysadmin, so I never really felt the hate against systemd. For my use cases it was always not exactly transparent; it was essentially invisible.
- turminal 6y ago
  > Since most major distros use systemd by default, it is important that also most of them fix the same fundamental problems the same way; and I really hope this new oomd finally fixes thrashing behavior. Solving problems in multiple different ways is the only reason we have multiple distros serving different needs. Unification is not always a positive thing.
  - lmilcin 6y ago
    I second that. I feel like I have less and less choice. I can either accept all systemd provides or switch to some fringe distro. I switched from Windows to Linux 20 years ago to have more choice.
    - kaba0 6y ago
      I really don’t get this mentality. Where are you limited exactly? You can trivially view and edit every single service file to achieve basically anything. But a modern system does require some building blocks. I mean, the linux kernel is similarly limiting you to eg. have a file-oriented abstraction, and you can’t just swap it out to a different kernel. Systemd is much more modular than that for example.
      - lmm 6y ago
        Pre-systemd you actually could switch out the kernel on Debian - you could be running Hurd or the FreeBSD kernel, but the rest of the OS would still be Debian.
anotherhue 6y ago
Systemd continues to remind me of windows. It keeps fixing what wasn't broken, and you don't get to say 'no thank you' without a complete OS switch. Yes you can argue it's the distros decision, but that ship has sailed and fairly soon there won't even be an effective choice.
- dale_glass 6y ago
  Seems perfectly useful to me. The stated intention is to use that to provide things like debugging tools in setups that are deliberately minimal by design and don't include any troubleshooting functionality, maybe not even a package manager to install any with. A bit of a niche use perhaps, but seems to be very useful to me. And it's good that it's in systemd because otherwise you'd have to hack the boot process of every distro you might want this in. And I wouldn't say it wasn't broken, it's just a need you personally didn't have. I do actually have this need in a virtualization context, and may well making use of it.
  - anotherhue 6y ago
    Would an approach like this not also serve your needs? https://www.unix.com/man-page/FreeBSD/8/rescue/ https://www.unix.com/man-page/FreeBSD/8/rescue/
    - dale_glass 6y ago
      There's other approaches would work for me, yes. I could also download a tar file with what's missing and unpack it over root, I suppose. But then root would need to be read-write, like your solution also requires. Also, FreeBSD wouldn't work. We use many Linux specific features, and I have no interest whatsoever in porting all that stuff to BSD for no gain in functionality. Also, I see no issue to somebody else solving my problems and not needing to write more stuff that's unrelated to the actual purpose of what I'm doing.
- Chris2048 6y ago
  > you can argue it's the distros decision Is this not a fact, versus a mere argument? Do you think the decision is not based on merit? b/c there's all the effective distros switching, versus you saying nothing is broken - one of you must be wrong? Maybe the Linux ecosystem is broken, you just can't say it because you've already adjusted you expectations, or solidified your use case(s)?
geofft 6y ago
Previous discussion, for the v248 release candidate: https://news.ycombinator.com/item?id=26450960 https://news.ycombinator.com/item?id=26450960 There's a bunch of discussion of systemd-oomd and a bit of discussion of systemd extension images. Much of it is even calm and technical.
throwaway823882 6y ago
https://www.freedesktop.org/software/systemd/man/systemd-sysext.html https://www.freedesktop.org/software/systemd/man/systemd-sys... Somebody has got to stop systemd from unilaterally fucking up every Linux distribution's design with their wacky features. Only /opt and /usr? Because no other directories might need/want an overlay? And why the fuck can't we just use a regular overlay fs? To say nothing of it actually breaking the expectations of users and operators ("In addition to your existing huge troubleshooting checklist, see if systemd is silently injecting fake files into your process's path") When the hostname is set explicitly to "localhost", systemd-hostnamed will respect this. Previously such a setting would be mostly silently ignored. :-| This whole thing is designed like Kubernetes. Come up with a bad design, then hack in random functionality to make it as complicated as possible to use.
- louwrentius 6y ago
  They want to sell you hosted systemd ;-)
  - dane-pgp 6y ago
    More likely they want to create an "app store" where they control which versions of each package you install, and when, and how much you pay for them.
anotherhue 6y ago
Actually read the link. It reads like an OS change log. e.g. https://www.freebsd.org/releases/11.0R/relnotes/ https://www.freebsd.org/releases/11.0R/relnotes/
- tyingq 6y ago
  Seems like it would, given all the spaces it's in: systemd-networkd, systemd-resolved, systemd-timesyncd, systemd-udevd, systemd-journald, systemd-logind, systemd-nspawn, systemd-cron, systemd-notify, systemd-container, systemd-boot, systemd-oomd, systemd-mount, dbus, ...
  - rektide 6y ago
    and there are good & healthy improvements to each of these subsystems. and oh good --json logging support is available everywhere. nice SYSTEMD_COLORS supports new 16 and 256 options for all these tools. my entire system will work much better. with high consistency. this whole monorepo (not monolith) thing is working out.
    - tyingq 6y ago
      It varies. Their sntp client steps time instead of skewing, for example.
      - fl0wenol 6y ago
        I thought that was because it's designed to only jump time once at bootup so that TLS/logging can be sane... so that an NTP client can take over starting at a close offset?
        tyingq 6y ago
        No, it (systemd-timesyncd) runs as a daemon with settable poll intervals, etc.
      - aarmenaa 6y ago
kaszanka 6y ago
Come on, what was wrong with the previous title? It was more informative, and "Systemd 248" is technically not the original title either.
jordemort 6y ago
I mostly like systemd. I definitely like writing unit files a heck of a lot more than writing shell scripts; it's really easy to write bad shell, and we didn't have shellcheck to help us out back in the old days. The parts that I don't like, I don't use - it's really more of a monorepo than a monolith. That being said, I really wish there was more interest from the systemd folks in interoperating with containers and registries and all things OCI in general. Like the portable services they introduced in 239, the storage for the system extensions introduced in 248 is backed by either a directory or a disk image; meanwhile, there's an entire ecosystem of tools in the container world dedicated to the storage and distribution of root filesystems that they seem to be completely ignoring. I know there's nothing stopping me from using `umoci` or some such to pull and unpack a container and use the resulting directory as either a system extension or a source of portable services, but it'd be a lot cooler if that kind of functionality was baked in.
- guenthert 6y ago
  > I definitely like writing unit files a heck of a lot more than writing shell scripts; No argument there (even though declarative programming languages aren't universally favored over imperative ones), but why does this come up so often? On a typical Linux desktop or server there are hundreds, if not thousands of packages installed, yet only a few dozen init scripts. Almost no tool or application is typically run as service requiring such.
  - zootboy 6y ago
    Possibly it's because initscripts were such a painful experience that they weren't used as extensively. I find myself making systemd units often for small things that I wouldn't have wanted to write a whole initscript for. Just the dependency resolution features alone make it fantastic. It's only a few lines to specify a network dependency, a filesystem dependency, another service dependency, timeout and retry behaviors, monitoring and alerting on failures, etc. Plus it goes beyond just init. The scheduling features mean I'm turning to it instead of something like cron for doing repeated tasks on a server. Again, there's just a bunch of quality-of-life improvements there, like dependencies, better and more granular logging, error reporting, retries with limits, etc.

Systemd 248

126 points by marcodiego 6y ago

deleted 6y ago

[deleted]

uncledave 6y ago

I can’t wait to have to debug that in production.

mariusor 6y ago
And by "that" you mean which, exactly, of the 77 bullet points in the release notes?
- megous 6y ago
  That's hard to say upfront. Last time it was systemd-homed randomly blocking ssh access to remote systems where it was not even configured to be used, other than distro sticking its pam module to default pam config. What will be the killer future this time is yet to be seen.
  - kaba0 6y ago
    It sounds like either your distro f*cked up here, or you didn’t read the update notes, not sure what does it have to do with systemd..
    - megous 6y ago
      Why a disabled feature that should just do nothing even if its pam module is loaded, infinitely loops on D-BUS access in its pam module? Anyway, I reported it and it presumably got fixed. I wouldn't know, because systemd dev handling this didn't say a thing to me at all. Just closed the report after some seemingly not very related commits to what I saw in gdb. I just dropped the pam module from config anyway, and I'm not willing to lose access to my cluster again just to try. Not sure how distro fucked up in this case, when it's homed pam module going into infinite loop once in a while unpredictably blocking all processes that use pam naively, unless you mean that they fucked up by using systemd or pam at all. Edit: lol, I read through systemd release notes and there's no mention of new huge systemd-homed pam module at all. But good I looked, they're moving pam config for systemd to /usr/lib/pam.d and systemd-home pam module is again enabled there. So I'll have to check again all my systems if it's really disabled after upgrade.
  - tyingq 6y ago
    My last systemd mystery was nohup, tmux, etc, not being able to leave a process running. "Working as designed", sure, but it took a while for me to suspect systemd was involved and figure it out. Is there a document somewhere that shows what the systemd team thinks is a functional boundary? What things they don't plan on replacing?
    - uncledave 6y ago
      systemd is god now and he’s not benevolent. More lord cthulhu.
    - megous 6y ago
      Yes https://github.com/systemd/systemd/blob/main/TODO https://github.com/systemd/systemd/blob/main/TODO

Arnavion 6y ago

`ExtensionImages` (second bullet point) seems it would be essentially the same as having a regular Portable Service [1]. I get they needed the field for the system-level sysext service, so they just made it available to every other unit too. But is there any reason to use `ExtensionImages` instead of making a Portable Service? Edit: I guess if you have multiple services from multiple vendors that nevertheless agree to some common base image, it makes sense for those services to use `ExtensionImages`. Eg multiple services that all require a libglib base image. A Portable Service can expose multiple services from a single disk image, but that's the point - the vendors have to build a single disk image with their services. [1]: https://github.com/systemd/systemd/blob/main/docs/PORTABLE_SERVICES.md https://github.com/systemd/systemd/blob/main/docs/PORTABLE_S...

ohazi 6y ago

Is the use case desktops / servers, or embedded systems? There's a lot of crypto / secure boot stuff in there that looks complicated, but could be pretty neat if it works...

rezonant 6y ago
"The primary use case for system images are immutable environments where debugging and development tools shall optionally be made available, but not included in the immutable base OS image itself (e.g. strace and gdb shall be an optionally installable addition in order to make debugging/development easier). System extension images should not be misunderstood as a generic software packaging framework, as no dependency scheme is available: system extensions should carry all files they need themselves, except for those already shipped in the underlying host system image. Typically, system extension images are built at the same time as the base OS image — within the same build system." https://www.freedesktop.org/software/systemd/man/systemd-sysext.html https://www.freedesktop.org/software/systemd/man/systemd-sys...
- totony 6y ago
  What's the difference between this and just adding an overlayfs mount to /etc/fstab?
deleted 6y ago
[deleted]

PurpleFoxy 6y ago

The main problem with systemd IMO is that it’s written in a critically insecure language. If they could rewrite it in something safe but keep the same design, that would be ideal.

atoav 6y ago
I would rather say, the main problem with systemd is, that it tries to solve to many things in a way that: 1. makes very common usecases needlessly hard for beginners (e.g. run something on boot) 2. is sometimes the opposite of self explainatory I use systemd and am OK with it and I aggree with the problems it is trying to solve. It is just a bit convoluted and intransparent even after years of using it.
- genghizkhan 6y ago
  I'd say running something on boot tends to be similar for beginners with or without systemd. The support for drop-in configs, however, makes it easy to revert screw-ups without much effort. In addition, the fact that one does not have to write any bash to change the way a service is started is a godsend. Ini-files aren't perfect, I get that, but from the point of view of a beginner they're both easier to grok and modify as compared to bash scripts.
- foobar33333 6y ago
  I had to find a way to start something on boot recently and I found it trivial. I just did a google search for starting thing on boot systemd, copied a 5 line service file, enabled it and it worked. And if you just want to start a gui, Gnome Tweaks has a page which is super simple.
- deadbunny 6y ago
  > makes very common usecases needlessly hard for beginners (e.g. run something on boot) Ah yes, systemd unit files are well regarded as far more complex than shell scripts that are 99% boilerplate. /s
  - GordonS 6y ago

olau 6y ago

How efficient is overlayfs? Could you use this to build a regular packaging system where instead of installing .debs/.rpms directly, they come as extension images and you just mount them in? I sometimes wonder why we even install stuff - mount it it in from remote with some kind of caching system, and you'd always have the latest, like on the web. Slap a delta algorithm on top, and it could even be more efficient. This is not to say that there's no value in freezing stuff and staying in control - there is - but ideally we would be able to choose.

unilynx 6y ago
isn't this what things like flatpack/snap try to offer?
- marcodiego 6y ago
  Flatpak/snap/AppImage have been a godsend for me. I can now finally have a satisfactory easy balance between security/maturity of my system and run the latest software without having to compile it, and sometimes some of its dependencies, myself.
- vetinari 6y ago
  Flatpak/snap are other part of the same puzzle. Think of them as the "app" part similar to mobile OSes; fedora silverblue/rpm-ostree/systemd-extensions as the "system" part.
Arnavion 6y ago
Yes, that's been one of Poettering's long-term goals [1] [2], and what Fedora SilverBlue and OSTree are trying to achieve. systemd features like the ability to create users via installable files [3] are geared towards this goal. [1]: http://0pointer.net/blog/projects/stateless.html http://0pointer.net/blog/projects/stateless.html [2]: http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html http://0pointer.net/blog/revisiting-how-we-put-together-linu... [3]: https://www.freedesktop.org/software/systemd/man/sysusers.d.html https://www.freedesktop.org/software/systemd/man/sysusers.d....
6y ago

znpy 6y ago

* systemd-cryptsetup gained support for unlocking LUKS2 volumes using TPM2 hardware, as well as FIDO2 security tokens (in addition to the pre-existing support for PKCS#11 security tokens). that's really interesting. i'd have to look at the details, but it could mean we could have encrypted disks and have a machine boot unassisted.

Arnavion 6y ago
You've been able to do LUKS filesystems auto-unlocked by TPMs before; the new thing here is just that systemd-cryptsetup can do it.
- mschuster91 6y ago
  I don't get why this is a feature that people want. In case of theft / loss it doesn't offer any security benefits over no encryption.
  - hlieberman 6y ago
    The main thing this is used for in the Linux world is as part of a trusted boot pathway. It allows you to use the TPM to perform measurements on the boot chain and refuse to decrypt the data on the encrypted filesystem if it fails those checks.
  - vladvasiliu 6y ago
    As the sibling has said, this is usually used with SecureBoot. The system won't unlock the drives if, for example, you attempt booting an unsigned kernel image, change the boot order or otherwise tamper with the system setup. Granted, in case of theft, the computer will boot up if nothing is done to it. But in the case of a "user" computer where no services are listening, the risk is relatively low. In order to get access to the decrypted disk contents you'd have to exploit some vulnerability in Linux and / or the login manager.
    - lmilcin 6y ago

marcodiego 6y ago

Most important part for me is: "systemd-oomd is now considered fully supported". Since most major distros use systemd by default, it is important that also most of them fix the same fundamental problems the same way; and I really hope this new oomd finally fixes thrashing behavior. I'm not a sysadmin, so I never really felt the hate against systemd. For my use cases it was always not exactly transparent; it was essentially invisible.

turminal 6y ago
> Since most major distros use systemd by default, it is important that also most of them fix the same fundamental problems the same way; and I really hope this new oomd finally fixes thrashing behavior. Solving problems in multiple different ways is the only reason we have multiple distros serving different needs. Unification is not always a positive thing.
- lmilcin 6y ago
  I second that. I feel like I have less and less choice. I can either accept all systemd provides or switch to some fringe distro. I switched from Windows to Linux 20 years ago to have more choice.
  - kaba0 6y ago
    I really don’t get this mentality. Where are you limited exactly? You can trivially view and edit every single service file to achieve basically anything. But a modern system does require some building blocks. I mean, the linux kernel is similarly limiting you to eg. have a file-oriented abstraction, and you can’t just swap it out to a different kernel. Systemd is much more modular than that for example.
    - lmm 6y ago
      Pre-systemd you actually could switch out the kernel on Debian - you could be running Hurd or the FreeBSD kernel, but the rest of the OS would still be Debian.

anotherhue 6y ago

Systemd continues to remind me of windows. It keeps fixing what wasn't broken, and you don't get to say 'no thank you' without a complete OS switch. Yes you can argue it's the distros decision, but that ship has sailed and fairly soon there won't even be an effective choice.

dale_glass 6y ago
Seems perfectly useful to me. The stated intention is to use that to provide things like debugging tools in setups that are deliberately minimal by design and don't include any troubleshooting functionality, maybe not even a package manager to install any with. A bit of a niche use perhaps, but seems to be very useful to me. And it's good that it's in systemd because otherwise you'd have to hack the boot process of every distro you might want this in. And I wouldn't say it wasn't broken, it's just a need you personally didn't have. I do actually have this need in a virtualization context, and may well making use of it.
- anotherhue 6y ago
  Would an approach like this not also serve your needs? https://www.unix.com/man-page/FreeBSD/8/rescue/ https://www.unix.com/man-page/FreeBSD/8/rescue/
  - dale_glass 6y ago
    There's other approaches would work for me, yes. I could also download a tar file with what's missing and unpack it over root, I suppose. But then root would need to be read-write, like your solution also requires. Also, FreeBSD wouldn't work. We use many Linux specific features, and I have no interest whatsoever in porting all that stuff to BSD for no gain in functionality. Also, I see no issue to somebody else solving my problems and not needing to write more stuff that's unrelated to the actual purpose of what I'm doing.
Chris2048 6y ago
> you can argue it's the distros decision Is this not a fact, versus a mere argument? Do you think the decision is not based on merit? b/c there's all the effective distros switching, versus you saying nothing is broken - one of you must be wrong? Maybe the Linux ecosystem is broken, you just can't say it because you've already adjusted you expectations, or solidified your use case(s)?

geofft 6y ago

Previous discussion, for the v248 release candidate: https://news.ycombinator.com/item?id=26450960 https://news.ycombinator.com/item?id=26450960 There's a bunch of discussion of systemd-oomd and a bit of discussion of systemd extension images. Much of it is even calm and technical.

throwaway823882 6y ago

https://www.freedesktop.org/software/systemd/man/systemd-sysext.html https://www.freedesktop.org/software/systemd/man/systemd-sys... Somebody has got to stop systemd from unilaterally fucking up every Linux distribution's design with their wacky features. Only /opt and /usr? Because no other directories might need/want an overlay? And why the fuck can't we just use a regular overlay fs? To say nothing of it actually breaking the expectations of users and operators ("In addition to your existing huge troubleshooting checklist, see if systemd is silently injecting fake files into your process's path") When the hostname is set explicitly to "localhost", systemd-hostnamed will respect this. Previously such a setting would be mostly silently ignored. :-| This whole thing is designed like Kubernetes. Come up with a bad design, then hack in random functionality to make it as complicated as possible to use.

louwrentius 6y ago
They want to sell you hosted systemd ;-)
- dane-pgp 6y ago
  More likely they want to create an "app store" where they control which versions of each package you install, and when, and how much you pay for them.

anotherhue 6y ago

Actually read the link. It reads like an OS change log. e.g. https://www.freebsd.org/releases/11.0R/relnotes/ https://www.freebsd.org/releases/11.0R/relnotes/

tyingq 6y ago
Seems like it would, given all the spaces it's in: systemd-networkd, systemd-resolved, systemd-timesyncd, systemd-udevd, systemd-journald, systemd-logind, systemd-nspawn, systemd-cron, systemd-notify, systemd-container, systemd-boot, systemd-oomd, systemd-mount, dbus, ...
- rektide 6y ago
  and there are good & healthy improvements to each of these subsystems. and oh good --json logging support is available everywhere. nice SYSTEMD_COLORS supports new 16 and 256 options for all these tools. my entire system will work much better. with high consistency. this whole monorepo (not monolith) thing is working out.
  - tyingq 6y ago
    It varies. Their sntp client steps time instead of skewing, for example.
    - fl0wenol 6y ago
      I thought that was because it's designed to only jump time once at bootup so that TLS/logging can be sane... so that an NTP client can take over starting at a close offset?
      - tyingq 6y ago
        No, it (systemd-timesyncd) runs as a daemon with settable poll intervals, etc.
    - aarmenaa 6y ago

kaszanka 6y ago

Come on, what was wrong with the previous title? It was more informative, and "Systemd 248" is technically not the original title either.

jordemort 6y ago

I mostly like systemd. I definitely like writing unit files a heck of a lot more than writing shell scripts; it's really easy to write bad shell, and we didn't have shellcheck to help us out back in the old days. The parts that I don't like, I don't use - it's really more of a monorepo than a monolith. That being said, I really wish there was more interest from the systemd folks in interoperating with containers and registries and all things OCI in general. Like the portable services they introduced in 239, the storage for the system extensions introduced in 248 is backed by either a directory or a disk image; meanwhile, there's an entire ecosystem of tools in the container world dedicated to the storage and distribution of root filesystems that they seem to be completely ignoring. I know there's nothing stopping me from using `umoci` or some such to pull and unpack a container and use the resulting directory as either a system extension or a source of portable services, but it'd be a lot cooler if that kind of functionality was baked in.

guenthert 6y ago
> I definitely like writing unit files a heck of a lot more than writing shell scripts; No argument there (even though declarative programming languages aren't universally favored over imperative ones), but why does this come up so often? On a typical Linux desktop or server there are hundreds, if not thousands of packages installed, yet only a few dozen init scripts. Almost no tool or application is typically run as service requiring such.
- zootboy 6y ago
  Possibly it's because initscripts were such a painful experience that they weren't used as extensively. I find myself making systemd units often for small things that I wouldn't have wanted to write a whole initscript for. Just the dependency resolution features alone make it fantastic. It's only a few lines to specify a network dependency, a filesystem dependency, another service dependency, timeout and retry behaviors, monitoring and alerting on failures, etc. Plus it goes beyond just init. The scheduling features mean I'm turning to it instead of something like cron for doing repeated tasks on a server. Again, there's just a bunch of quality-of-life improvements there, like dependencies, better and more granular logging, error reporting, retries with limits, etc.