401–410 of 416 posts
Earlier quoted context omitted.
If there are so many such instances, surely you must have one that comes readily to mind, then.
I can do gainsaying too: surely you didn't look through these comments and the huge number of previous HN threads on this huge topic. Do your own work.
I have read the first couple pages of these results. Would like you like to highlight one of these in particular?
Earlier quoted context omitted.
.. and that opinion is a great explanation of why systemd won. Turns out, a lot of people are not happy with "Come on man. It's been done for decades." attitude, and they wanted something new and much better. And so when something new came up, they jumped on it with both feet. It's instructive to read Debian CTTE discussion on init systems (btw I think it's best tech drama of 2013, highly recommend) - a lot of people…
> .. and that opinion is a great explanation of why systemd won. Completely wrong and ignorant. > Turns out, a lot of people are not happy with "Come on man. It's been done for decades." attitude, and they wanted something new and much better. And then they got systemd. LOL Like Dr. Phil said, "How's that workin out for ya?" LOL > And so when something new came up, they jumped on it with both feet. You just did what…
Earlier quoted context omitted.
SysVInit on Linux isn’t true Unix though as the way it abuses runlevels to start daemons was never intended by the original designers of init.
Yeah, people forget the degree to which sysvinit was hated at the time - "why are you forcing me to deal with an impenetrable forest of symlinks rather than simply hand-edit a couple of basic rc scripts?!?". If the intention is to create a system that users can reason about, then sysvinit offers the worst of all possible worlds.
Run levels. That's it, sysvinit is about run levels. Each run level starts or kills off its own specific list of runnable things like applications, daemons, capabilities, etc.
Run levels were a desirable feature back in the day amongst System V Unix vendors, so each run level required its own kill and start scripts for each item. Run levels, for example, could take a running system from single user (root admin) mode to multi-user, multi-login, NFS sharing, full X11 mode in one command immediately as the scripts ran. This allowed rapid reconfiguration of a system, such as from a GIS workstation to a headless file server, etc. etc. as needed. Each system could be configured to boot to a specific run level. Rather than duplicate some or all such scripts across some or all run levels, symlinks were the solution.
For example, Solaris had run levels 0 through 6. Zero was a blunt force system halt; 1 was single root user admin mode; 2 was multi-user headless mode with NFS; 3 was multi-user X11 windows mode with NFS; 4 was unspecified and therefore kept for purely local configuration as desired; 5 was a planned, orderly system shutdown; and 6 was a planned, orderly system reboot. The root user could implement their choice of run level directly with the init command.
Each run level had its own run control directory (rc.d) under /etc/rc.d for its appropriate kill and start scripts, which were run in order of their K or S number, so dependencies had to be kept in mind when numbering, and curing a dependency failure was as simple as changing a script's number to rearrange the list. So, why copy S04blahblah from rc2.d to rc3.d when a symlink is far better?
Its not hard to understand when you get the big picture, and it wasn't hard to administer if you had the proper overview of it all. Admittedly, admins coming in cold would have to sort through it all, which is partly why it gained a reputation for murkiness when not properly documented by/for local admins. Keep in mind it was the era of administering sendmail macros and NIS tables by hand and you get the picture.
NOTE: edited for clarity
Earlier quoted context omitted.
Runit is 5474 SLOCs. Most source files are shorter than 100 lines. Works like a charm. Implements an init system; does not replace DNS, syslog, inetd, or anything else. Systemd, by construction, is a set of Unix-replacing daemons. An ideal embedded system setup is kernel, systemd, and the containers it runs (even without podman). This makes sense, especially given the Red Hat's line of business, but it has little rel…
> Implements an init system; does not replace DNS, syslog, inetd, or anything else Neither does systemd its init. Unknowledgeable people keep confusing systemd the init and systemd the daemon / utility suite. You can use just the init system without pulling in resolved or networkd or whatever. Systemd is the Unix philosophy of lots of modularity. But because all the systemd daemons come from the same shop, you get a…
That's how vendor lock-in works, in which a myth is propagated that having it all come from under one roof is best. In fact, it is a guarantee that best-of-breed alternative solutions cannot be used. Interoperability is thwarted. This is why sensible Unix admins historically knew to keep options open for mixed-vendor sourcing as long as the bosses didn't get roped in to a single vendor or source.
Earlier quoted context omitted.
It's always a little amusing when the Open Source Tea Party bemoans the lack of "the UNIX way" and someone else with actual historical experience (and not misguided nostalgia) brings perspective. On a related note, X11 was never good and there's a whole chapter in the UNIX-HATERS Handbook explaining why.
It was never good? Weird. Works fine for me. When will Wayland earn the label "good"? I don't think it currently qualifies.
1. You're using X11 with hardware that is fantastically newer than anything available at the time the UNIX-HATERS Handbook was written.
2. Every graphics vendor that still supports X11 is shipping workarounds for bugs in Xorg.
I used to have a citation for that second one but it went away when Hector Martin dropped off the face of the Internet.
Earlier quoted context omitted.
Is it? What's the connection between systemd and having a desktop?
Read the article: "The second reason for dropping System V is that packages like GNOME and soon KDE's Plasma are building in requirements that require capabilities in systemd"
Kind of related: The Great Debian Init Debate https://aaonline.fr/search.php?search&criteria[sequenceId-is... >
Earlier quoted context omitted.
No software is perfect. Not sysvinit (and it's bash scripts from different vendors), nor systemd. Errors happen. At least for me systemd is a net positive.
> No software is perfect Especially when it's a giant blob of buggy C code written by a known hack who has multiple decades' worth of history of foisting shit code upon a less than enthused public. > At least for me systemd is a net positive For the moment. Just wait until it finds a way to fuck you. It's plotting and scheming behind your back to do so as we speak. Systemd for some reason seems to uniquely be the epi…
I am very sorry to inform you but efivarfs is something coming from the Linux kernel. Being able to rm -rf it is squarely something that is entirely on the kernel implementation, WHICH THE AUTHOR OF EFIVARFS EVEN ADMITS[0]