LWN: Comments on "Shuttleworth: Quality has a new name"

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

runciter — Thu, 03 May 2012 20:55:43 +0000

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

josh — Thu, 03 May 2012 00:52:03 +0000

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.

Shuttleworth: Quality has a new name

jschrod — Wed, 02 May 2012 15:09:17 +0000

You are right, of course.

Dennis' and Ken's work have been so intertwined for me, that this lapsus may happen... ;-) They got the award together in 1983, and I always considered that article the real Turing lecture for Unix, not the other one about Bell Labs' research politics. Even ACM lists that article on Dennis' short annotated bibliography: http://amturing.acm.org/bib/ritchie_1506389.cfm

(I had the pleasure to have a dinner with them, many years ago. It was a great evening that I still remember well.)

Shuttleworth: Quality has a new name

dgm — Wed, 02 May 2012 14:08:28 +0000

And trust is all that's about, isn't it? (I'm referring to Dennis' Turing Award article, in case that ain't clear.)

I think you mean Ken Thomson's article.

Shuttleworth: Quality has a new name

BenHutchings — Tue, 01 May 2012 17:05:45 +0000

They don't even update kernels between releases.

Yes they do. And it's not just updating drivers; they've backported quite large new features, like KVM into RHEL 5.

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

zlynx — Tue, 01 May 2012 06:50:09 +0000

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

jbicha — Mon, 30 Apr 2012 19:35:12 +0000

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

Cyberax — Mon, 30 Apr 2012 16:03:50 +0000

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

Shuttleworth: Quality has a new name

anselm — Mon, 30 Apr 2012 15:53:32 +0000

For me, the most sad point is: I actually agree with Kay and Lennart et.al. that SysV init is not done well and should be replaced. The architecture of systemd is sound and much better.

I think we're all on the same side here …

But: The developer's attitude does not inspire trust. That's like running software from Dan Bernstein, which I would never do in a professional environment. And trust is all that's about, isn't it?

True. It would certainly be good if Lennart Poettering was less like Dan Bernstein and more like Wietse Venema ;^)

PS: Are you Anselm from Darmstadt?

Yep, that's me ;^)

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

jbicha — Mon, 30 Apr 2012 15:52:05 +0000

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.

Shuttleworth: Quality has a new name

jschrod — Mon, 30 Apr 2012 01:15:06 +0000

> System V init doesn't really have much of an ABI to be compatible with.

Ahem. Please read http://lwn.net/Articles/490177/, by an author named, well, anselm. Perhaps he'll understand what's about; I can fully subscribe to his views expressed in that post. :-)

In fact, the System V init ABI is simple: If /etc/init.d/start/$service {start,stop,status,restart,reloac} worked with init.d, it should work with systemd as well.

Since the systemd proponents dismiss init.d scripts as ineffective and not-working, and strive for substitution by systemd definition files in all cases, I won't accept the existance of »deprecated« init.d scripts as »systemd supports it«. Discussions on mailing lists of Fedora, opensuse-factory, et.al. clearly shows that this is not what is supposed to be »real systemd support«.

But then I notice that there are intrinsic assumptions of systemd that are not always fulfilled. E.g., on opensuse-factory I followed quite some flamewars where developers asked how previous features should be realized now. The most prominent examples were (a) how to shut down all running virtual machines when no watchdog process is there (systemd ties a service to a running process it can supervize), and (b) how to state the status of a system like AppArmor when there's no daemon to ask for the status. HylaFax service description wasn't convertible either; I don't remember the reason any more, though. All the time, the answer the developers got was: Thou Shall Not Want To Do That. I.e., the answer they got was: That's not a service as defined by systemd and thus it's not a valid request. We Define What's Right And You Are Wrong(tm).

