6 ms·

Systemd ParticleOS

89 points by kblissett 2y ago

sph 2y ago
> Currently both arch and fedora are supported distributions. Does this mean that we can now have an actual immutable Arch-based distro?! I love Silverblue, best distro ever, but the day I can have immutable Arch Linux I’m outta here! I truly despise rpm and all the fedora machinations required to build a custom package.
- DaanDeMeyer 2y ago
  Yeah I've been running the Arch variant of this on my personal laptop for a while now. Of course no stability guarantees with this for now since you'll be running systemd from source.
  - xx_ns 2y ago
    How have your experiences with this setup been so far? Any major pain points?
    - DaanDeMeyer 2y ago
      Building the next update locally is slow because erofs has to compress the entirety of /usr on my rather old laptop and that takes a while. Aside from that, I'm using flatpak for firefox and for some reason it takes absolutely forever (like > 15s) to start firefox on my machine, still need to look into why that happens. Aside from those it's very usable. But of course it's running systemd from source so I'm not going to actually recommend anyone to run this who is not a systemd maintainer until we iron out the kinks.
      - xx_ns 2y ago
        Thanks! The slow startup times have usually been an xdg-desktop-portal issue for me in the past, might be worth looking into.
  - vaylian 2y ago
    How does the update process work? Do you run pacman -Syu and then bake the result into the next image with mkiso?
    - DaanDeMeyer 2y ago
      mkosi runs pacman for you and then packs up the result as a disk image. It also builds a unified kernel image and does a bunch of signing. The new /usr partition and UKI are then installed with systemd-sysupdate.
cedws 2y ago
I’m somewhat a fan of systemd and I’m interested in immutable images, but I don’t want to build systemd from source: >Sometimes ParticleOS adopts systemd features as soon as they get merged into systemd without waiting for an official release. As a result it's recommended to build systemd from source when building ParticleOS to make sure all required features are supported
- palata 2y ago
  > I’m somewhat a fan of systemd As in: "you've tried alternatives and you really think that systemd is superior", or as in "you don't see why people complain about systemd and its philosophy"? Genuinely interested, because usually people I hear say that they don't see the problem with systemd don't really have experience with the alternatives. Which makes sense: people who like being able to use alternatives tend to get screwed by systemd :-). Edit: for those downvoting, this is a genuine question. I mostly hear opinions from people who hate systemd, and those who don't generally just don't really care: "I've always used systemd and I haven't had issues". But the latter group wouldn't call themselves "fans of systemd".
  - miladyincontrol 2y ago
    Blatantly not the person you're asking, but once you go past basic service management trying to do it just about anywhere else is an absolute and total nightmare. People who have major problems with systemd more than anything just ever seem confused, often vastly overestimating systemd's actual scope. The reality to many is its the simplest simple way to handle some very complex tasks, and the vast majority of it is still all so very very much optional even in the most 'systemd heavy' distros.
  - TheDong 2y ago
    Not the person you're asking, but I'm curious what you mean when you say "the alternatives". I've used runit, openrc, briefly upstart (what a trashfire that was), and I don't miss a single thing about them while writing systemd unit files. I've used GNU Shepherd on Guix, and honestly, meh, systemd feels way more pragmatic. I've also used systemd-networkd as well as NetworkManager, and feel like they both still have a few warts, but overall prefer systemd-networked on servers. I've used grub, refit, and systemd-boot, and gotta say systemd-boot is my preference there too. I haven't really used systemd portable services, but I've used docker and don't like it, and my overall impression is I'll probably like portable services more. Are there other alternatives I have to use before I'm allowed to have an opinion? What alternatives have you used which made you feel so enlightened?
