User: Password:
|
|
Subscribe / Log in / New account

Poettering: The Biggest Myths

Poettering: The Biggest Myths

Posted Jan 27, 2013 14:01 UTC (Sun) by niner (subscriber, #26151)
In reply to: Poettering: The Biggest Myths by hazard
Parent article: Poettering: The Biggest Myths

So your complaint is that it's different and you have to learn something new. Well if you don't like learning, you should look for a different job. If I complained loudly every time something I knew in technology became obsolete, noone would like to talk to me anymore, since all I'd do was complaining.

I would love to know, how you would implement systemd's features without departing significantly from SysV init. Especially systemd's ability to reliably kill a daemon and all it's child processes. This feature alone would make me switch to systemd immediately, since it makes cluster failover much more reliable. File systems can only be unmounted if all processes accessing them are killed. So we need reliable killing to unmount and switch the drbd node to secondary.

I will not for one second miss the whole "oh the daemon could not write it's PID file, but it started anyway and now the init script cannot stop it anymore" mess... Or the init script shows a green "done" but it didn't notice that apache died immediately afterwards.

systemd solves real problems for real users. It does so at the cost of and hour or two of learning how to use it versus the 17 years of experience one needed to get SysV based systems to run reliably.


(Log in to post comments)

Poettering: The Biggest Myths

Posted Jan 27, 2013 14:32 UTC (Sun) by hazard (guest, #3695) [Link]

> So your complaint is that it's different and you have to learn something new. Well if you don't like learning, you should look for a different job.

I expected that someone will appear and oversimplify my thoughts down to this.

There are reasons why Cisco keeps IOS syntax unchanged, why GUI apps keep using "floppy disk" icon to save files and why Linus insists to keep kernel's user-level API unchanged.

And these reasons are: to preserve compatibility and to preserve existing knowledge.

Try coming to any serious enterprise and tell them to switch all servers to Linux, just because "it's better". And if their IT responds that they don't know Linux, tell them that they should look for a different job if they don't like to learn.

Sorry, real life doesn't work this way. What people know DOES matter, what your existing customer base wants also DOES matter.

I may learn systemd; or I may as well switch to some other distro which listens to its user-base.

Poettering: The Biggest Myths

Posted Jan 27, 2013 14:50 UTC (Sun) by hazard (guest, #3695) [Link]

To make it clear, I never said that systemd doesn't bring improvements. systemd does offer numerous quite-nice-features.

However, in my opinion it was completely unnecessary to wipe out existing SysV principles in order to implement those quite-nice-features.

Actually it seems to me that the main reasons to throw SysV concepts out were to implement features which many users don't really care for, like use of targets instead of runlevels.

You can implement a daemon which would launch scripts from /etc/init.d/rcS.N and use /etc/inittab, you can introduce special functions in the scripts to support reliable service launch and PID capture, you can still have this daemon to listen for callbacks from the services to indicate succesful startup, catch service startup output in a structured log, etc. You can even provide OPTIONAL ability for parallel startup for those who want it, while keeping the traditional startup sequence by default.

Poettering: The Biggest Myths

Posted Jan 27, 2013 15:13 UTC (Sun) by niner (subscriber, #26151) [Link]

If you want, you _can_ still use systemd as if it was just a SysV implementation and have scripts in /etc/initd (or was it /etc/rc.d or /etc/init.d/rc.d on your distro?). I actually still use them (or rather the rc<daemonname> symlinks in /usr/sbin to them) out of habit. But most of them are nice and redirect to systemd to do what I mean.

"You can implement a daemon which would launch scripts from /etc/init.d/rcS.N and use /etc/inittab, you can introduce special functions in the scripts to support reliable service launch and PID capture, you can still have this daemon to listen for callbacks from the services to indicate succesful startup, catch service startup output in a structured log, etc."

In other words, one could create new infrastructure to support those features and rewrite every single init script to use it. Administrtors would have to learn a lot again about what new magical commands one would have to use to start a daemon.

But why not use this chance to go a little further and make another leap in usability and features? I still remember the WTF look on my dad's face, when I showed him how to fix the ordering of the init scripts on his server by editing some magical comments in bash scripts.

"You can even provide OPTIONAL ability for parallel startup for those who want it, while keeping the traditional startup sequence by default."

I have not had a purely sequential startup on my systems for a decade, since SUSE's init already started init scripts with the same number in parallel. So systemd does not even deviate here from SysV. It just fixes the mentioned WTF problems.

Poettering: The Biggest Myths

Posted Jan 27, 2013 15:30 UTC (Sun) by hazard (guest, #3695) [Link]

> In other words, one could create new infrastructure to support those features and rewrite every single init script to use it. Administrtors would have to learn a lot again about what new magical commands one would have to use to start a daemon.

Yes, but that can be done as a limited incremental change in the init scripts. Users would still know where to look and what to expect. In case of systemd, the approach is to wipe out everything and replace it with something completely different.

> But why not use this chance to go a little further and make another leap in usability and features?

Very simply, to allow people to use their existing knowledge and preserve backwards compatibility.

Too big a leap and you get your customers against you. Remember GNOME 3, Windows 8, etc.

> I still remember the WTF look on my dad's face, when I showed him how to fix the ordering of the init scripts

That's not a big problem. A big problem is when I get WTF face from my sysadmins. :)

Poettering: The Biggest Myths

Posted Jan 27, 2013 15:50 UTC (Sun) by niner (subscriber, #26151) [Link]

"In case of systemd, the approach is to wipe out everything and replace it with something completely different."

Which is simply not true. On my systems there are still a lot of init scripts still in use despite using systemd as init. None of our own custom init scripts needed even a single change. But of course we will replace them by real systemd unit files at some convenient time.

"That's not a big problem. A big problem is when I get WTF face from my sysadmins. :)"

Well my dad _is_ a sysadmin with decades of expierience with Netware and Windows. Stupidly overcomplicated things like SysV init scripts almost made him give up on Linux and stay with those systems. Because really, that 17 years of experience with something so mundane like the way to start and stop services on a server actually are worth something shouts that there's somthing wrong with the system.

Poettering: The Biggest Myths

Posted Jan 27, 2013 16:04 UTC (Sun) by drago01 (subscriber, #50715) [Link]

> That's not a big problem. A big problem is when I get WTF face from my sysadmins. :)

Go fire them and hire new ones. Seriously technology is not static a thing ... a sysadmin that cannot spend a few hours (at most) to learn a new system that is actually way easier to use then the old one has chosen the wrong job.

Poettering: The Biggest Myths

Posted Jan 31, 2013 15:54 UTC (Thu) by nye (guest, #51576) [Link]

Conversely it could be said that a sysadmin who is happy to spend a few hours here and there learning to use something new that solves problems *they don't have* is too ready to waste time.

Poettering: The Biggest Myths

Posted Jan 31, 2013 17:02 UTC (Thu) by davidstrauss (subscriber, #85867) [Link]

> Conversely it could be said that a sysadmin who is happy to spend a few hours here and there learning to use something new that solves problems *they don't have* is too ready to waste time.

A boss managing sysadmins with that attitude has zero respect for employee skill development or finding improved ways to do even the company's own work. It creates a workplace that hires people and spits them out ten years later with no recent skill development. Around here, the Bay Area, that approach couldn't even retain a good sysadmin. They'd quit for a company that shows them more respect.

But, maybe you don't have the experience to understand that. I've actually owned companies employing engineers and sysadmins for the last eight years, both here in and in Austin. The way to keep good people is to go out of your way as an employer to foster careers and skill development through side projects, training, books, conferences, and community involvement.

Poettering: The Biggest Myths

Posted Feb 2, 2013 19:11 UTC (Sat) by nix (subscriber, #2304) [Link]

The Bay Area is unusual. I was considered almost freakish in the City of London for wanting to keep my (software development) skills up to date. Just use what everyone else is using! Follow the herd and learn the hot stuff only when everyone else learns it! Baaaa.

Poettering: The Biggest Myths

Posted Feb 2, 2013 22:04 UTC (Sat) by davidstrauss (subscriber, #85867) [Link]

> The Bay Area is unusual. I was considered almost freakish in the City of London for wanting to keep my (software development) skills up to date. Just use what everyone else is using! Follow the herd and learn the hot stuff only when everyone else learns it!

I've done lots of work in London for The Economist and Cap Gemini. While they're both conservative in their technology choices, I'd have trouble generalizing it to the London area as a whole, mostly based on me having such a small sample size of organizations.

I've already mentioned Austin in my post, too, but devops culture aggressively focused on improving sysadmin work also extends to Portland (Puppet Labs), Seattle (Opscode), Austin/Chicago (bcfg2 and devops events), Berlin (systemd), New York, Boston, and a host of other cities with major projects or conferences devoted to improving the the way we do things.

Poettering: The Biggest Myths

Posted Feb 4, 2013 13:09 UTC (Mon) by nye (guest, #51576) [Link]

The point is, I'm sure you're not seriously suggesting that every time some new idea comes along, every sysadmin in the world should either be chomping at the bit to spend hours learning about it or be labelled as 'incompetent' and fired.

That's what I was responding to, and it's absurd. Nobody would ever get anything done.

I was attempting to make a rhetorical point, and clearly didn't do very well. I'm not suggesting that wanting to improve one's skills is a bad thing, but characterising anyone who doesn't immediately want to jump onto every new bandwagon as lazy and incompetent is appalling.

Poettering: The Biggest Myths

Posted Feb 4, 2013 14:28 UTC (Mon) by anselm (subscriber, #2796) [Link]

I'm not suggesting that wanting to improve one's skills is a bad thing, but characterising anyone who doesn't immediately want to jump onto every new bandwagon as lazy and incompetent is appalling.

I think that with systemd we're quickly getting past the »new bandwagon« stage. With the major enterprise-type distributions (RHEL and SLES) slated to replace System V init by systemd in the foreseeable future, administrators of machines based on these distributions, along with their spinoffs such as CentOS or Scientific Linux, could do worse than start getting used to systemd. On many other popular distributions, systemd is at least an option that is available to those interested in it, and it is quite likely that most of these distributions will also move over in time.

The nice thing is that systemd, for all it is being dissed by the traditionalists, is in fact in many ways an improvement on the tangle of »System V init plus distribution-specific init scripts plus various distribution-specific bits of infrastructure not actually part of System V init but tacked on to make it work in practice« that many system administrators are saddled with. In my experience, it doesn't take long for somebody who approaches systemd with an open mind to see that there actually might be something to it after all. Also, using systemd in place of System V init isn't exactly rocket science; it's not as if system administrators were suddenly forced to learn Mandarin in order to be able to keep their systems running.

Poettering: The Biggest Myths

Posted Feb 4, 2013 19:16 UTC (Mon) by davidstrauss (subscriber, #85867) [Link]

> I'm sure you're not seriously suggesting that every time some new idea comes along, every sysadmin in the world should either be chomping at the bit to spend hours learning about it or be labelled as 'incompetent' and fired.

No, I'm saying that "a few hours here and there learning to use something new" isn't a bad thing. I put that in quotes because that's what you actually said was bad.

Arguing that's valuable is hardly saying that "every time some new idea comes along, every sysadmin in the world should either be chomping at the bit to spend hours learning about it or be labelled as 'incompetent' and fired."

Don't create straw men out of my arguments.

Poettering: The Biggest Myths

Posted Feb 6, 2013 12:08 UTC (Wed) by nye (guest, #51576) [Link]

>Don't create straw men out of my arguments.

I didn't. That's why I said "I'm sure you're not" before paraphrasing the argument that the other guy made, specifically to point out that what you're arguing for is *not* what I'm arguing against.

I'm trying to say that you can support the idea that people might want to educate themselves without jumping right to "and anyone who doesn't always want to do that is incompetent".

Poettering: The Biggest Myths

Posted Jan 31, 2013 18:51 UTC (Thu) by smurf (subscriber, #17840) [Link]

Aww. So what you're saying is that there actually _is_ a sysadmin out there who never needs to figure out whether a given service is running, and if so, why not?
And thus, a less cumbersome/error-prone way to do that won't be of _any_ use to said sysadmin? Not even if … oh well, I'm not going to repeat myself again.

Anyway. I feel for them. I really do.

You see, in _my_ company sysadmins with _that_ attitude will quickly find themselves with exactly one remaining task: clean out their desk.

Poettering: The Biggest Myths

Posted Feb 4, 2013 13:13 UTC (Mon) by nye (guest, #51576) [Link]

>Aww. So what you're saying is that there actually _is_ a sysadmin out there who never needs to figure out whether a given service is running, and if so, why not?

I'm saying that there are loads of people who keep saying that they don't need systemd because they have no need for the facilities it provides, and that maybe - just maybe - they might not be lying.

>You see, in _my_ company sysadmins with _that_ attitude will quickly find themselves with exactly one remaining task: clean out their desk.

If this childish posturing makes you feel important, go right ahead.

Poettering: The Biggest Myths

Posted Feb 4, 2013 14:35 UTC (Mon) by anselm (subscriber, #2796) [Link]

I'm saying that there are loads of people who keep saying that they don't need systemd because they have no need for the facilities it provides, and that maybe - just maybe - they might not be lying.

They may not desperately need systemd's facilities but they might actually appreciate them once they have them available.

This »We don't need this« attitude reminds me of some of the Windows administrators I encounter in the Linux workshops I teach. These often refuse to have anything to do with pipelines, regular expressions, etc. on the grounds that they »don't need this« on their Windows machines, so these features can be of no conceivable worth whatsoever. Some of them are of a sufficiently agile mind to see that using these facilities on Linux does in fact make some things easier, even to a point where they find they have less drudge work to do on Linux than on Windows, but others never quite seem to get it.

Poettering: The Biggest Myths

Posted Feb 4, 2013 16:12 UTC (Mon) by rgmoore (✭ supporter ✭, #75) [Link]

I'm saying that there are loads of people who keep saying that they don't need systemd because they have no need for the facilities it provides, and that maybe - just maybe - they might not be lying.

And they might be more believable if they appeared to be more familiar with exactly what facilities systemd provides. It appears to me that a substantial fraction of the resistance to systemd is based around ignorance of what it actually does and doesn't do. People seem to have made up their minds that they're happy with existing init systems and then looked for reasons to dislike systemd rather than finding out in detail about the potential advantages and disadvantages.

Poettering: The Biggest Myths

Posted Feb 6, 2013 12:29 UTC (Wed) by nye (guest, #51576) [Link]

To begin with, personally I'm actually not one of those people who doesn't have those problems. I do on occasion want to be able to do things that systemd makes easier, and am in principle very much in favour of systemd, though in practice I'm not actually willing to try it for myself yet until it's had at least another couple of years to mature - let's say jessie (Debian 8.0).

However, I have a great sympathy for those who are in that position, because that's where I was (and actually still am) with PulseAudio (which, I'll note, still doesn't work properly with Wine on 64-bit systems, at least not on Debian, and still provides no benefits I actually care about).

This is roughly how the exchange sounds from that perspective:

Person A: Try this new snibulator; it's great!
Person B: I'm happy with my old snibulator, thanks.
A: But this one allows you to snibulate even when you're under water!
B: Huh, that sounds cool, but I've never needed to do that.
A: Well you're just too stupid to realise that you need this after all.
B: Please stop telling me what to do.
A: Stop being so hostile! You're clearly too lazy to spend the time to work out that you really need waterproof snibulation. If I had any employees like you, I'd fire them on the spot! I'm so important!

The last line is the one that really grates on me, because it's so arrogant and so aggressively obnoxious. And I haven't hardly even had to exaggerate in my paraphrasing; many of the responses really are that hyperbolic.

Poettering: The Biggest Myths

Posted Feb 6, 2013 19:00 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

> …with PulseAudio (which, I'll note, still doesn't work properly with Wine on 64-bit systems, at least not on Debian, and still provides no benefits I actually care about).

It Works For Me™ on Fedora. Rawhide no less (in December; not sure about this month yet). As for features, I keep an instance of MPlayer streaming some internet radio at work. It's nice to be able to mute it and still play some video with sound and then go back and unmute the stream seamlessly.

Poettering: The Biggest Myths

Posted Jan 27, 2013 14:51 UTC (Sun) by ovitters (subscriber, #27950) [Link]

You're suggesting that systemd requires loads of time to digress. I don't get why though. Could you please explain in practice?

I mean, I still can use chkconfig, service and dump a sysvinit script using systemd. Those are not the systemd ways, but it works fine anyway.

I also wonder why you think you represent an entire user-base or that you aren't listened to?

The most confusing thing about systemd for the distro I help out in is that we disabled the syslog daemon by default. That takes getting used to, no matter how easy it is to reenable it again.

Poettering: The Biggest Myths

Posted Jan 27, 2013 15:18 UTC (Sun) by hazard (guest, #3695) [Link]

Firstly I never wrote that I represent entire user-base. However, I do feel that many sysadmins share the same feelings about systemd as I do. At least I never heard praise of systemd from any of my peers.

systemd requires time to understand in its entirety. I'm not speaking about ability to start or stop particular service or init-script, I'm speaking about understanding the grand picture of how the new startup works in detail, what all those files in /lib/systemd mean and how they interact with each other.

Without having a good grasp on the startup process overall, one is unable to quickly troubleshoot issues. This causes a commercial risk of longer downtime, as sysadmins will take longer to bring the system up in case of a fault.

Poettering: The Biggest Myths

Posted Jan 27, 2013 18:04 UTC (Sun) by jwarnica (guest, #27492) [Link]

So don't upgrade to a system that uses systemd.

What is the problem?

Poettering: The Biggest Myths

Posted Jan 27, 2013 18:36 UTC (Sun) by larryr (guest, #4030) [Link]

So don't upgrade to a system that uses systemd.
What is the problem?

The problem for me is I want the other updates to the other 99% of the software on the system. I am not a sysadmin by profession or by choice, but I need to be for the things I want to do with the system. Understanding the holistic and specific impacts of using of systemd for everything it takes to do what I want has taken me many hours, and I suspect it will take many more. But I am not going to introduce the even greater risk of switching to a different system to avoid using systemd.

Poettering: The Biggest Myths

Posted Jan 27, 2013 18:49 UTC (Sun) by HelloWorld (guest, #56129) [Link]

> systemd requires time to understand in its entirety.
Sysvinit based init schemes take orders of magnitudes more time and they even work differently on different distros.

> Without having a good grasp on the startup process overall, one is unable to quickly troubleshoot issues. This causes a commercial risk of longer downtime, as sysadmins will take longer to bring the system up in case of a fault.
This is a short-term problem that is easily offset by systemd's relative simplicity in the long term.

Poettering: The Biggest Myths

Posted Jan 27, 2013 23:13 UTC (Sun) by ovitters (subscriber, #27950) [Link]

If the init system was intended to be changed every few years, then I'd understand your point. But it is one change in 10+ years (depending on distro, etc).

So 'change is bad': agree. But this is a one-time change. Obviously there is pain in relearning things. But there are also loads of benefits, e.g. systemctl status $SERVICE actually gives meaningful output. Furthermore, you can have systemd reliably detect crashed services and have them restart automatically (no need for some monitor script). Things like this I see as hugely beneficial. One one server amavis dies every few months for reasons unknown. Restart and it'll work for months again. Pretty nice if that is supported instead of yet another monitoring script.

Regarding representing the entire user-base, you said:

Sorry, real life doesn't work this way. What people know DOES matter, what your existing customer base wants also DOES matter.

I doubt anyone fully knows what (e.g. Fedora) users want. Maybe they want systemd, maybe not. You suggest that change is bad and to me you were trying to speak on behalf of everyone with above. Misread that.

Poettering: The Biggest Myths

Posted Jan 28, 2013 4:20 UTC (Mon) by raven667 (subscriber, #5198) [Link]

I am a sysadmin and have been for around 15 years and I think that systemd is awesome so now you have some praise from your peers 8-)

I find systemd to be thorough well thought out, and am excited after doing some troubleshooting that required interaction with systemctl, loginctl and journalctl by how simple it makes things. In a way it reminds me of OpenBSD, which I also find to be well organized. The problems it solves are not fundamentally difficult, starting processes in a controlled environment, and clears away a lot of confusion by just, doing, that.

Poettering: The Biggest Myths

Posted Feb 6, 2013 5:45 UTC (Wed) by vonbrand (guest, #4458) [Link]

But as the knots SysVinit would tie the system into (by willy-nilly starting stuff "in order" when some precondition was delayed for whatever reason, something didn't start because of a mistake and the whole line of dominoes came down leaving no clue) are next to impossible with systemd, this point is moot...

Poettering: The Biggest Myths

Posted Jan 27, 2013 17:26 UTC (Sun) by HelloWorld (guest, #56129) [Link]

> There are reasons why Cisco keeps IOS syntax unchanged, why GUI apps keep using "floppy disk" icon to save files and why Linus insists to keep kernel's user-level API unchanged.
Yeah, it's probably for the same reason that systemd still supports SysV init scripts, /dev/initctl and all that crap. Seriously, who are you trying to shit here?

Poettering: The Biggest Myths

Posted Jan 28, 2013 13:36 UTC (Mon) by pboddie (guest, #50784) [Link]

Perhaps you would make your point better by pointing to the documentation for those compatibility features instead of assuming that someone who is honestly reporting their concerns has a hidden agenda and has to be "called out" over it.

I know it's fashionable to tell existing users to "get with the program" and to assume that they have just as much time to read up on all the new stuff as the people who made that stuff had to develop it, but the recommended transition happens a lot easier if you don't ridicule those people as the first thing you do.

Poettering: The Biggest Myths

Posted Jan 28, 2013 13:52 UTC (Mon) by niner (subscriber, #26151) [Link]

Information about these compatibility features is contained in man systemd which at less than 400 lines of text should be short enough to warrant a reading by someone who obviously has enough time to post multiple messages about systemd. Wouldn't it be prudent to at least read a minimum of documentation before claiming missing compatibility?


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds