systemd & the tightly couple core band vs a world of many inits
systemd & the tightly couple core band vs a world of many inits
Posted Apr 24, 2012 19:26 UTC (Tue) by oldtomas (guest, #72579)In reply to: systemd & the tightly couple core band vs a world of many inits by martin.langhoff
Parent article: Shuttleworth: Quality has a new name
To me that is the *practical side* of GNU's "freedom 1". And SysV init is definitely the most hackable of the alternatives discussed here -- all its baroque clumsiness notwithstanding (no, I'm no fan of SysV init, but in the presence of the attitudes of the proponents of systemd and upstart, it still seems the best choice. Not technically, but socially).
Posted Apr 24, 2012 20:41 UTC (Tue)
by hazeii (guest, #82286)
[Link] (24 responses)
The hood is not so much being welded shut, as everything underneath it is being made so complex and inter-related that only big companies have sufficient resources to make meaningful changes.
And that, of course, is exactly how they want it.
Posted Apr 24, 2012 20:59 UTC (Tue)
by ovitters (guest, #27950)
[Link] (3 responses)
I further do not agree things are more difficult. Having just one way of doing things across distributions should make things easier to grasp; not more difficult. Further, a lot can now just be changed with a config file instead of knowing the right shell command (e.g. instead of knowing that there is a ulimit command and you can put that in a sysvinit script instead you can now change an option in a documented config file).
Posted Apr 24, 2012 21:03 UTC (Tue)
by dlang (guest, #313)
[Link]
that's a huge change, and part of what people are objecting to.
Posted Apr 26, 2012 16:01 UTC (Thu)
by pspinler (subscriber, #2922)
[Link] (1 responses)
Except that shell knowledge is transitive, and applies to lots and lots of stuff. A 5% increase in your shell skills thus is a 5% increase in a quite large number of things.
On the other hand, systemd config files are specific to systemd, and knowledge gained there, even if it's easier to learn, is non-transitive. So I have to learn many, unrelated things to hack here. For instance, systemd config files, dbus interfaces and scripting, etc.
On the whole, I prefer the one skill set -> many areas approach.
-- Pat
Posted Apr 26, 2012 17:55 UTC (Thu)
by mpr22 (subscriber, #60784)
[Link]
Posted Apr 25, 2012 2:17 UTC (Wed)
by dgm (subscriber, #49227)
[Link] (19 responses)
Posted Apr 25, 2012 6:03 UTC (Wed)
by paulj (subscriber, #341)
[Link] (18 responses)
Posted Apr 25, 2012 6:32 UTC (Wed)
by apoelstra (subscriber, #75205)
[Link] (17 responses)
I would say rather that these are fixes to real problems affecting real desktop users -- the old ifup scripts could not handle switching between wireless networks all the time, and init was slow as a dog and (as much as we all grew to know and love it) really did involve deep magic to manage.
The point of pulse was to manage sound across multiple users and applications smoothly. There were some apps *cough*flash*cough* which would routinely hijack the audio system, and I remember often having to reboot just to get my music back. Pulse, after the first few versions of Fedora anyway, has never given me that kind of crap.
In my experience, I've always resisted these changes at first, then after a year or two, started to love them. Because after the early bugs were worked through, they really were technically superior to the old systems, and often more configurable and more flexible. Since they're new, they tend not to be so discoverable or well-documented, which I think is what most "I loved init like a child!" posters here are actually complaining about.
For example, I still can't figure out how to use NetworkManager from a command-line, so I don't. (As a result, I need to do all sorts of ugly crap when moving between networks, crap which no end-user should be required to deal with. But no end-user -is- required to, as long as they install a DE, so this is fine.)
This stuff is all open-source and freely licensed, so there's no reason for other distributions not to use it. If this is Red Hat's strategy, it's pretty stupid, since it amounts to working for free for the competition.
To compare, consider the changes Ubuntu makes. In my experience, these start out as irritating, then transition to unusable. (After Unity, I threw in the towel, and stopped using Ubuntu anywhere) so I have no idea what they've been up to in the last few years. Upstart was crashy and confusing, hard to configure and poorly documented. Unity is a complete gong show. It looks like garbage, is non-discoverable and unusable, doesn't work on most computers, depends on high-end video drivers (which are mostly proprietary), and involved special tools and BINARY BLOBS to configure. The Ubuntu attitude has always been "our way or the highway", and this attitude has gotten worse, as they deviate further and further from the mainstream, in the WRONG DIRECTION, for NO REASON.
I had technically illiterate family members using Ubuntu. At first (around the 6.06 era) it worked great. Then they started breaking things in weird ways. For a while, I was able to work around their crap, apologize profusely and insist that I was "talking to the developers" about this "completely unprofessional" behaviour. Then Unity came around, and X stopped starting, and when I went to poke around, found the system internals completely trashed. Stuff was renamed, deleted, replaced, whatever, for seemingly no other reason than to be different. Since half the stuff couldn't be configured over SSH, and I had literally no clue what the UI looked like (even though it was a stock UI), this involved me physically travelling around to maintain these computers. In the 20th century.
After dicking around for a few hours, I said "go to Futile Shop, buy a $250 refurbished computer with Windows on it".
I didn't mean for this to be a rant about Ubuntu. My point was simply that I would not blame Red Hat for being hostile and uncooperative with the community. And I would absolutely accuse Canonical of this.
Posted Apr 25, 2012 7:58 UTC (Wed)
by spaetz (guest, #32870)
[Link] (6 responses)
Not that I believe Canonical is always making the right decisions, but it is possible to run stock Gnome Shell on an unmodified Ubuntu. Personally, I run Xubuntu and I am very happy with it, even using old and crappy graphics drivers. So, you can't really claim my way or the highway when other DEs are simply making similar decisions.
Posted Apr 25, 2012 8:34 UTC (Wed)
by apoelstra (subscriber, #75205)
[Link] (5 responses)
>So, you can't really claim my way or the highway...
Without rehashing the specific arguments, I recall there being a lot of complaints in the beta release, followed by a grandiose blog post from Mark Shuttleworth, and the new buttons appeared in the final release anyway.
Of course, as the spin-off distros show, it is still possible to do your own thing with Ubuntu, provided you have the know-how.
> when other DEs are simply making similar decisions.
Yes, I should have been clearer that Unity is not alone in their silly changes. Gnome 3, Windows Metro, and any other "touchscreen" desktop environments are just as guilty of making poor UI choices. The difference is that Canonical has put a significant amount of effort into making their -own- poor UI, whereas other distributions focus their efforts on more useful pursuits.
Posted Apr 26, 2012 17:47 UTC (Thu)
by JanC_ (guest, #34940)
[Link] (1 responses)
The majority of Ubuntu users never complained about that, but a loud minority did. (Personally, I find that it's not really all that important which side these buttons are, and most people get used to it.)
Posted Apr 26, 2012 17:50 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Apr 30, 2012 15:52 UTC (Mon)
by jbicha (subscriber, #75043)
[Link] (2 responses)
Of course Unity didn't exist in 10.04 and the reasoning wasn't explained well then.
Posted Apr 30, 2012 16:03 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
Posted Apr 30, 2012 19:35 UTC (Mon)
by jbicha (subscriber, #75043)
[Link]
Posted Apr 25, 2012 7:58 UTC (Wed)
by mezcalero (subscriber, #45103)
[Link] (3 responses)
Lennart
Posted Apr 25, 2012 8:35 UTC (Wed)
by apoelstra (subscriber, #75205)
[Link] (2 responses)
Posted Apr 26, 2012 21:36 UTC (Thu)
by mgedmin (subscriber, #34497)
[Link] (1 responses)
Posted May 3, 2012 0:52 UTC (Thu)
by josh (subscriber, #17465)
[Link]
Posted Apr 25, 2012 12:08 UTC (Wed)
by james (subscriber, #1325)
[Link] (5 responses)
Posted Apr 25, 2012 15:46 UTC (Wed)
by drag (guest, #31333)
[Link]
For example:
I wouldn't even know were to start with configuring 802.1x network access controls (very different from 802.11) on Redhat and Debian and Suse, but I know I can do it all the same way on all three systems if I am using Network Manager.
Posted Apr 26, 2012 21:38 UTC (Thu)
by mgedmin (subscriber, #34497)
[Link] (3 responses)
I've read 'man nmcli'. It didn't help.
Posted Apr 26, 2012 21:47 UTC (Thu)
by nybble41 (subscriber, #55106)
[Link] (1 responses)
Posted Apr 27, 2012 1:54 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link]
[1]http://repo.or.cz/w/cnetworkmanager.git/commitdiff/e2c001...
Posted May 3, 2012 20:55 UTC (Thu)
by runciter (guest, #75370)
[Link]
Posted Apr 24, 2012 21:32 UTC (Tue)
by vonbrand (subscriber, #4458)
[Link] (9 responses)
To me, the baroque SysVinit scripts are some of the more opaque code I've ever seen. This stuff is definitively not easily hackable at all (yes, I had to tweak some of those scripts and even wrote a few very simple ones from scratch). Besides, the whole idea is very fundamentally broken: There can't be a "reasonable order for starting/shutting down services," the same way as just adding some "precedence" doesn't help a bit at figuring out the prerequisites, even less making sure they are all running OK before starting something. It was enough for SysVr4 (i.e., server-ish machines which were started in some almost unchanging configuration once a month or so), but it definitely doesn't cut it for today's ever-changing desktops.
Posted Apr 24, 2012 21:45 UTC (Tue)
by dlang (guest, #313)
[Link] (2 responses)
However, I do have trouble with the idea that if it's a good thing for (some/many) laptops, then servers and embedded devices need to use it as well.
Posted Apr 24, 2012 23:09 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link]
And I won't mind systemd's containment functionality on my servers.
For instance, a SIMPLE task like "allow the Java program started by this script to listen on port 80" is not really possible with initscripts. At least my puny brain was not able to cope with all the capability inheritance over UID change crap.
With systemd? It's easy! A few lines in the service file and you're done.
Ditto for filesystem containment and secure /tmp.
Posted Apr 25, 2012 5:33 UTC (Wed)
by misc (subscriber, #73730)
[Link]
I faced issue with sympa not starting and blocking on wait because it needed postgresql to be started first. We see issues with some daemons starting faster than the network card ( cause network service say "ok, i am ok", while it is not, Mandriva used to have a service "network-up" just for that ).
The way we set limit on file descriptor or anything is dependent on the initscript, the distribution, and usually hard to automate. With systemd, that's just .ini, in well defined location with the same and guaranteed semantics, something that is much easier to automate and to deploy.
The old approach was fragile and, stuff like "having 3 openvpn" was done by cut and paste of the initscripts, that's not really ideal IMHO. There is lots of duplicated code in all initscripts from distribution, and that's not how I envision long term maintainance. Gentoo init system was a fresh approach on that point, kudos to them, and systemd push that further.
I cannot comment on embedded device, but for a server, I see the values, even if I understand that some people feel the sysv init way to be fine for them.
Posted Apr 28, 2012 22:49 UTC (Sat)
by speedster1 (guest, #8143)
[Link] (5 responses)
I'm curious which startup scripts you ran across that were a painful mess. I've dealt with plenty of classic init scripts on RHEL/CentOS, debian, and embedded systems and none of those seemed hard to customize when needed. Plenty of startup scripts for custom services as well. Wondering if our standards for painful shell code are different, or if you were poking in an area that I never had to modify.
Posted Apr 28, 2012 23:40 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
And I still can't get why my BIND hangs during shutdown (something to do with RNDC which I just don't have energy to debug).
Posted Apr 28, 2012 23:52 UTC (Sat)
by speedster1 (guest, #8143)
[Link]
Posted Apr 29, 2012 1:21 UTC (Sun)
by jimparis (guest, #38647)
[Link]
If you're running Debian or Ubuntu: http://bugs.debian.org/570852
Posted Apr 29, 2012 10:10 UTC (Sun)
by anselm (subscriber, #2796)
[Link] (1 responses)
They are still 90% boiler plate, and distribution-specific boiler plate at that. If systemd did nothing except replacing that boiler plate with small distribution-independent configuration files (which is a minuscule part of what it actually does) it would still be a net win.
Posted Apr 29, 2012 18:29 UTC (Sun)
by speedster1 (guest, #8143)
[Link]
Boilerplate code is not automatically terrible in all situations. For projects that have lots of churn, it can be a hiding place for bugs unless there are good automated tools to ensure every instance gets updated. If the boilerplate is horribly ugly, it can make your eyes hurt from having to look at it so often.
However the init scripts on my embedded projects don't fit that category, nor RHEL init scripts for a non-embedded project, nor the init scripts on my debian server, nor the init scripts on my gentoo development station. The scripts are normal-looking shell scripts which are all the more easily understood because they follow a common pattern and well-known purpose. For a small number of already well-behaved systems (not servers that must run somewhat ill-behaved services), switching from shell scripts to denser config files may not offer any benefit.
BUT, for my embedded projects, systemd does currently offer one much more compelling feature than replacing some small easily-understood shell scripts with even smaller systemd configs: finer respawn control. Busybox init is very limited in that respect. Ability to start and stop a service (init.d), OR ability to respawn (inittab). No control over respawn timing either. In the one current project where we are able to give systemd a spin, configurable respawn policy is the actual practical advantage over sysv-style init for ; we don't have the sorts of daemons that really call for cgroup features otherwise (e.g. misbehaving child processes that don't get cleaned up properly otherwise).
Posted Apr 24, 2012 22:33 UTC (Tue)
by HelloWorld (guest, #56129)
[Link] (13 responses)
Posted Apr 24, 2012 22:40 UTC (Tue)
by dlang (guest, #313)
[Link] (12 responses)
yes, but it's one that sysadmins are very familiar with. They need it and use it for all sort of other things so your objection really doesn't matter.
systems that don't have sysadmins will probably not change the configuration anyway, so whatever the distro provides is almost always good enough for them.
Posted Apr 24, 2012 22:51 UTC (Tue)
by HelloWorld (guest, #56129)
[Link] (2 responses)
Posted Apr 25, 2012 12:36 UTC (Wed)
by sciurus (guest, #58832)
[Link]
Posted Apr 26, 2012 19:22 UTC (Thu)
by cdmiller (guest, #2813)
[Link]
Posted Apr 24, 2012 23:12 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (8 responses)
Posted Apr 24, 2012 23:26 UTC (Tue)
by dlang (guest, #313)
[Link] (6 responses)
But why do you think you have the right to dictate what other people do on their systems?
Posted Apr 25, 2012 5:28 UTC (Wed)
by cmccabe (guest, #60281)
[Link] (5 responses)
But in all seriousness, the whole "SysV init is simpler" thing just ain't true. And you can still write SysV init scripts under either Upstart or Systemd, if you feel like you must.
Posted Apr 25, 2012 11:04 UTC (Wed)
by dgm (subscriber, #49227)
[Link] (3 responses)
Init, the process, is simple. It's code is simple, because it's job is simple. And that's because the grunt work is left for the shell scripts that init runs. Init itself doesn't do much.
If you consider init, plus the directory layout conventions, plus the script conventions, plus the additional tools, then maybe init is not so much simpler than Systemd or Upstart. But all that is optional, mind you. Remember how Arjan van de Ven got his system booting to desktop in just five seconds. They did so with plain old init (and plenty of ingenuity).
Posted Apr 25, 2012 14:41 UTC (Wed)
by mezcalero (subscriber, #45103)
[Link]
Posted Apr 25, 2012 19:16 UTC (Wed)
by oldtomas (guest, #72579)
[Link]
[1] <http://en.wikipedia.org/wiki/OpenRC#Size_and_complexity>
Posted Apr 26, 2012 22:49 UTC (Thu)
by s0f4r (guest, #52284)
[Link]
Arjan and me are supporting systemd in many ways, with code, feedback, prototypes and exploration of unwritten mechanisms.
For example, at the Tizen Conference in May, I will be presenting a prototype `systemd --user` initialized desktop that entirely removes XDG autostart in favor of treating everything that starts as `a service`, even for user-started programs (such as, Xorg, your window manager, the session bus).
sysvinit didn't scale - we knew that already in 2009, which is exactly why we had been talking with Lennert and folks for a loooong time to come up with something better.
Posted Apr 25, 2012 15:40 UTC (Wed)
by jedidiah (guest, #20319)
[Link]
Init and bash are things that have had decades to show it's warts.
You just haven't given Upstart a chance yet. '-)
Posted Apr 25, 2012 7:56 UTC (Wed)
by HelloWorld (guest, #56129)
[Link]
Posted Apr 25, 2012 10:44 UTC (Wed)
by njs (subscriber, #40338)
[Link] (8 responses)
It occurs to me that this is exactly the same argument that justifies using PHP.
I don't know if that makes it more or less convincing.
Posted Apr 26, 2012 17:20 UTC (Thu)
by oldtomas (guest, #72579)
[Link] (7 responses)
Sorry. Wrong analogy: In which way is PHP code more hackable than say Perl, Python, shell or Tcl?
If the code is more or less well-written, they are more or less at the same hackability level.
OTOH, a bunch of more or less well written shell scripts, as Debians SysV init is, is infinitely more hackable than a fuzzball of 100-200 kloc for systemd and its dependencies.
Not that I am a friend of SysV init. One of the things I miss from BSD init is the possibility of letting init watch the daemons (remember respawn)?, which the newer systems are acquiring again. But the "collateral baggage" they all bring in is so unappetizing overall that I'll prefer to cling to SysV.
Posted Apr 26, 2012 17:35 UTC (Thu)
by dlang (guest, #313)
[Link]
SysV init scripts don't need to be nearly this complicated, and on other distros they aren't.
Posted Apr 26, 2012 18:21 UTC (Thu)
by njs (subscriber, #40338)
[Link]
Also, typical PHP web-pages and typical SysV init scripts probably have comparable levels of copy-pasted code...
Posted Apr 26, 2012 19:21 UTC (Thu)
by HelloWorld (guest, #56129)
[Link] (4 responses)
Posted Apr 26, 2012 19:33 UTC (Thu)
by cdmiller (guest, #2813)
[Link] (3 responses)
Posted Apr 26, 2012 20:26 UTC (Thu)
by HelloWorld (guest, #56129)
[Link] (1 responses)
Posted Apr 28, 2012 20:21 UTC (Sat)
by man_ls (guest, #15091)
[Link]
Posted Apr 26, 2012 21:21 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Remember, it's fully compatible with SysV init.
systemd & the tightly couple core band vs a world of many inits
systemd & the tightly couple core band vs a world of many inits
systemd & the tightly couple core band vs a world of many inits
systemd & the tightly couple core band vs a world of many inits
I'm inclined to suspect that the reason shell applies to so many things heavily depends on it having been the thing you could rely on to be there rather than actually being a good fit to the problem.
systemd & the tightly couple core band vs a world of many inits
systemd & the tightly couple core band vs a world of many inits
systemd & the tightly couple core band vs a world of many inits
systemd & the tightly couple core band vs a world of many inits
systemd & the tightly couple core band vs a world of many inits
systemd & the tightly couple core band vs a world of many inits
My "our way or the highway" comment was regarding Ubuntu's attitude toward user feedback -- for example, the flak they got when they moved the maximize/minimize/close buttons to the other side of the title bar.
systemd & the tightly couple core band vs a world of many inits
> attitude toward user feedback -- for example, the flak they
> got when they moved the maximize/minimize/close buttons to
> the other side of the title bar.
systemd & the tightly couple core band vs a world of many inits
systemd & the tightly couple core band vs a world of many inits
systemd & the tightly couple core band vs a world of many inits
Why?
systemd & the tightly couple core band vs a world of many inits
systemd & the tightly couple core band vs a world of many inits
systemd & the tightly couple core band vs a world of many inits
systemd & the tightly couple core band vs a world of many inits
1. People like to flame about anything Lennart has written.
2. People like to flame about NetworkManager.
3. Therefore Lennart wrote NetworkManager.
systemd & the tightly couple core band vs a world of many inits
systemd & the tightly couple core band vs a world of many inits
I still can't figure out how to use NetworkManager from a command-line, so I don't.
man nmcli should tell you how to manage it, and
https://live.gnome.org/NetworkManager/SystemSettings should tell you how to configure it through text files.
systemd & the tightly couple core band vs a world of many inits
systemd & the tightly couple core band vs a world of many inits
systemd & the tightly couple core band vs a world of many inits
systemd & the tightly couple core band vs a world of many inits
systemd & the tightly couple core band vs a world of many inits
systemd & the tightly couple core band vs a world of many inits
systemd & the tightly couple core band vs a world of many inits
systemd & the tightly couple core band vs a world of many inits
systemd & the tightly couple core band vs a world of many inits
systemd & the tightly couple core band vs a world of many inits
systemd & the tightly couple core band vs a world of many inits
systemd & the tightly couple core band vs a world of many inits
systemd & the tightly couple core band vs a world of many inits
systemd & the tightly couple core band vs a world of many inits
I've dealt with plenty of classic init scripts on RHEL/CentOS, debian, and embedded systems and none of those seemed hard to customize when needed.
A bit of boilerplate is not always a big deal, but systemd respawn is nice
systemd & the tightly couple core band vs a world of many inits
What a load of crap. sh is an *extremely* baroque and quirky language, and you have to learn a bazillion tools as well in order to write anything useful. Writing systemd unit files otoh is a piece of cake, and if you really, really need to write a shell script in order to start your daemon, systemd won't stop you.
systemd & the tightly couple core band vs a world of many inits
systemd & the tightly couple core band vs a world of many inits
Oh, it very much does. Writing sh scripts is much harder than writing simple ini-style configuration files even if you know sh. And actually, many admins know it barely enough to somehow get by. When did you last meet a sysadmin who knows the difference between cat << EOF and cat << "EOF"?
systemd & the tightly couple core band vs a world of many inits
systemd & the tightly couple core band vs a world of many inits
systemd & the tightly couple core band vs a world of many inits
systemd & the tightly couple core band vs a world of many inits
systemd & the tightly couple core band vs a world of many inits
(joke)
systemd & the tightly couple core band vs a world of many inits
systemd & the tightly couple core band vs a world of many inits
systemd & the tightly couple core band vs a world of many inits
systemd & the tightly couple core band vs a world of many inits
systemd & the tightly couple core band vs a world of many inits
systemd & the tightly couple core band vs a world of many inits
systemd & the tightly couple core band vs a world of many inits
Hackability
Hackability
Hackability
Hackability
That's just a lie. If you want to compare systemd and sysvinit in a meaningful way, you can't just look at the source code of sysvinit and the init scripts. You also have to include the shell which runs the init scripts and all tools called from therein (i. e. cat, sed, awk and whatnot). And if you do that, it turns out that the sysvinit solution is much, *much*, *MUCH* bigger and definitely less hackable than systemd.
Hackability
Hackability
In the context of hackability it makes perfect sense; if you never had to recompile then you never did hack systemd. To hack on SysV init you just change a script (and you don't have to recompile bash).
Hackability
Hackability