51–60 of 102 posts
Earlier quoted context omitted.
Yup, earlyssh - I found it a massive pain to set up, but it works.
Interesting, I've never heard of earlyssh as an option--I've used dropbear-initramfs for this in the past.
Earlier quoted context omitted.
The "horrific abomination" turned a process of trial and error and custom shell scripts full of low-level, platform-specific commands into a single, consistent interface. I don't see the downside?
For me, the difference is simple. Systemd is great when it works. But, part of the value of the Unix philosophy is resiliency in the face of errors. When my void Linux / alpine Linux systems have internal failures, I can troubleshoot and solve them because the system is composed of minimal abstractions tied together - I can feasibly deduce the root of the problem, and fix it, even if half the OS is missing. With syst…
Earlier quoted context omitted.
I don't really understand this feature creep argument against systemd. I mean, this is not like this is a feature included in PID1, it is a new binary so a separate feature (and I am pretty sure that you can choose to not compile it too if you don't want, like almost any other systemd feature with the exception of systemd itself and journald). Also, the way I understand systemd nowadays is it isn't an init system, it…
> I don't really understand this feature creep argument against systemd. > Also, the way I understand systemd nowadays is it isn't an init system, it is an API for Linux systems that abstracts low level features in kernel in a consistent way (either using unit files or systemd C interface). Starting as an init system and becoming a general API that abstracts low level kernel features seems like feature creep. > You c…
I think the initial presentation of systemd as a faster init system hurt it more than helped, because people started to think that systemd "was just an init system". And it never was really, even early on there were blog posts showing how powerful was its declarative approach. But it seems that the only blog post people remember is the "faster init" one (that even this one did more emphasis on the fact that systemd did dependencies the right way them the fact that it was fast).
> every other approach and dragging linux further away from its BSD/Illumos cousins
The way I think about systemd is that it make it closer to the approach of BSD and other *nix systems does. Portability is never something easy, specially when you're doing complicated things like power or network management. A good example is that all the different BSDs have difference between on how you manage networks, and the way it was on Linux before systemd was that *every* distro reinvented their own network management system (and each one was slightly broken in some fun way).
So what systemd does? They standardized everything. Now if your distro uses systemd-networkd, you can finally write a service that depends on a specific network topology that is portable across multiple Linux distros.
BSD don't need something like systemd because they're already tightly integrated, because the kernel and user space is both developed by the same team. Each part of a Linux user space used to be developed by different people, and it was the work of the distro to integrate everything. Now systemd provides a good foundation for many things in user space, and most distros stopped to ship their own solutions except for package management and some other integration bits that they need for their specific purposes.
So if you say to me that systemd is feature creep, it is as much feature creep them the whole FreeBSD or OpenBSD. And this just doesn't make sense.
Earlier quoted context omitted.
The "horrific abomination" turned a process of trial and error and custom shell scripts full of low-level, platform-specific commands into a single, consistent interface. I don't see the downside?
I tinker on my gentoo box and OpenRC is more than capable of everything it needs to do. I don't understand why people's linux fill up with "trial and error custom shell scripts". Can someone explain why non-systemd systems are claimed to be full of broken shell scripts? I've yet to experience that.
For example mysqld_safe is there pretty much to handle things that systemd can do, but initd can't. Some other services have custom wait-logic to make sure dependencies are ready, which is covered by service readiness notification in systemd (see just yesterday https://news.ycombinator.com/item?id=25845143). Many services do custom pidfile handling (see the fun implementation in openssh init file - your pidfile path better not have `=` in it) just because initd has no idea of services.
Basically every service I've seen which has more than a single line in start and stop functions in broken is at least one subtle way. (and close to every single status function - no, existence of the pidfile and that pid running an undefined process is not the same as service functioning) Systemd provides 99% of what those init scripts try to achieve as simple configuration and if something's missing you can still fall back to executing a script instead.
Seems like some more feature creep from systemd.
I don't really understand this feature creep argument against systemd. I mean, this is not like this is a feature included in PID1, it is a new binary so a separate feature (and I am pretty sure that you can choose to not compile it too if you don't want, like almost any other systemd feature with the exception of systemd itself and journald). Also, the way I understand systemd nowadays is it isn't an init system, it…
AFAIK systemd and the different components has so many internal dependencies on each other than not much works if you try to pull things apart. You can remove systemd completely, yes, but try to only have systemd as an init system and nothing works!
Earlier quoted context omitted.
For me, the difference is simple. Systemd is great when it works. But, part of the value of the Unix philosophy is resiliency in the face of errors. When my void Linux / alpine Linux systems have internal failures, I can troubleshoot and solve them because the system is composed of minimal abstractions tied together - I can feasibly deduce the root of the problem, and fix it, even if half the OS is missing. With syst…
Are you sure it's not just familiarity with old tools? Systemd works pretty hard to put logs in one place (journald) - even ones from service start-ups. And any dbus interaction can be traced by listening to the system bus. Is that a mess compared to the old bunch of separate log files and errors lost if they don't activate their logging interface early enough?
I'm talking about being able to rule out causes because the primary components of the system are independent of each other.
Earlier quoted context omitted.
Are you sure it's not just familiarity with old tools? Systemd works pretty hard to put logs in one place (journald) - even ones from service start-ups. And any dbus interaction can be traced by listening to the system bus. Is that a mess compared to the old bunch of separate log files and errors lost if they don't activate their logging interface early enough?
I'm not talking about reading logs. (Which, by the way, is a lot easier to do in a dead system when they're text and not binary. It's hard to mess up cat, grep, and notepad.) I'm talking about being able to rule out causes because the primary components of the system are independent of each other.
The binary format doesn't matter for browsing logs. Replace `cat /your/custom/service/file.log | grep ...` with `journalctl -u service | grep ...` (or just `-a` for everything)
I'd actually argue it's easier not to mess up with journal with simple tools, because you don't have to special-case `service`, `service.1`, `service.2.gz` files.
Earlier quoted context omitted.
Note that this trashes your disk I/O performance; AWS offers Customer Managed Keys as an alternative where you use their platform's encryption but with your own keys: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncry...
Google compute platform even offers user-provided keys at instance startup; they persist in RAM only for the lifetime of the instance and you can provide an rsa-encrypted symmetric key to GCP if you don't trust the box responsible for calling the GCP API. Combined with AMD-based (SEV) confidential computing and shielded vm you can get close to what on-premises hardware offers. Nothing can truly replace hardware you o…
If you do trust Google, this is of no benefit. They encrypt your disk at rest anyway with their own keys if you don't provide yours.
The only reason to use any of the above tech is to change the legal burden of who has to provide data if a court order is made. If you provide the keys then the court has to come to you to provide data on demand.
FYI, Nitrokey runs Solo FIDO2 implementation [1], which is also used by Signet HC and OnlyKey. So all these FIDO2 keys will work with LUKS2.
And if any maker of keys is reading, please reach out if you're implementing U2F but want to upgrade to the full FIDO2, including the hmac-secret extension.