systemd & the tightly couple core band vs a world of many inits

Posted Apr 24, 2012 14:55 UTC (Tue) by martin.langhoff (guest, #61417)
Parent article: Shuttleworth: Quality has a new name

I find both Mark's and Lennart's comments un-enlightening. As part of OLPC (using Fedora) and long time Debian/Ubuntu user, this topic has my attention.

Even if you like systemd, it is clear to see that it is a very bold bet; it leads to a tightly coupled "core distro". This tight coupling is hard for Debian to manage, and would be very hard for Ubuntu to fork from Debian over this.

There are a number of folk in the Linux ecosystem pushing for a small core of tightly coupled components to make the core of a modern linux distro. The idea is that this "core distro" can evolve in sync with the kernel, and generally move fast. This is both good for the overall platform and very hard to implement for the "universal" distros.

If you want to fast-track to a modern, competitive product, this "core distro" model is a winner. If you want not just the opportunity but the _concurrent shipping_ of many possible/competing implementations of core distro components, then it is unacceptable.

OLPC's team is shipping a "vertically integrated" product, we want to move fast and our system to use the latest smarts of the kernel and the whole stack. Debian is still catering to sysadmins and developers running quirky setups (FreeBSD kernels, alternative inits...).

This is the root of the divide. It is not pretty, and my best guess is that it will take a while to shake out. Hopefully not too long.

to post comments

systemd & the tightly couple core band vs a world of many inits

Posted Apr 24, 2012 19:26 UTC (Tue) by oldtomas (guest, #72579) [Link] (58 responses)

Very insightful overall. There's one aspect I often miss in this discussions, and that's hackability: a low-key entry path for folks who are not yet at the level of checking out C code and managing a patched version.

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).

systemd & the tightly couple core band vs a world of many inits

Posted Apr 24, 2012 20:41 UTC (Tue) by hazeii (guest, #82286) [Link] (24 responses)

Hear hear; the 'hackability' of linux (distros) is reducing fast.

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.

systemd & the tightly couple core band vs a world of many inits

Posted Apr 24, 2012 20:59 UTC (Tue) by ovitters (guest, #27950) [Link] (3 responses)

I'm pretty sure the people who want to hack on things will still be able to; doesn't matter if they are paid by a company or not.

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).

systemd & the tightly couple core band vs a world of many inits

Posted Apr 24, 2012 21:03 UTC (Tue) by dlang (guest, #313) [Link]

it may be nicer if you start learning things that way, but you have to know to go looking into the systemd documentation for this, and in the process ignore everything that you find in Unix/Linux documentation that predates systemd.

that's a huge change, and part of what people are objecting to.

systemd & the tightly couple core band vs a world of many inits

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

systemd & the tightly couple core band vs a world of many inits

Posted Apr 26, 2012 17:55 UTC (Thu) by mpr22 (subscriber, #60784) [Link]

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

Posted Apr 25, 2012 2:17 UTC (Wed) by dgm (subscriber, #49227) [Link] (19 responses)

What a ridiculous claim. Why on Earth would a "big company" that makes a living on the work of volunteers, want to woo away those volunteers? That's not only stupid, it would be suicidal!

systemd & the tightly couple core band vs a world of many inits

Posted Apr 25, 2012 6:03 UTC (Wed) by paulj (subscriber, #341) [Link] (18 responses)

A few RedHat employed hackers now have raised concerns about Canonicals' ability to maintain the software they need to (including Lennart, in this post of his). It's at least well within the realms of possibility that RedHat has adopted a strategy of using their superior engineering resources to try exhaust those of their smaller rival, by re-engineering as many aspects of the Linux stack with closely-coupled and/or more monolithic systems.

systemd & the tightly couple core band vs a world of many inits

Posted Apr 25, 2012 6:32 UTC (Wed) by apoelstra (subscriber, #75205) [Link] (17 responses)

I assume you are referring to Lennart's changes: NetworkManager, pulse, systemd and friends.

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.

systemd & the tightly couple core band vs a world of many inits

Posted Apr 25, 2012 7:58 UTC (Wed) by spaetz (guest, #32870) [Link] (6 responses)

> Ubuntu attitude has always been "our way or the highway", and this attitude has gotten worse

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.

systemd & the tightly couple core band vs a world of many inits

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...
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.

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.

systemd & the tightly couple core band vs a world of many inits

Posted Apr 26, 2012 17:47 UTC (Thu) by JanC_ (guest, #34940) [Link] (1 responses)

> 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.

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.)

systemd & the tightly couple core band vs a world of many inits

Posted Apr 26, 2012 17:50 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

I see that most Ubuntu users around me just adjusted the settings using regedit^W gsettings.

systemd & the tightly couple core band vs a world of many inits

Posted Apr 30, 2012 15:52 UTC (Mon) by jbicha (subscriber, #75043) [Link] (2 responses)

For full-screen windows in Unity, the minimize/maximize buttons make the most sense in the top left corner.

Of course Unity didn't exist in 10.04 and the reasoning wasn't explained well then.

systemd & the tightly couple core band vs a world of many inits

Posted Apr 30, 2012 16:03 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

>For full-screen windows in Unity, the minimize/maximize buttons make the most sense in the top left corner.
Why?

systemd & the tightly couple core band vs a world of many inits

Posted Apr 30, 2012 19:35 UTC (Mon) by jbicha (subscriber, #75043) [Link]

The entire top right side is taken up with "indicator" status menus, which frees up the top left corner as a hot corner for the minimize/maximize/close buttons.

systemd & the tightly couple core band vs a world of many inits

Posted Apr 25, 2012 7:58 UTC (Wed) by mezcalero (subscriber, #45103) [Link] (3 responses)

I didn't write NetworkManager.

Lennart

systemd & the tightly couple core band vs a world of many inits

Posted Apr 25, 2012 8:35 UTC (Wed) by apoelstra (subscriber, #75205) [Link] (2 responses)

My mistake. I (mis)read somewhere that you had.

systemd & the tightly couple core band vs a world of many inits

Posted Apr 26, 2012 21:36 UTC (Thu) by mgedmin (guest, #34497) [Link] (1 responses)

It's an easy mistake:
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

Posted May 3, 2012 0:52 UTC (Thu) by josh (subscriber, #17465) [Link]

For much the same reasons, really. NetworkManager, systemd, and pulseaudio all follow a similar policy of "no hacking around broken kernel code, fix the kernel". In all three cases, that policy results in occasional short-term breakage and "doesn't work for me", and long-term awesomeness.

systemd & the tightly couple core band vs a world of many inits

Posted Apr 25, 2012 12:08 UTC (Wed) by james (guest, #1325) [Link] (5 responses)

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

Posted Apr 25, 2012 15:46 UTC (Wed) by drag (guest, #31333) [Link]

Network-Manager is awesome on a server.

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.

systemd & the tightly couple core band vs a world of many inits

Posted Apr 26, 2012 21:38 UTC (Thu) by mgedmin (guest, #34497) [Link] (3 responses)

Please tell me how I can connect to a WPA2-protected network with a passphrase using nmcli. Please.

I've read 'man nmcli'. It didn't help.

systemd & the tightly couple core band vs a world of many inits

Posted Apr 26, 2012 21:47 UTC (Thu) by nybble41 (subscriber, #55106) [Link] (1 responses)

I am not familiar with nmcli, but cnetworkmanager[1] can connect to WPA networks with passphrases from the command-line, using NetworkManager. It has a fairly simple, high-level interface.

[1] http://vidner.net/martin/software/cnetworkmanager/

systemd & the tightly couple core band vs a world of many inits

Posted Apr 27, 2012 1:54 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

nmcli is the successor to cnetworkmanager[1]. nmcli cannot yet make new connection configurations on its own.

[1]http://repo.or.cz/w/cnetworkmanager.git/commitdiff/e2c001...

systemd & the tightly couple core band vs a world of many inits

Posted May 3, 2012 20:55 UTC (Thu) by runciter (guest, #75370) [Link]

I'd like to recommend wicd with wicd-curses. Managing wireless connections has been a pleasure ever since I discovered it.

systemd & the tightly couple core band vs a world of many inits

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.

systemd & the tightly couple core band vs a world of many inits

Posted Apr 24, 2012 21:45 UTC (Tue) by dlang (guest, #313) [Link] (2 responses)

I have no trouble with the idea that desktops/laptops/tablets want to do things differently then how servers have done it for years.

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.

systemd & the tightly couple core band vs a world of many inits

Posted Apr 24, 2012 23:09 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

My embedded devices use SystemD for socket activation and startup. It works really really great.

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.

systemd & the tightly couple core band vs a world of many inits

Posted Apr 25, 2012 5:33 UTC (Wed) by misc (subscriber, #73730) [Link]

With software such as bind ( where you never can be sure that it got shutdown thanks to the rdnc message passing system to close it ), or apache, where I routinely see restart being blocked by some child that only arcane shell can kill, I would be among the first to celebrate systemd and cgroup controled process on the server.

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.

systemd & the tightly couple core band vs a world of many inits

Posted Apr 28, 2012 22:49 UTC (Sat) by speedster1 (guest, #8143) [Link] (5 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).

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.

systemd & the tightly couple core band vs a world of many inits

Posted Apr 28, 2012 23:40 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

How about Postfix or something like Tomcat or Jetty?

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).

systemd & the tightly couple core band vs a world of many inits

Posted Apr 28, 2012 23:52 UTC (Sat) by speedster1 (guest, #8143) [Link]

Never dealt with any of those, so maybe my running services are just better behaved and don't require twisted setup scripts... exim, dovecot, lighttpd, dhcp, dnsmasq, apache, mysql, nfs, upnp, vnc, mdadm etc

systemd & the tightly couple core band vs a world of many inits

Posted Apr 29, 2012 1:21 UTC (Sun) by jimparis (guest, #38647) [Link]

> And I still can't get why my BIND hangs during shutdown

If you're running Debian or Ubuntu: http://bugs.debian.org/570852

systemd & the tightly couple core band vs a world of many inits

Posted Apr 29, 2012 10:10 UTC (Sun) by anselm (subscriber, #2796) [Link] (1 responses)

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.

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.

A bit of boilerplate is not always a big deal, but systemd respawn is nice

Posted Apr 29, 2012 18:29 UTC (Sun) by speedster1 (guest, #8143) [Link]

If you mean net win on the large scale, for developers of large distros, I'd agree with you. However there are other niches where systemd would not win on that basis.

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).

systemd & the tightly couple core band vs a world of many inits

Posted Apr 24, 2012 22:33 UTC (Tue) by HelloWorld (guest, #56129) [Link] (13 responses)

> And SysV init is definitely the most hackable of the alternatives discussed here -- all its baroque clumsiness notwithstanding
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

Posted Apr 24, 2012 22:40 UTC (Tue) by dlang (guest, #313) [Link] (12 responses)

> sh is an *extremely* baroque and quirky language, and you have to learn a bazillion tools as well in order to write anything useful.

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.

systemd & the tightly couple core band vs a world of many inits

Posted Apr 24, 2012 22:51 UTC (Tue) by HelloWorld (guest, #56129) [Link] (2 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.
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

Posted Apr 25, 2012 12:36 UTC (Wed) by sciurus (guest, #58832) [Link]

Variable interpolation. Don't underestimate the sysadmin's ability to memorize arcana. :-)

systemd & the tightly couple core band vs a world of many inits

Posted Apr 26, 2012 19:22 UTC (Thu) by cdmiller (guest, #2813) [Link]

Hmm, that would be every sysadmin in our shop, including the primary Windows server admin.

systemd & the tightly couple core band vs a world of many inits

Posted Apr 24, 2012 23:12 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (8 responses)

As a sysadmin maintaining a big money-sucking cluster on Amazon EC2, I wish to go back in time and exterminate EVERYONE who thinks that shell scripts are a good idea before they are born.

systemd & the tightly couple core band vs a world of many inits

Posted Apr 24, 2012 23:26 UTC (Tue) by dlang (guest, #313) [Link] (6 responses)

you are entitled to do whatever you want on your systems.

But why do you think you have the right to dictate what other people do on their systems?

systemd & the tightly couple core band vs a world of many inits

Posted Apr 25, 2012 5:28 UTC (Wed) by cmccabe (guest, #60281) [Link] (5 responses)

He's a sysadmin. Of course he wants to dictate what you do on the system :)
(joke)

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.

systemd & the tightly couple core band vs a world of many inits

Posted Apr 25, 2012 11:04 UTC (Wed) by dgm (subscriber, #49227) [Link] (3 responses)

Well, it is, and it isn't at the same time.

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).

systemd & the tightly couple core band vs a world of many inits

Posted Apr 25, 2012 14:41 UTC (Wed) by mezcalero (subscriber, #45103) [Link]

The same Arjan is now working with the systemd folks and pushed systemd into multiple intel projects, simply because it offers the best performance.

systemd & the tightly couple core band vs a world of many inits

Posted Apr 25, 2012 19:16 UTC (Wed) by oldtomas (guest, #72579) [Link]

Hm. If one trusts this source [1], Debian SysV is the most concise, by a long shot.

[1] <http://en.wikipedia.org/wiki/OpenRC#Size_and_complexity>

systemd & the tightly couple core band vs a world of many inits

Posted Apr 26, 2012 22:49 UTC (Thu) by s0f4r (guest, #52284) [Link]

The same Arjan who game the talk at Linux Plumbers together with me. And, our newest work will reduce boot time even further, while doing more, be more robust, and scale across many more services and devices in systems.

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.

systemd & the tightly couple core band vs a world of many inits

Posted Apr 25, 2012 15:40 UTC (Wed) by jedidiah (guest, #20319) [Link]

The simpler part of init scripts is not the scripts themselves but how they interact with each other. As far as the script themselves being unmaintainable spaghetti, you can do that with any language. I am sure as Upstart gains more traction more cruft and craziness will build up.

Init and bash are things that have had decades to show it's warts.

You just haven't given Upstart a chance yet. '-)

systemd & the tightly couple core band vs a world of many inits

Posted Apr 25, 2012 7:56 UTC (Wed) by HelloWorld (guest, #56129) [Link]

systemd & the tightly couple core band vs a world of many inits

Posted Apr 25, 2012 10:44 UTC (Wed) by njs (subscriber, #40338) [Link] (8 responses)

> SysV init is definitely the most hackable of the alternatives discussed here -- all its baroque clumsiness notwithstanding

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.

Hackability

Posted Apr 26, 2012 17:20 UTC (Thu) by oldtomas (guest, #72579) [Link] (7 responses)

"It occurs to me that this is exactly the same argument that justifies using PHP"

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.

Hackability

Posted Apr 26, 2012 17:35 UTC (Thu) by dlang (guest, #313) [Link]

One thing that I think people are not accounting for is the fact that RedHat sysV init scripts tend to be especially bad, with scripts calling other scripts taht source other scripts that read and parse config files.... so that you have to dig many layers down to figure out what's happening.

SysV init scripts don't need to be nearly this complicated, and on other distros they aren't.

Hackability

Posted Apr 26, 2012 18:21 UTC (Thu) by njs (subscriber, #40338) [Link]

Yes, that's my point. PHP's "hackability" has nothing to do with its merits as a language -- if it did, then it would have been strangled at birth. Its "hackability" is that random users can open up a file, see some HTML and familiar bits of their webpage and bits of code scattered around, and start copy-pasting and tweaking to get it to do something different. The code is horrible, but easily accessible for tweaking. PHP's success is entirely due to its providing a "low-key entry path for folks who are not yet at the level of [doing real programming]".

Also, typical PHP web-pages and typical SysV init scripts probably have comparable levels of copy-pasted code...

Hackability

Posted Apr 26, 2012 19:21 UTC (Thu) by HelloWorld (guest, #56129) [Link] (4 responses)

> 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.
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

Posted Apr 26, 2012 19:33 UTC (Thu) by cdmiller (guest, #2813) [Link] (3 responses)

As one never needs to patch and recompile anything from /bin to hack a work around into an init script, It's your proposed comparison which lacks any pragmatic meaning.

Hackability

Posted Apr 26, 2012 20:26 UTC (Thu) by HelloWorld (guest, #56129) [Link] (1 responses)

I've never needed to recompile systemd either, so what kind of argument is that supposed to be?

Hackability

Posted Apr 28, 2012 20:21 UTC (Sat) by man_ls (guest, #15091) [Link]

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

Posted Apr 26, 2012 21:21 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

Nobody stops you from rewriting a systemd unit file as a sh/bash script if you hit a deficiency in systemd.

Remember, it's fully compatible with SysV init.

systemd & the tightly couple core band vs a world of many inits

Posted Apr 24, 2012 21:00 UTC (Tue) by drag (guest, #31333) [Link] (25 responses)

> There are a number of folk in the Linux ecosystem pushing for a small core of tightly coupled components to make the core of a modern linux distro. The idea is that this "core distro" can evolve in sync with the kernel, and generally move fast. This is both good for the overall platform and very hard to implement for the "universal" distros.

Not really. All operating systems need to do a more-or-less the same job regardless of what you plan on doing with them. It doesn't really matter what you want to do with them.

On embedded systems or servers... what they want to accomplish and what they need is trivial compared to what it takes to support desktop and mobile devices properly. So if you are using something like SystemD or NetworkManager you end up with a overabundance of capabilities, which is almost never a bad thing. Once you learn to use them properly then you'll find that they are easier and better, even for embedded systems or sever systems. (and this is no joke)

Which ever Debian chooses to use (sysV, systemd, or upstart) the most important thing they need to do is make a decision. I am far less concerned about which they choose, just that they make a choice.

systemd & the tightly couple core band vs a world of many inits

Posted Apr 24, 2012 21:05 UTC (Tue) by dlang (guest, #313) [Link] (1 responses)

> you end up with a overabundance of capabilities, which is almost never a bad thing.

This overabundance of capabilities brings a significant amount of additional complexity along with it, which is almost never a good thing.

Add to it the fact that a lot of these tools try _really_ hard to do what a desktop user would want them to do, and it can frequently be hard to get them to _not_ do that and instead do what you need them to do.

systemd & the tightly couple core band vs a world of many inits

Posted Apr 25, 2012 15:35 UTC (Wed) by drag (guest, #31333) [Link]

> This overabundance of capabilities brings a significant amount of additional complexity along with it, which is almost never a good thing.

But it is necessary complexity in many regards.

Either you have it done in systemd or you find some other mechanism to do it.

systemd & the tightly couple core band vs a world of many inits

Posted Apr 26, 2012 2:59 UTC (Thu) by salimma (subscriber, #34460) [Link]

>> There are a number of folk in the Linux ecosystem pushing for a small core of tightly coupled components to make the core of a modern linux distro. The idea is that this "core distro" can evolve in sync with the kernel, and generally move fast. This is both good for the overall platform and very hard to implement for the "universal" distros.
> Not really. All operating systems need to do a more-or-less the same job regardless of what you plan on doing with them. It doesn't really matter what you want to do with them.

I think Martin meant something else by "universal" -- he meant that Debian, unlike say Fedora and Ubuntu, support multiple different ways of providing the same feature, even in the base OS -- different kernels (Linux, FreeBSD, GNU Hurd), different init systems, etc., and thus life gets harder for them when people push for tighter integration.

systemd & the tightly couple core band vs a world of many inits

Posted Apr 26, 2012 10:07 UTC (Thu) by cas (guest, #52554) [Link] (21 responses)

That's the first time i've ever seen NetworkManager accused of having an overabundance of capabilities.

I guess there must be leakage from some parallel universe where NM isn't a pile of worthless crap that makes it impossible to have anything but the most basic network configuration.

NM is OK (as in tolerable) on laptops and desktop machines where all you want is a dhcp assigned IP and a simple GUI to configure access to your wireless AP.

For anything else, it's a complete PITA that actively prevents you from getting your network working.

systemd & the tightly couple core band vs a world of many inits

Posted Apr 26, 2012 10:31 UTC (Thu) by ovitters (guest, #27950) [Link] (5 responses)

Hi, this is the second message I see from you. If you want to be taken seriously, suggest to not use phrasings like "pile of worthless crap". Thanks.

systemd & the tightly couple core band vs a world of many inits

Posted Apr 26, 2012 10:49 UTC (Thu) by cas (guest, #52554) [Link] (4 responses)

I can think of no compelling reason for me to care in the slightest whether you take me seriously or not. Feel free to try to convince me that your opinion should be worth something to me. It won't be easy.

As for Network Manager, given that it is a steaming pile of worthless crap, I have no hesitation in describing it as such.

systemd & the tightly couple core band vs a world of many inits

Posted Apr 26, 2012 11:58 UTC (Thu) by ean5533 (guest, #69480) [Link]

It's not just bkor's opinion you should care about -- it's the entire LWN community that will take you less seriously. Perhaps you don't care about anyone's opinion, but if that's the case, then why are you here?

systemd & the tightly couple core band vs a world of many inits

Posted Apr 26, 2012 22:18 UTC (Thu) by ovitters (guest, #27950) [Link] (2 responses)

You're turning things around. I already stated that the way you communicate is not very nice. As such, why are you asking me to convince you? I fail to see the logic in this. Of course it's your choice to continue communicating in the same way (eventhough I'd appreciate some more strict moderation on LWN).

Some "communities" (as far as LWN is a community) are different; on e.g. GNOME you can disagree/agree as much as you want, but it is not a free for all.

Suggest saying the same as you do here in real life / conferences such as GUADEC/FOSDEM. You'll see that some communication methods just don't get you much further.

systemd & the tightly couple core band vs a world of many inits

Posted Apr 27, 2012 2:36 UTC (Fri) by cas (guest, #52554) [Link] (1 responses)

1. lecturing people because they don't live up to or believe in YOUR PERSONAL IDIOSYNCRATIC PREFERENCES is offensive and annoying.

If you don't like me saying that "software package X is crap, and here are some of the reasons why" then DON'T READ ANYTHING I POST, but don't insist that I conform to YOUR standards as if they are some universal objective standard of correct behaviour.

2. it is you who are turning things around. you said words to the effect of "be nice as i define it or i won't listen to you" - this is a repulsively passive-aggressive form of attempted censorship. I said "why should i care if you listen to me or not?". you still haven't provided any reason why i should care and seem to be going out of your way to provide reasons why i shouldn't.

3. Don't bother me again with this tedious garbage. i'm not interested.

some days i really wish forums like this had a killfile.

systemd & the tightly couple core band vs a world of many inits

Posted Apr 27, 2012 2:43 UTC (Fri) by sfeam (subscriber, #2841) [Link]

"some days i really wish forums like this had a killfile."
It does. You're now in it.

systemd & the tightly couple core band vs a world of many inits

Posted Apr 26, 2012 19:08 UTC (Thu) by jimparis (guest, #38647) [Link] (14 responses)

> I guess there must be leakage from some parallel universe where NM isn't a pile of worthless crap that makes it impossible to have anything but the most basic network configuration.

I suspect you're basing that on old versions of NM. When it started, it was how you describe, capable of only very basic network configuration. But many more features have been added since then. For example, I've recently used it on a remote data-capture system to:
- configure one wired port with a static IP
- independently, connect to a 3G network via USB modem
- run an OpenVPN tunnel over that 3G network
Combined with a script that lightly poked around with "nmcli con" to reconnect if the 3G seemed to be stuck, it was by far the easiest way to deal with the cell phone and VPN setup.

I also occasionally plug my cell phone into my laptop, let NM connect to the Internet through it, and then tell NM to run a DHCP server on my wired connection and share the connection there.

Those cases might not be useful for you, but I think it's still far improved from "very basic network configuration". In general, I've found that if NM _does_ support a particular configuration, it goes one
step further and makes that configuration _easy_.

systemd & the tightly couple core band vs a world of many inits

Posted Apr 26, 2012 19:15 UTC (Thu) by dlang (guest, #313) [Link] (5 responses)

> I've found that if NM _does_ support a particular configuration, it goes one step further and makes that configuration _easy_.

I think this sums up the issue almost completely.

_IF_ it supports the configuration, it makes it easy for a desktop user to use it.

but if it doesn't support that configuration, or if you aren't a desktop user (i.e. server, embedded), then it is a problem.

systemd & the tightly couple core band vs a world of many inits

Posted Apr 26, 2012 20:05 UTC (Thu) by jimparis (guest, #38647) [Link]

>_IF_ it supports the configuration, it makes it easy for a desktop user to use it.

> but if it doesn't support that configuration, or if you aren't a desktop user (i.e. server, embedded), then it is a problem.

I agree that you're basically out of luck if it doesn't support your configuration. But those situations are getting more and more rare in my experience.

Regarding "embedded", I disagree. The main example I gave was essentially an embedded system -- a laptop hooked up to data-capture equipment shoved in an inaccessible machine room somewhere. And in that case, I purposely installed and used network-manager because it supported what I needed (multiple interfaces, 3G modem, OpenVPN). Tweaking pppd and its config for just the 3G would have been quite a pain in comparison.

For "server", I'd still tend to agree -- having multiple bridged and bonded network interfaces in separate zones is, AFAIK, still not something NM would be helpful for.

systemd & the tightly couple core band vs a world of many inits

Posted Apr 27, 2012 2:42 UTC (Fri) by cas (guest, #52554) [Link] (3 responses)

this is *exactly* the problem with NM.

You can do what is pre-programmed into it very easily. the catch is that you can *ONLY* do what is pre-programmed into it, and you can not use a combination of NM for the simple stuff plus your own hand-crafted config for the more complex / non-preprogrammed stuff.

If you could convince NM to leave your hand-crafted stuff alone and not break your network configuration because it doesn't understand it, then it would merely be a somewhat useful but quite limited tool. But you can't do that. which makes it a pile of worthless crap.

(and, btw, the most recent version of NM i tested was whatever was in debian sid about a month ago. i used it for a few days until it interfered with stuff i needed to do to get kvm running on my new workstation)

systemd & the tightly couple core band vs a world of many inits

Posted Apr 27, 2012 12:36 UTC (Fri) by mpr22 (subscriber, #60784) [Link] (2 responses)

you can not use a combination of NM for the simple stuff plus your own hand-crafted config for the more complex / non-preprogrammed stuff.

A cursory examination of a nearby Ubuntu 10.04 system gives me the impression that NetworkManager can be configured to only touch the interfaces the administrator wants it to touch, which means that at least some cases satisfying your description are viable (obviously there are plenty that are not).

I also note that the existence of network configurations which it is reasonable to desire and which NetworkManager cannot be coerced into understanding (or at least into not breaking) is clearly a bug in NetworkManager which should be reported through the appropriate channels.

systemd & the tightly couple core band vs a world of many inits

Posted Apr 27, 2012 16:03 UTC (Fri) by dlang (guest, #313) [Link] (1 responses)

> I also note that the existence of network configurations which it is reasonable to desire and which NetworkManager cannot be coerced into understanding (or at least into not breaking) is clearly a bug in NetworkManager which should be reported through the appropriate channels.

The problem is how you define "reasonable to desire"

there are an incredible number of situations where the right thing to do in a particular situation is not something that would be considered sane in most other situations. Listing all these special cases in a tool like NM would confuse users and cause them to select the wrong thing.

systemd & the tightly couple core band vs a world of many inits

Posted Apr 27, 2012 16:14 UTC (Fri) by mpr22 (subscriber, #60784) [Link]

NetworkManager, the daemon, is not nm-connection-editor, the GUI tool for manipulating the daemon's configuration.

systemd & the tightly couple core band vs a world of many inits

Posted Apr 27, 2012 3:33 UTC (Fri) by shemminger (subscriber, #5739) [Link] (7 responses)

The good and the bad of NM. NM makes setting up VPN's etc on my laptop easy, but it interferes horribly when doing anything moderately serverish like setting up VLAN's, bridging, bonding, fiddling with devices. I.e all the things you hope a network developer tests. So yes for users it's great but for developers it is a nuisance.

I fear systemd will end up the same way. Kind of like the Apple IOS, when everything works its wonderful, but when you want to develop hardware support or run another OS, or have a hardware error, it just says "your not worthy" and spits in your face.

systemd & the tightly couple core band vs a world of many inits

Posted Apr 27, 2012 22:06 UTC (Fri) by zlynx (guest, #2285) [Link] (6 responses)

Setting up the VPN is easy, but NM fails at something I used to have scripts doing: getting name service set properly.

I *used* to run a caching named with forwarding servers defined for the internal nameservers on remote networks. The scripts would set the reference to the server and reconfig named.

To do the same thing on NetworkManager I'd have to write a plugin. Considering the state of other NM plugins, the NM authors have zero concern for API compatibility and therefore I'd also have to rewrite the code every six months or so.

systemd & the tightly couple core band vs a world of many inits

Posted Apr 27, 2012 22:14 UTC (Fri) by jimparis (guest, #38647) [Link] (5 responses)

A plugin might be overkill. Is putting your scripts in /etc/NetworkManager/dispatcher.d not sufficient? It seems that you would just have to check that the interface coming up is your VPN, and then do your named config magic as usual.

systemd & the tightly couple core band vs a world of many inits

Posted Apr 28, 2012 1:45 UTC (Sat) by jspaleta (subscriber, #50639) [Link] (1 responses)

by plugin do you mean a script networkmanager's dispatcher.d facilility that fires on network up/down?

i just want to be clear as to what you have attempted.

-jef

systemd & the tightly couple core band vs a world of many inits

Posted Apr 28, 2012 2:29 UTC (Sat) by jspaleta (subscriber, #50639) [Link]

replying to myself... somehow i punched the wrong comment to reply to and i was too late to be relevant anyways. Please ignore me.. just this once.

-jef

systemd & the tightly couple core band vs a world of many inits

Posted Apr 28, 2012 21:02 UTC (Sat) by zlynx (guest, #2285) [Link] (2 responses)

I just looked around at the man pages and http://live.gnome.org/NetworkManager

Do you realize the dispatch stuff isn't documented anywhere?

Besides that, NM makes it quite difficult to use DHCP and still point the DNS at ::1.

Which seems to be why someone wrote the dns=plugin stuff that is in the NetworkManager configuration file.

systemd & the tightly couple core band vs a world of many inits

Posted Apr 29, 2012 0:44 UTC (Sun) by jimparis (guest, #38647) [Link] (1 responses)

> Do you realize the dispatch stuff isn't documented anywhere?

On my system, it's the majority of the "Description" section in "man networkmanager". See http://linux.die.net/man/8/networkmanager

> Besides that, NM makes it quite difficult to use DHCP and still point the DNS at ::1.

Under your IPv4 or IPv6 settings tab, just set the "method" to "Automatic (DHCP) addresses only" or "Automatic, addresses only". Then fill in the DNS servers yourself.

systemd & the tightly couple core band vs a world of many inits

Posted May 1, 2012 6:50 UTC (Tue) by zlynx (guest, #2285) [Link]

Hmm. Sure enough, it is there in the Description section. I never saw it. I probably skipped Description in order to get to the good stuff. It seems to me that most man pages put a description in Description and then the actually useful information in other sections.

Or it is possible that I was logged into a CentOS 5 system when I ran the man command. NetworkManager 0.7 (the RHEL 5 version) has a dispatcher.d directory, but nothing in the man page about it. And this time I double-checked.

systemd & the tightly couple core band vs a world of many inits

Posted Apr 25, 2012 22:47 UTC (Wed) by ballombe (subscriber, #9523) [Link]

The problem of the "core distro" model is that whoever control the development of the core distro can dictate how your distribution will run (for example which kernel you can use). Of course you can patch over or fork the core distro, but that defeats the purpose.