1. 11
  1. 24

    I’d just like to interject for a moment. What you’re refering to as Linux, is in fact, systemd/Linux, or as I’ve recently taken to calling it, systemd plus Linux. Linux is not an operating system unto itself, but rather another free component of a fully functioning systemd system made useful by the systemd corelibs, shell utilities and vital system components comprising a full OS as defined by Red Hat.

    Many computer users run a modified version of the systemd system every day, without realizing it. Through a peculiar turn of events, the version of systemd which is widely used today is often called Linux, and many of its users are not aware that it is basically the systemd system, developed by the systemd project.

    (more seriously, this gets truer every year.)

    1. 1

      The edit didn’t fix it. :(

      1. 2

        Should be fixed now.

        Also, I do think systemd enables some neat things–NixOS being one of them. But, it’s still fun to rag on.

        1. 6

          I would not say that systemd enables NixOS. NixOS ran fine on upstart. There were some issues with impedance mismatch, and there are some different ones (and also some required custom patches) with systemd. Guix might have given up, but they ran their own Shepherd thing just fine. And well, the features of NixOS that make it different — I have these on a system running sinit as PID1 right now (using Nix/Nixpkgs and some chunks of NixOS code). What I lose and what I get rid of are some systemd-specific behaviours (some bad, some good, but I have no use for the good ones), not really anything NixOS-specific.

          1. 3

            It’d be awesome if you could go into your process there and how you ended up with what you did!

            1. 2

              Hm. It seems to be a long-ish story, and part rant on systemd. And offtopic. But I do not want to link my work and explicitly say it is my work but signed by my different identity (people making inferences is fine, that activity is limited to people with common interests). So I guess here it goes https://friendpaste.com/1pqXzSdNjIkjo8ubuhilUY

    2. 11

      Soooo xkcd. If EFI hasn’t standardized it in the last 20 years, then surely defining a new standard will achieve immediate adoption and consensus, amirite?

      The idea of systemd taking over the bootloader is kind of horrifying, but it’s easy to take comfort in the slim chance of success.

      1. 5

        Many EFI systems disable USB support during early boot to optimize boot times, thus making keyboard input unavailable in the EFI menu. It is thus useful if the OS UI has a standardized way to discover available boot options which can be booted to.

        If that’s true, it’s yet another compelling reason to abandon the x86 PC. I’ve been using Raspberry Pi for years. The boot process is refreshingly uncomplicated. I started out on Apple II machines back in the late 80s. The Apple II booted from a floppy without configuration; the Pi boots from an SD card without configuration. Want to boot another image? Just swap out cards and power it up.

        x86 is drowning in its own crazyness and legacy.

        1. 5

          I’ve been using Raspberry Pi for years. The boot process is refreshingly uncomplicated.

          I really hope that you’re joking. The RPi starts by executing some code on the GPU. The GPU then DMAs some code into memory and sends an interrupt to the CPU that then begins executing the second-stage bootloader code. This is why the early boot on a RPi shows a shaded triangle: because the GPU is running but the CPU isn’t yet.

          I’m horrified that anyone would think that is uncomplicated or something that should positively influence any other system.

          1. 2

            I’m as serious as a heart attack. I think we’re talking about different things, though.

            I’ve never written a boot loader for the Pi; I have no idea what it’s doing at a low level when it boots up. But from a user’s point of view, there’s nothing simpler than changing boot media to swap out operating systems. No BIOS to configure, no boot menu, no “choose between UEFI and legacy”. Just slip in an SD card with the proper files in the proper place and you’re good to go.

            I’m blind. Unless I’m lucky enough to have a machine with IPMI or a serial console of some sort, it is incredibly difficult for me to debug a failed boot on x86. I’ll walk that back a tiny bit, because GRUB 2 has a morse code output mode, and I know morse. Even that requires the machine to have a working console beep; not all do. So yeah, my idea of refreshingly uncomplicated and your idea are orthogonal.

          2. 1

            I don’t think that’s true at all. I work with a lot of different x86 systems that boot EFI, and I’ve never had one not work with a usb keyboard in either the EFI shell or setup menu.

            1. 1

              Yeah, this seemed rather dubious to me.

              I’ve seen this pattern of rationalization from the systemd project before, anecdotally, but I’m struggling to come up with other examples right now. “We’re doing Y because the world works like X now”, where X is something dubious. In fact, they wish the world worked like X, assume it does, and then use that as rationale for doing Y. Really I don’t mean to single out systemd for this; I think I see that pattern all over the industry.

          3. 2

            EFI is not ubiquitous, especially not in embedded systems.

            What embedded systems support the systemd bootloader specification and do not have an EFI-compatible bootloader?

            1. 1

              Yea, I didn’t understand that either. Microsoft’s Nokia phones had UEFI+ARM, even though they were locked. I think people have been able to unlock them, but there are still a ton of missing drivers to be able to run your own stuff on old Win phones.

              Honestly we should see MORE UEFI on all embedded devices. The Pi5 should support UEFI. All the SoCs like the Beagle Bone and Banana Pi should use UEFI. No one uses device tree and it’s garbage anyway. UEFI would go a long way to reducing embedded and SoC e-waste by just giving us a common way to at least start trying to reverse engineer old ARM devices.

              1. 6

                No one uses device tree and it’s garbage anyway.

                It may be garbage, but almost every platform besides x86 uses it on every board (at least for Linux).

                1. 3

                  No one uses device tree and it’s garbage anyway.

                  Unfortunately for my mental sanity, almost every embedded Linux gadget uses device trees. Most of them don’t have the underlying firmware to dynamically build and query it, of course, the device tree gets “fed” to the kernel through various other mechanisms (usually via U-Boot, which acts as both bootloader and firmware), but device trees are otherwise quite universal. The tooling is at the intersection of horrifying and useless, which is why everyone hates device trees – it is garbage, but literally everyone uses it. Even for “platform devices”, which you can technically initialise without device trees, too.

                  IMHO adding an UEFI layer to embedded devices wouldn’t help much. Most of the peripheral devices get connected on buses that don’t really support enumeration anyway – I2C, SPI, all sorts of internal SoC buses and so on. So you’d get on-board firmware that enumerates devices from a statically-defined device tree anyway, except with an extra layer of manufacturer-supplied bugs, upgrading headaches and so on.

                  The idea of loading various platforms with BIOS-like firmwares has been floated around the embedded space for a very long time, since the mid 90s at the very least. It hasn’t caught on because it doesn’t actually help much, certainly not enough to warrant the extra cost. Things like the Beagle Bone and the Banana Pi are definitely not representative of the embedded systems space at large – they’re hobbyist platforms that often do get used as reference designs for real devices, too, but that’s not how cost-sensitive design, where Linux and Android particularly shine, is usually done.

                  1. 1

                    Slap U-Boot on it. Now you have UEFI.