leoedin 2y ago
I work in the embedded space. I'd absolutely love to have a tool to build immutable, signed distro images which I can push to devices with a/b style updates. I imagine you can do this with mkosi, but it doesn't quite feel like the intended use case. Most immutable distros (this included) are developed with the idea that you'd run local commands on the machine, and update a single OS image in place. That gets pretty unwieldy to manage across a fleet of devices. Right now the industry standard tooling for building truly immutable images for embedded devices is Yocto. It works well, but it's incredibly complicated and has ridiculous build times because it insists on building every single package from source. It's utter madness that building a Linux image for a common ARM64 processor requires me to compile the Rust compiler myself.
- weikju 2y ago
  If only Tiny Core Linux had had better tooling and if only corporations liked simplicity, it might have been more popular…
  - vbezhenar 2y ago
    Bulidroot is popular and simple alternative. But corporations prefer complexity.
    - dijit 2y ago
      We at darkscience used buildroot for a simple ZNC SBC[0] distribution which we deployed to an Orange Pi Zero that we sold at 33C3[1]. It was great! I highly recommend! It didn't take long to get started and while the compile times were pretty large (wonder if NIX or Bazel could help here?) it ended up with absolutely microscopic resource requirements. [0]: https://git.drk.sc/Derecho/irc-sbc-buildroot https://git.drk.sc/Derecho/irc-sbc-buildroot [1]: https://media.ccc.de/c/33c3 https://media.ccc.de/c/33c3
      - sam_bristow 2y ago
        I've had a reasonable amount of luck with a combination of Buildroot and Bazel. I use Buildroot to assemble a minimal Base OS with just the kernel, bootloader and a few system services. Then the application layer is built with Bazel and assembled into a set of squashfs images which are mounted as overlay filesystems at boot time. The whole thing is shipped as a SWUpdate file built with the Bazel layer. Because most of the iteration is happening in the Bazel layers I can generate a full system update in about 15 seconds with everything being fully reproducible.
bfrog 2y ago
Nix would let you do just this already with potential binary cache and reproducibility. I’m surprised it’s not more widely used for embedded. Maybe due to larger images? That’s a solvable problem. Maybe best of all it’s fast. Yocto is painfully slow.
- klysm 2y ago
  I'm not sure nix is aimed at the same kind of things here. ParticleOS seems to be a logical continuation of the effort that systemd has been putting into TPM2, boot security, signing, and immutability.
vaylian 2y ago
Is ParticleOS also a useful everyday driver for Linux enthusiasts who aren't systemd developers? Let's say I got bored with Gentoo and I want to try something new. Is ParticleOS something that a technical user would enjoy at the current stage?
- DaanDeMeyer 2y ago
  I think you'll get the most out of this at the moment if you're interested in actively contributing to systemd. There's lots of work left to be done to make this usable which will just be annoying if you aren't interested in fixing some of this stuff yourself. Of course if you're interested in doing small prs and such to improve things then I think it could be very satisfying. You can always join the mkosi matrix channel to chat more about this stuff.

89 points by kblissett 2y ago

sph 2y ago

> Currently both arch and fedora are supported distributions. Does this mean that we can now have an actual immutable Arch-based distro?! I love Silverblue, best distro ever, but the day I can have immutable Arch Linux I’m outta here! I truly despise rpm and all the fedora machinations required to build a custom package.

DaanDeMeyer 2y ago
Yeah I've been running the Arch variant of this on my personal laptop for a while now. Of course no stability guarantees with this for now since you'll be running systemd from source.
- xx_ns 2y ago
  How have your experiences with this setup been so far? Any major pain points?
  - DaanDeMeyer 2y ago
    Building the next update locally is slow because erofs has to compress the entirety of /usr on my rather old laptop and that takes a while. Aside from that, I'm using flatpak for firefox and for some reason it takes absolutely forever (like > 15s) to start firefox on my machine, still need to look into why that happens. Aside from those it's very usable. But of course it's running systemd from source so I'm not going to actually recommend anyone to run this who is not a systemd maintainer until we iron out the kinks.
    - xx_ns 2y ago
      Thanks! The slow startup times have usually been an xdg-desktop-portal issue for me in the past, might be worth looking into.
- vaylian 2y ago
  How does the update process work? Do you run pacman -Syu and then bake the result into the next image with mkiso?
  - DaanDeMeyer 2y ago
    mkosi runs pacman for you and then packs up the result as a disk image. It also builds a unified kernel image and does a bunch of signing. The new /usr partition and UKI are then installed with systemd-sysupdate.

cedws 2y ago

I’m somewhat a fan of systemd and I’m interested in immutable images, but I don’t want to build systemd from source: >Sometimes ParticleOS adopts systemd features as soon as they get merged into systemd without waiting for an official release. As a result it's recommended to build systemd from source when building ParticleOS to make sure all required features are supported

