121–130 of 416 posts
Earlier quoted context omitted.
It's a pretty good example of why people think systemd is bloated and does too much. It's a simple boot entry multiplexer. Does it need to live in systemd's tree?
Nobody complains about a very wide variety of only vaguely related utilities being in the Gnu coreutils tree.
But, who is counting?
Earlier quoted context omitted.
and grub is a rotting pile while systemd-boot is a simple boot entry multiplexer that rides off the kernel's capability of being run as an EFI executable, it just happens to live in systemd's tree. not a good example
It's a pretty good example of why people think systemd is bloated and does too much. It's a simple boot entry multiplexer. Does it need to live in systemd's tree?
Earlier quoted context omitted.
From an education standpoint for those who really, really want to understand, the *BSD init and SysVinit systems require direct human administration. You break it, you fix it. Then, and only then, does learning systemd's ''then something happens behind the curtain'' type of automation make sense. If the student decides that one is more suitable than the other(s), they've done so from an enlightened vantage point.
I thought systemd was fairly straightforwards, even if it does too many different things for my tastes. What's an example of it doing a too much magic behind the curtain thing?
Earlier quoted context omitted.
> Well to be fair, you don't need to understand how SystemD is built to know how to use it. The attitude that you don't need to learn what is inside the magic black box is exactly the kind of thing LFS is pushing against. UNIX traditionally was a "worse is better" system, where its seen as better design to have a simple system that you can understand the internals of even if that simplicity leads to bugs. Simple syst…
LFS is full of packages that fit your description of a black box. It shows you how to compile and configure packages, but I don't remember them diving into the code internals of a single one. I understand not wanting to shift from something that is wholly explainable to something that isn't, but it's not the end of the world.
Earlier quoted context omitted.
systemd is not a monolith, and distros make different choices on what portions of systemd they which to ship and enable by default. For example, not all distros ship and use systemd-resolved by default, to choose from your list.
systemd-boot competes with grub
Earlier quoted context omitted.
LFS is full of packages that fit your description of a black box. It shows you how to compile and configure packages, but I don't remember them diving into the code internals of a single one. I understand not wanting to shift from something that is wholly explainable to something that isn't, but it's not the end of the world.
No, its not the end of the world. And I agree, LFS isn't going to be the best resource for learning how a compiler works or cron or ntp. But the init process & systemd is so core to linux. I can certainly see the argument that they should be part of the "from scratch" parts.
They still explain what an init system is for and how to use it.
Earlier quoted context omitted.
Didn't you find though that systemd was just a black box? I was hoping to learn more about it as well- and I did manage to get a fully baked LFS CLI system up and running, and it was just like "ok install systemd..." and now... it just goes. Sysv at least gave you a peak under the covers when you used it, and while it may have given people headaches and lacked some functionality, was IMHO simple to understand. Of cou…
> "ok install systemd..." and now... it just goes. I believe it's `systemctl list-unit-files` to see all the config that's executed, included by the distro, and then if you want to see the whole hierarchy `systemd-analyze dot | dot -Tpng -o stuff.png` To me, seems much easier to understand what's actually going on, and one of the benefits of config as data rather than config as scripts.
The only other page that covers it is how to compile it and it install it (make configure, make, make install essentially- with a bunch of flags).
It kind of touches upon a few commands that will let you know what its doing and how to get it started, but from this page you don't learn much about how it works.
In fact, one of my takeaways from LFS was that I already kind of knew how a linux system starts... and what I really wanted to learn was how the devices are discovered and configured upon startup to be used, and that is pretty much all done in the black box that is SystemD.
Earlier quoted context omitted.
If we look on LFS for its academic merit, I'm saddened that key historical elements of Unix/Linux design are being left behind, much like closing down a wing of a laboratory or museum and telling students that they'll need to whip up their own material to fill in those gaps.
From the announcement, it saddens them too: > As a personal note, I do not like this decision. To me LFS is about learning how a system works. Understanding the boot process is a big part of that. systemd is about 1678 "C" files plus many data files. System V is "22" C files plus about 50 short bash scripts and data files. However the reasoning they provide makes sense.. It's hard to build a Linux system with a deskt…
Earlier quoted context omitted.
How is this best? It defeats the whole point. I’m going to stop recommending LFS to people wanting to learn about this stuff.
"best" meaning the best decision the LFS team can make given their limited, unpaid time and resources. They feel maintaining guides for two parallel init systems is unsustainable even though they would prefer not to have systemd as the only option.
I for one will not be strong armed into systemd or any other tech. If KDE makes it impossible for me to run without systemd, it goes into the trash bin. I will just install Trinity (KDE3) and be done with it. (Gnome deserves no consideration whatsoever.)