| |||||||||||||
GNOME and/or systemdGNOME and/or systemdPosted Nov 2, 2012 17:13 UTC (Fri) by khim (subscriber, #9252)In reply to: GNOME and/or systemd by dlang Parent article: GNOME and/or systemd
You are comparing (again) apples and oranges. replacing this with a tightly coupled set of tools that between then try and do everything just doesn't work. Commercial vendors who want to take over your entire system and have spent billions on software development haven't been able to make it work (Sun, Microsoft, IBM, Oracle, Novell, Apple and others have all tried at different times) Actually at least couple of these (Apple and Microsoft) are fine. And on desktop they are winning. Microsoft also wins on SME's servers! Why? The answer is obvious: robustness vs repairability. In the "professional" environment (where repairability is king) "loosely coupled collection of tools that each do one thing and do it well" works fine because there are people who can fix it - and it's easier to fix small thing which does "one thing well". When you move in the direction of unmaintaned devices you see only monolithic solutions - because they are more robust and there noone behind the keyboard who can fix them! Think set-top boxes: people are proud that there are so many linux-based ones, but they violate "do one thing and do it well" pretty severely - you can not introduce tighter coupling then busybox's one! Now, you may argue that even with busybox there are pieces which can be disabled and/or replaced. Sure, but systemd is designed in the same way so what's the difference? If Linux wants to win on desktop then something like systemd is strict requirement, not an option! Now, on server… I'm not sure if it's good enough or not, but if it's somehow not good enough then it's simpler to fix it rather then fight it.
(Log in to post comments)
GNOME and/or systemd Posted Nov 6, 2012 18:45 UTC (Tue) by kevlar (guest, #83261) [Link]
Systemd does violate the one thing well principle set by the Unix founders.
It also violates the no1 security rule of running as little as possible as root.
Busybox does not violate this rule because you can select every utility you want. The reason it is one binary is purely due to embedded hardware limits such as fragmented memory. Note that systemd is not ideal at all for deeply embedded systems that these set top box designers work on, though the kernel like busybox is perfectly configurable and usable on these systems to a smaller size than systemds pid1 even, and don't tell me Lennart said it's better for embedded because it isn't, check out the embedded lists like buildroot or uclinux, android uses a tiny init and android size devices actually account for a little of the embedded market.
I actually prefer OpenBSD as a desktop system to Linux however I do use Linux purely due to the dev power to provide faster and easier package and system updates for a few systems as well as the security KMS video can offer and on one system to run software that will only run on Windows/Linux.
The OpenBSD init system is great and is easily and completely followed and edited, locked down and understood from init.c and /etc/rc to rc.shutdown. Openrc and sysvinit is harder but do-able. I would be there all year with systemd.
The main problem with linux init is the human interfacing. Systemd is an improvement over upstart but I'd rather run upstart even and OpenBSDs and openrc's interface is far more intuitve and better than systemds.
The problem of sshd dying before a shutdown can be completed does not require systemd to solve and is something I have only witnessed on Linux a while ago. How about systemd hanging rather than one shell hanging on boot before sshd has started, a far more common occurence from the mailing lists.
Systemd actually offers a very poor function gain to risk ratio when you pick through the many pre-existing/stolen features and many either wrong assumptions or purposeful lies.
The majority of Linux systems (Gentoo, Debian, Ubuntu) will never run systemd so have fun marginalising Gnome and launching mate and XFCE.
Oh and moving critical statically compiled binaries into a larger /usr as encouraged by Lennart and the FSF is a function/stability mistake too. Think about it, don't take historical hype and busybox hype as given.
GNOME and/or systemd Posted Nov 6, 2012 22:24 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
> It also violates the no1 security rule of running as little as possible as root.
That's fun. Cause sysvinit runs MUCH more staff as root - bash, often perl and python, various unix utils, etc.
So thanks for supplying yet another argument why systemd is better.
GNOME and/or systemd Posted Nov 7, 2012 18:51 UTC (Wed) by nix (subscriber, #2304) [Link]
Um, I might point out that bash, Unix utilities, perl and python are routinely run as root by *normal system administrators*, so the fact that sysvinit init scripts often run them as root is not a meaningful argument against them or against sysvinit. They would pose security concerns in any case.
GNOME and/or systemd Posted Nov 7, 2012 19:00 UTC (Wed) by nix (subscriber, #2304) [Link] Well, I disagree with a substantial proportion of what you have to say.It also violates the no1 security rule of running as little as possible as root.systemd is cut into pieces precisely so that this rule is satisfied. It doesn't run things as root unless necessary. Lennart isn't an idiot. (It just runs too much *as PID 1* for me to be happy with it.) Systemd actually offers a very poor function gain to risk ratio when you pick through the many pre-existing/stolen features and many either wrong assumptions or purposeful lies.This sentence veers through a variety of logical fallacies at blistering speed:
|
|||||||||||||