As another example from the openSUSE community: When systemd was introduced in 12.1, they broke packages like Postfix. Well, shit happens when you introduce new things, no biggie -- one should think. But: systemd introduced the breakage and what was the reaction of those who caused the problem? It was: it's Postfix's problem, it should adapt to the New And Only Way; it's not systemd's fault and Postfix should fix it. Sit back and contrast this to the Linux kernel way: If somebody introduces a change in a fundamental service, it's his or her responsibility to fix all problems that's caused by the change; he can't tell the others »that's the New Way(tm), You Have To Do The Work to change«. Such patches would be flamed to hell by Linus, and rightly so. And that's the behaviour I would like to see in user land, too.

We're thoroughly missing a Linus for Linux plumber's land. Last year, it was all ConsoleKit etc, that was en vogue. Now it's obsolete, decided by the very same developer that introduced camel case *Kit daemones to Unix. Witness the change of udev's role and HAL's demise over the last few years -- this ain't a stable environment any more to develop for. Oh yes -- will standalone udev still exist next year, or will it be abandoned? The developers actions, blog posts, and comments on their blogs don't necessarily inspire trust.

And btw,

> do you mean we shouldn't use something like systemd on Linux because BSD
> and Solaris don't support advanced Linux features that systemd exploits,
> such as cgroups

I don't think we should not use cgroups. But if patches come along to make cgroups optional, upstream should go forward and accept them. Instead they ridicule non-Linux developers -- or even Linux developers, as shown by Lennart's last blog post about Ubuntu. systemd upstream is as bad as OpenSSH upstream -- and that's something to write, I wouldn't have thought I would compare someone to Theo de Raadt without meaning an insult. (I don't know if you ever met Theo in person. It's not a nice affair.)

For me, the most sad point is: I actually agree with Kay and Lennart et.al. that SysV init is not done well and should be replaced. The architecture of systemd is sound and much better. init.d dependencies is one of the first things one has to patch in most installations. systemd unit descriptions are really better and can be adapted more easily. But: The developer's attitude does not inspire trust. That's like running software from Dan Bernstein, which I would never do in a professional environment. And trust is all that's about, isn't it? (I'm referring to Dennis' Turing Award article, in case that ain't clear.)

I hope this clarifies some of my thoughts.

Joachim

PS: Are you Anselm from Darmstadt? If yes, I met with Metin last week. Cheerio. :-)

Shuttleworth: Quality has a new name

rahulsundaram — Sun, 29 Apr 2012 23:50:24 +0000

"the 2.6 development process was changed to encourage Red Hat"

Citations needed. https://lwn.net/Articles/94386/ shows Alan Cox pushing for a six month release process and Andrew Morton suggesting the current process. Also I note, you didn't provide any specifics on which kernel features weren't pushed upstream by Red Hat earlier in the 2.4 kernel process.

Shuttleworth: Quality has a new name

dlang — Sun, 29 Apr 2012 23:37:35 +0000

the 2.6 development process was changed to encourage Red Hat (and the other distributions) to cooperate more and work more upstream, and I think it's been a wonderful success in doing so.

I just see people giving Red Hat a free pass on anything that it does (or has ever done) while condemning Canonical and Ubuntu for doing similar things (and in my eyes, doing them to a less damaging degree)

Shuttleworth: Quality has a new name

rahulsundaram — Sun, 29 Apr 2012 22:22:50 +0000

Feel free to be more specific. I would argue that what has changed is the 2.6 kernel development process.

Shuttleworth: Quality has a new name

dlang — Sun, 29 Apr 2012 22:12:49 +0000

Red Hat currently does much of it's kernel work upstream, but this has not always been the case. they have gotten much better in the last couple of years.

Shuttleworth: Quality has a new name

rahulsundaram — Sun, 29 Apr 2012 21:26:38 +0000

"if you are going to start throwing rocks I'll point out that RedHat has probably the worst track record of any distro in terms of maintaining local patches to the kernel"

That isn't the same thing. Red Hat usually does all kernel work upstream and backports it to maintain compatibility for the enterprise releases. For Fedora, there isn't any history of major local patches that weren't upstream quickly because of the shorter release cycle. When people complain about vendor X not doing work upstream it is usually because that vendor hasn't made any efforts to push it upstream.

