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

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.

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

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

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

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.

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

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)

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.