palata 2y ago
> I’m somewhat a fan of systemd As in: "you've tried alternatives and you really think that systemd is superior", or as in "you don't see why people complain about systemd and its philosophy"? Genuinely interested, because usually people I hear say that they don't see the problem with systemd don't really have experience with the alternatives. Which makes sense: people who like being able to use alternatives tend to get screwed by systemd :-). Edit: for those downvoting, this is a genuine question. I mostly hear opinions from people who hate systemd, and those who don't generally just don't really care: "I've always used systemd and I haven't had issues". But the latter group wouldn't call themselves "fans of systemd".
- miladyincontrol 2y ago
  Blatantly not the person you're asking, but once you go past basic service management trying to do it just about anywhere else is an absolute and total nightmare. People who have major problems with systemd more than anything just ever seem confused, often vastly overestimating systemd's actual scope. The reality to many is its the simplest simple way to handle some very complex tasks, and the vast majority of it is still all so very very much optional even in the most 'systemd heavy' distros.
- TheDong 2y ago
  Not the person you're asking, but I'm curious what you mean when you say "the alternatives". I've used runit, openrc, briefly upstart (what a trashfire that was), and I don't miss a single thing about them while writing systemd unit files. I've used GNU Shepherd on Guix, and honestly, meh, systemd feels way more pragmatic. I've also used systemd-networkd as well as NetworkManager, and feel like they both still have a few warts, but overall prefer systemd-networked on servers. I've used grub, refit, and systemd-boot, and gotta say systemd-boot is my preference there too. I haven't really used systemd portable services, but I've used docker and don't like it, and my overall impression is I'll probably like portable services more. Are there other alternatives I have to use before I'm allowed to have an opinion? What alternatives have you used which made you feel so enlightened?

leoedin 2y ago

I work in the embedded space. I'd absolutely love to have a tool to build immutable, signed distro images which I can push to devices with a/b style updates. I imagine you can do this with mkosi, but it doesn't quite feel like the intended use case. Most immutable distros (this included) are developed with the idea that you'd run local commands on the machine, and update a single OS image in place. That gets pretty unwieldy to manage across a fleet of devices. Right now the industry standard tooling for building truly immutable images for embedded devices is Yocto. It works well, but it's incredibly complicated and has ridiculous build times because it insists on building every single package from source. It's utter madness that building a Linux image for a common ARM64 processor requires me to compile the Rust compiler myself.

weikju 2y ago
If only Tiny Core Linux had had better tooling and if only corporations liked simplicity, it might have been more popular…
- vbezhenar 2y ago
  Bulidroot is popular and simple alternative. But corporations prefer complexity.
  - dijit 2y ago
    We at darkscience used buildroot for a simple ZNC SBC[0] distribution which we deployed to an Orange Pi Zero that we sold at 33C3[1]. It was great! I highly recommend! It didn't take long to get started and while the compile times were pretty large (wonder if NIX or Bazel could help here?) it ended up with absolutely microscopic resource requirements. [0]: https://git.drk.sc/Derecho/irc-sbc-buildroot https://git.drk.sc/Derecho/irc-sbc-buildroot [1]: https://media.ccc.de/c/33c3 https://media.ccc.de/c/33c3
    - sam_bristow 2y ago
      I've had a reasonable amount of luck with a combination of Buildroot and Bazel. I use Buildroot to assemble a minimal Base OS with just the kernel, bootloader and a few system services. Then the application layer is built with Bazel and assembled into a set of squashfs images which are mounted as overlay filesystems at boot time. The whole thing is shipped as a SWUpdate file built with the Bazel layer. Because most of the iteration is happening in the Bazel layers I can generate a full system update in about 15 seconds with everything being fully reproducible.

bfrog 2y ago

Nix would let you do just this already with potential binary cache and reproducibility. I’m surprised it’s not more widely used for embedded. Maybe due to larger images? That’s a solvable problem. Maybe best of all it’s fast. Yocto is painfully slow.

klysm 2y ago
I'm not sure nix is aimed at the same kind of things here. ParticleOS seems to be a logical continuation of the effort that systemd has been putting into TPM2, boot security, signing, and immutability.

vaylian 2y ago

Is ParticleOS also a useful everyday driver for Linux enthusiasts who aren't systemd developers? Let's say I got bored with Gentoo and I want to try something new. Is ParticleOS something that a technical user would enjoy at the current stage?

DaanDeMeyer 2y ago
I think you'll get the most out of this at the moment if you're interested in actively contributing to systemd. There's lots of work left to be done to make this usable which will just be annoying if you aren't interested in fixing some of this stuff yourself. Of course if you're interested in doing small prs and such to improve things then I think it could be very satisfying. You can always join the mkosi matrix channel to chat more about this stuff.