Shuttleworth: Quality has a new name

man_ls — Sun, 29 Apr 2012 20:56:18 +0000

This grants you a spot in my "personal attacks" filter.

Amen. I needed to cull these articles with 200+ messages anyway...

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

speedster1 — Sun, 29 Apr 2012 18:29:50 +0000

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

anselm — Sun, 29 Apr 2012 10:10:58 +0000

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.

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

jimparis — Sun, 29 Apr 2012 01:21:56 +0000

> 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

jimparis — Sun, 29 Apr 2012 00:44:51 +0000

> 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

speedster1 — Sat, 28 Apr 2012 23:52:12 +0000

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

Shuttleworth: Quality has a new name

Cyberax — Sat, 28 Apr 2012 23:42:19 +0000

They don't even update kernels between releases. So little chance of that.

Though RHEL7 should be fairly soon - in 2014 or so :)

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

Cyberax — Sat, 28 Apr 2012 23:40:03 +0000

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

Shuttleworth: Quality has a new name

speedster1 — Sat, 28 Apr 2012 23:23:20 +0000

I think swapping init systems in a minor version bump would be very inappropriate for RHEL. Too much system config churn for their very conservative customer base, without a compelling excuse for making such an exception in their normal upgrade strategy.

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

speedster1 — Sat, 28 Apr 2012 22:49:16 +0000

> 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

zlynx — Sat, 28 Apr 2012 21:02:31 +0000

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.

Hackability

man_ls — Sat, 28 Apr 2012 20:21:16 +0000

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

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

jspaleta — Sat, 28 Apr 2012 02:29:52 +0000

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

jspaleta — Sat, 28 Apr 2012 01:45:06 +0000

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

jimparis — Fri, 27 Apr 2012 22:14:24 +0000

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

zlynx — Fri, 27 Apr 2012 22:06:45 +0000

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 to Sys V init converter

MrWim — Fri, 27 Apr 2012 20:57:24 +0000

Fascinating. I wonder how they will derive the dependencies that socket activation takes care of but are not explicit in the service files.

Shuttleworth: Quality has a new name

jspaleta — Fri, 27 Apr 2012 16:23:27 +0000

And there this is this gem:
https://bugs.launchpad.net/upstart/+bug/703800

Whatever test coverage they have... its not clear its helping them fix issues. They may know about them... know about them for years...and they aren't getting fixed.

There's a lot of complexity in the native job stuff... and I'm really not sure it has testing coverage either pre-deployment or real world to shake it all loose. There are several outstanding issues with going completely native that Ubuntu hasn't figured out that would point to a need for some deep tissue massage therapy in upstart itself. Just sort the upstart bugs by heat and go from hottest to coldest.

-jef

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

mpr22 — Fri, 27 Apr 2012 16:14:27 +0000

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

dlang — Fri, 27 Apr 2012 16:03:54 +0000

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

Shuttleworth: Quality has a new name

mathstuf — Fri, 27 Apr 2012 16:03:17 +0000

If you have a Compose key (I use Shift+RtAlt), just do <Compose></><m>. Most of the combined characters "make sense" in how to create them.

As a reference:

setxkbmap -option lv3:ralt_switch_multikey

Shuttleworth: Quality has a new name

rahulsundaram — Fri, 27 Apr 2012 14:28:16 +0000

It is a potentially valid advantage if that claim is accurate

https://plus.google.com/115547683951727699051/posts/JCDko...

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

mpr22 — Fri, 27 Apr 2012 12:36:18 +0000

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.

Shuttleworth: Quality has a new name

branden — Fri, 27 Apr 2012 12:09:20 +0000

I ain't installing a new input method or learning a new Unicode code point just to type "₥s" (and you're fortunate I am not too lazy to cut-and-paste from your post).

Try again!