This looks cool, I like this... but if I read the screenshot correctly, it took them 12 seconds from initrd to fully loaded. Maybe this would make sense there, but my laptop boots so fast, those 12 seconds are like two seconds. It would take longer to render the screen than it would just spraying its usual text to the VT.
(Honestly, it spends more time in uefi preboot than it does to actually boot the system.)
kodoman 27 minutes ago [-]
I usually don't like TUI's and just want outputs into emacs text buffers, but this interface is beautiful, A nice thing to glance at that tells you everything you need to know about your systemd units. Well done.
origini 27 minutes ago [-]
Like it :)
What i don't get is why booting still takes seconds. When power is on, the hardware is on.
You can initalize most hardware in parallel, reading the amount of operation system into ram is fast.
reacharavindh 2 hours ago [-]
Love it.
Now I need to figure out if I can do a similar thing with OpenRC. Thanks for the inspiration.
account42 48 minutes ago [-]
Come to think of it I don't think I even have parallel boot enabled on my OpenRC systems since the Linux boot time is so much shorter than whatever the BIOS does before it hands control over (or before it even displays anything on some machines).
TacticalCoder 12 minutes ago [-]
> ... Linux boot time is so much shorter than whatever the BIOS does before it hands control over
On which system? Is your machine, for whatever reason, re-doing "memory training" everytime it boots? This is one can be really slow.
account42 2 minutes ago [-]
Who knows, but any desktop and laptop I had access to in the last decade spent more time in POST or whatever than it does in OpenRC. Might be more of a case of the Linux bootup with a minimal set of services I actually need already being pretty fast even without paralellism rather than those BIOS being particularly slow. Windows for example is a lot slower there from my experience - and the difference is even more ridiculous for shutdown.
throwa356262 44 minutes ago [-]
This is very cool. It should be the new default on all distros.
It may terrify windows and osx refugees, but that's a sacrifice I am happy to make ;)
nehal3m 11 minutes ago [-]
This also tickles some part of my brain that likes watching spinners, and it gives you an intuitive idea of what’s happening on your system. But for those who find it scary you could just default to a splash.
jeffrallen 2 hours ago [-]
I hate systemd with a burning passion, but this is the first time I ever thought it might be slightly redeemed.
gavinsyancey 2 hours ago [-]
> I hate systemd with a burning passion
Why?
bayindirh 1 hours ago [-]
Not the OP, but to provide a short perspective:
- Too many parts.
- Doing too many things, sometimes poorly.
- Fights with other services, no graceful fallback & logging (i.e. aggressive).
- As a result, unnecessarily complex, brittle and fragile.
- Harder to secure (at code level) than simpler tools.
- Project is too aggressive and want to replace any and every service.
- Sometimes break in unexpected ways.
- Not faster than Parallel Sys-V.
We can discuss these. I'm not the one who wants flame wars.
origini 25 minutes ago [-]
I'm using systemd for ages, never had a single issue at all with it.
But do you run systemd and complain or why do you even hate it?
its linux right, if a linux distribution decides to use it, its not systemds fault to be used and if you use it and don't take the time and effort to have it your way, you shouldn't complain either?
preisschild 48 minutes ago [-]
It has the exact right amount of parts. A modern Operating system just has a lot more to cover than 1970's Unix...
I can remember having to deal with SysVinit and thank god for Poettering and all the other systemd maintainers for bringing the Linux ecosystem to the 21st century
kodoman 33 minutes ago [-]
I think the reasonable argument is not old thing is better ( like some people make, but it has its own problems that are usually because of it trying to do everything.
My main issues stem from it's prevalence in server Distro's especially for micro service images.
D-bus is one of the great offenders for me and I don't like having it on even my desktop system but systemd wants it for many things and some things will just break without it. On a small micro service image, it would be nice to be able to strip lots of it down but systemd fights you on this because of the amount of moving parts and interconnected subs-sytems it introduces.
bayindirh 29 minutes ago [-]
I concur. My main pain point is the size and aggressiveness of the whole "subsystem". I compare it to Sys-V init, because it's the best example I have used until systemd.
kodoman 15 minutes ago [-]
I have been finding myself more and more reaching for alpine linux and have liked openrc.
I am a nixos user so have to use systemd on nixos and that makes it very painful, but I can see myself moving away nixos as my host machines os for many reasons but systemd and the painful way nixos uses it is a big one.
bayindirh 43 minutes ago [-]
It doesn't have to replace the cron, resolver, time synchronization, system logs, bootloader, home folder management, all of the disk encryption, TPM, signing, users, and a whole lot to manage services.
I can understand the frustrations with Sys-V init scripts, but on the other hand, I never had a problem with that both as a sysadmin and a distribution developer.
To be honest, loginctl allowed us to pull some hacks, but to be fair, that hacks were to handle bad behavior from a very bad codebase. Any self-respecting development team wouldn't have written anything which needed OS/kernel level reaping to clean from system correctly.
We have been chatting recently, and someone who's more experienced than me said that they have never seen Nixie's cron to die spontaneously in the last 30 years. systemd's timers not only did that, the systemd didn't bother to restart it. Ironic, considering that the biggest feature of systemd is service supervision and unattended recovery.
torcete 25 minutes ago [-]
I reckon using cron vs systemd timers is a good example of some of the points above.
jimis 60 minutes ago [-]
+ Harder to debug/trace than initscripts.
account42 50 minutes ago [-]
+ "My way or the highway" attitude from the developers
kodoman 41 minutes ago [-]
> Why?
The thing with the whole systemd hate thing is everyone now knows why people might hate systemd (I am not a fan). I think a lot of features around isolation and systemd containers where useful but now probably using your containerization system that best suits your needs.
For me when I get really mad at it is when I want to build small nixos Images and want to minimize the footprint of systemd and run few services (some of that is on nixos as well).
I think it's better suited for desktop systems then server systems and it's quite annoying how prevalent it is. D-bus is one thing that always annoys me and how everything in systemd wants to use it and you can run into issues disabling it (Also don't like D-bus even on a desktop system).
Overall I think and hope we will see a rise not necessarily in openrc but in simpler init 1 systems that try to do less and provide good strong primitives that allow for easily using what ever daemon configured how you want, rather then trying to provide coupled implementations for everything.
Again I know these criticism are something of a meme, but they still are true.
TacticalCoder 2 minutes ago [-]
The XZ backdoor. That's why.
Only Rube-Goldberg complexity on the scale of systemd made the XZ backdoor possible. Systemd was made by despicable individuals who went on to work for despicable companies (as a big fuck you to open-source lovers) and then later on to work on even more despicable surveillance project (as a big fuck you to humanity).
systemd has its tentacles meddling in every single part of the Linux ecosystem.
But thankfully there's light at the end of the tunnel: thanks to VMs and containers and the need for speed, we've seen many minimal distros (I'm thinking stuff like Talos for Kubernetes) and those of course don't use systemd.
As soon as I get the time to switch away from my current hypervisor (Proxmox, so Debian, so systemd) to an hypervisor not running under Linux, like maybe bhyve on FreeBSD, I'll have all my VMs and containers and hypervisor totally systemd free (my VMs and containers are already systemd free: I did in anticipation of, at long last, giving systemd the middle finger).
But of course none of this matter much because according to HN we're already at a point in time where we can write: "Plz rewrite an init system".
The real question is: why don't people hate a rube-goldberg init system made by someone who went to work for Microsoft, while using crypto made up by his brother (certainly secure we're sure), and who then went on to create a full-on surveillance company working on locking down hardware?
Regain control of PID 1 people.
torcete 40 minutes ago [-]
I also dislike it very much.
edit: Having written that, this tool looks very cool and useful when you need to deal with a systemd distribution.
Rendered at 11:03:52 GMT+0000 (Coordinated Universal Time) with Vercel.
(Honestly, it spends more time in uefi preboot than it does to actually boot the system.)
What i don't get is why booting still takes seconds. When power is on, the hardware is on.
You can initalize most hardware in parallel, reading the amount of operation system into ram is fast.
On which system? Is your machine, for whatever reason, re-doing "memory training" everytime it boots? This is one can be really slow.
It may terrify windows and osx refugees, but that's a sacrifice I am happy to make ;)
Why?
But do you run systemd and complain or why do you even hate it?
its linux right, if a linux distribution decides to use it, its not systemds fault to be used and if you use it and don't take the time and effort to have it your way, you shouldn't complain either?
I can remember having to deal with SysVinit and thank god for Poettering and all the other systemd maintainers for bringing the Linux ecosystem to the 21st century
My main issues stem from it's prevalence in server Distro's especially for micro service images.
D-bus is one of the great offenders for me and I don't like having it on even my desktop system but systemd wants it for many things and some things will just break without it. On a small micro service image, it would be nice to be able to strip lots of it down but systemd fights you on this because of the amount of moving parts and interconnected subs-sytems it introduces.
I am a nixos user so have to use systemd on nixos and that makes it very painful, but I can see myself moving away nixos as my host machines os for many reasons but systemd and the painful way nixos uses it is a big one.
I can understand the frustrations with Sys-V init scripts, but on the other hand, I never had a problem with that both as a sysadmin and a distribution developer.
To be honest, loginctl allowed us to pull some hacks, but to be fair, that hacks were to handle bad behavior from a very bad codebase. Any self-respecting development team wouldn't have written anything which needed OS/kernel level reaping to clean from system correctly.
We have been chatting recently, and someone who's more experienced than me said that they have never seen Nixie's cron to die spontaneously in the last 30 years. systemd's timers not only did that, the systemd didn't bother to restart it. Ironic, considering that the biggest feature of systemd is service supervision and unattended recovery.
The thing with the whole systemd hate thing is everyone now knows why people might hate systemd (I am not a fan). I think a lot of features around isolation and systemd containers where useful but now probably using your containerization system that best suits your needs.
For me when I get really mad at it is when I want to build small nixos Images and want to minimize the footprint of systemd and run few services (some of that is on nixos as well).
I think it's better suited for desktop systems then server systems and it's quite annoying how prevalent it is. D-bus is one thing that always annoys me and how everything in systemd wants to use it and you can run into issues disabling it (Also don't like D-bus even on a desktop system).
Overall I think and hope we will see a rise not necessarily in openrc but in simpler init 1 systems that try to do less and provide good strong primitives that allow for easily using what ever daemon configured how you want, rather then trying to provide coupled implementations for everything.
Again I know these criticism are something of a meme, but they still are true.
Only Rube-Goldberg complexity on the scale of systemd made the XZ backdoor possible. Systemd was made by despicable individuals who went on to work for despicable companies (as a big fuck you to open-source lovers) and then later on to work on even more despicable surveillance project (as a big fuck you to humanity).
systemd has its tentacles meddling in every single part of the Linux ecosystem.
But thankfully there's light at the end of the tunnel: thanks to VMs and containers and the need for speed, we've seen many minimal distros (I'm thinking stuff like Talos for Kubernetes) and those of course don't use systemd.
As soon as I get the time to switch away from my current hypervisor (Proxmox, so Debian, so systemd) to an hypervisor not running under Linux, like maybe bhyve on FreeBSD, I'll have all my VMs and containers and hypervisor totally systemd free (my VMs and containers are already systemd free: I did in anticipation of, at long last, giving systemd the middle finger).
But of course none of this matter much because according to HN we're already at a point in time where we can write: "Plz rewrite an init system".
The real question is: why don't people hate a rube-goldberg init system made by someone who went to work for Microsoft, while using crypto made up by his brother (certainly secure we're sure), and who then went on to create a full-on surveillance company working on locking down hardware?
Regain control of PID 1 people.
edit: Having written that, this tool looks very cool and useful when you need to deal with a systemd distribution.