Slashdot Mirror
Systemd Getting UEFI Boot Loader
New submitter mrons writes: Many new features are coming for systemd. This includes the ability to do a full secure boot. As Lennart Poettering mentions in a Google+ comment: "This is really just about providing the tools to implement the full trust chain from the firmware to the host OS, if SecureBoot is available. ... Of course, if you don't have EFI SecureBoot, than nothing changes. Also if you turn it off, than nothing changes either. [sic]" Phoronix notes, "Gummiboot is a simple UEFI boot manager that's been around for a few years but only receives new work from time-to-time. Lennart and Kay Sievers are looking at adding Gummiboot to systemd to complete the safety chain of the boot process with UEFI Secure Boot. Systemd will communicate with this UEFI boot loader to ensure the system didn't boot into a compromised state."
FreeBSD user here since over a decade. Welcome.
You haven't seen FreeBSD crash? It only means that you haven't seen enough, yet. FreeBSD is a great system and I recommend it to everyone who can manage it, but you don't need to mention stability as a feature, because it is not the highlight about FreeBSD. You don't install a system and watch how stable it is, but how useful it is (for you and your special requirements).
The best thing about FreeBSD are the FreeBSD Ports and how much commitment there is to make every possible application work on the system. You have basically far more possibilities and options than on Linux distributions thanks to the great job they are doing on this system.
A second point is that it is easier to feel comfortable on the system, because the whole thing is consistent and easy to understand, provided you take some time and learn about the concepts.
That's the problem. There isn't a stable release with systemd.
Fedora has so far released six stable releases with systemd, and Red Hat shipped their first stable release with systemd last summer.
The code isn't audited, nor has it seen actual production testing. It was just foisted on the end users without any transition period, possibly breaking every single app that uses the init.d mechanism for starting and control.
It has been shipping in Fedora for the past four years, and in RHEL since last summer. If that's not production testing then what is?
To boot, with systemd's ability to listen on the network, it has a good chance of becoming a massive remote root exploit in the waiting. Does it have any internal security? We can cross fingers that this large blob of new code does more harm than good, but all it takes is one glitch, and it would mean havoc worse than the RTM worm on the UNIX side ages ago, or the Windows worms in the early 2000s.
Inetd has been doing that for years. It has since moved to a different project. Big deal?
Not enough coffee this morning, I quoted Unstable. Testing has similar warnings and you will find that every time there is major plumbing changes testing breaks. It's inevitable as edge cases break things.
Search the archives, there have been plenty of instances where a package pushed into testing broke people's machines. I remember several.
More like different focuses.
FreeBSD is nice, but it's very server-oriented. Sure you can use it on a desktop through ports, but everything's still basically assuming you're on a server.
SystemD is like PulseAudio, CUPS, and NetworkManager - they're tools to handle the complex desktop use cases that don't exist with servers.
Of course, one thing FreeBSD does have is a general guidance and an avoidance of the latest shiny or political plays, which means a lot of Linux cruftiness is avoided, so stability in that form means things don't change too much.
But, desktop users have a lot of requirements that just cannot be band-aided over like they do in Linux where you have spitwads, gum and duct tape holding together a lot of the system. Sure it works, but it's an extremely fragile system that's just begging for breakage.
Here's some use cases that are extremely common in a desktop, but not at all on a server, and how various packages handle them.
Audio - modern desktops have multiple audio paths - from HDMI to plain old speaker/headphone/line outs. And new ones appear and disappear constantly (say, Bluetooth). And audio needs to be mixed because the user might be watching a YouTube video when the system needs to alert them via a system sound. Or say, the user is listening to music, and then a VoIP call comes in which means muting the audio from the music player and activating the communications audio path (which can be completely different audio paths - the music may play through a speaker path, while the VoIP takes place over a headset using either a separate set of ADCs and DACs, Bluetooth, or whatever). Or perhaps the user is listening to music over their A/V system using HDMI audio. Then they turn off their A/V system losing the audio connection - audio now needs to be transported to a secondary source transparently to the application (can't have apps crashing because the audio device disappeared). Or how about a user opening an audio device for exclusive use (low latency, bit-perfect, whatever), and the system needs to play a sound (VoIP, alert, whatever). If there's no other audio path, it's a too-bad situation. But if there's another set of speakers or audio, why not route that audio that way so the user can get the alert through a secondary audio path?
Networks are just as tricky - you want to connect to many different networks with differing roles - perhaps if you're at home, you bring down the firewall, while if you're on the go, the firewall goes up and maybe the VPN does too. Suddenly media connections are very important too because once you disconnect, you don't know if the next attachment will be to a trusted or untrusted network. And the firewall may need to manage different rules - like perhaps the HTTP server is allowed on all networks - public, private, VPN, whatever, while say Samba should only be accessible on private networks only. Repeat for other applications as necessary.
SystemD is similar - a lot of services these days aren't launched on the system's behalf, but on the user. Right now there are dozens of different ways to have services launch when you log in - every environment provides a different way of doing it and there's no standard, so perhaps if you need a service to launch on Ubuntu when you log in, it won't work on Fedora. That's a huge mess - why not have something that's good at managing processes do it? Sure you have system services that start up on system boot, but there are a lot