| |||||||||||||
evolutionevolutionPosted Jan 27, 2013 2:01 UTC (Sun) by larryr (guest, #4030)Parent article: Poettering: The Biggest Myths
I liked Unix system administration because getting the system booted and running was something which demanded no more than some simple, discoverable, static configuration which someone with a basic understanding of the shell and a text editor could figure out and change by editing some files under /etc, and which could be tested by just powering up the system and seeing if it all came up properly. Even with udev the Linux kernel has not been demanding much more than that. More complex and dynamic configuration always required more than just this, but it did not require fundamentally replacing the existing infrastructure, and I am not convinced it needs to.
(Log in to post comments)
evolution Posted Jan 27, 2013 2:12 UTC (Sun) by dashesy (subscriber, #74652) [Link]
If anything systemd has made things simpler. If you used to have a system with a few simple scripts you will still need a few simple textual files in systemd, and you can still do a lot with shell scripts if you want (Myth 4).
evolution Posted Jan 27, 2013 2:31 UTC (Sun) by larryr (guest, #4030) [Link] From the vacuous perspective where all usage of text files and shell scripts is equivalent, it could be speciously argued that systemd is not much more demanding of system administrators than its predecessors.
evolution Posted Jan 27, 2013 3:14 UTC (Sun) by nirbheek (subscriber, #54111) [Link]
All that systemd demands of system administrators is that they take some time to learn an excellent new piece of software instead of spewing a knee-jerk reaction of "get off my lawn".
At this point in time, I count Pulseaudio and systemd amongst the best pieces of software written for Linux. The no. of features that they expose to ordinary users and sysadmins is staggering—and they do this without removing features or functionality, and while maintaining near-perfect backward-compatibility. I'm shocked that no one realises how hard it is to do this, and what value these add to our ecosystem.
At this point, after dozens of blog posts by Lennart explaining systemd, if I see anyone arguing the way you are, I am compelled to conclude that they never really gave systemd a fair chance; or, worse, they're too angry at its very existence to even try that.
I feel like most of the animosity towards these projects is not because of their (perceived) lack of technical merit, but because of the abrasive personality of their creator.
evolution Posted Jan 27, 2013 5:51 UTC (Sun) by raven667 (subscriber, #5198) [Link]
> I feel like most of the animosity towards these projects is not because of their (perceived) lack of technical merit, but because of the abrasive personality of their creator.
I think this happens a lot and is also an out of date assessment, Lennart may be matter of fact in a stereotypically Germanic sort of way, which rubs some people the wrong way, but seems to have matured greatly since the flamewars during the PulseAudio days 5+ years ago.
evolution Posted Jan 27, 2013 3:24 UTC (Sun) by dashesy (subscriber, #74652) [Link]
The problem with bash scripts is that they are never simple, they are convoluted, use vague idioms to save key strokes, and it takes quite some time for sysadmins to learn them well; I think every one has stories like how she learned to double-quote all variables in if-statement (test not internal) after her hard drive was formatted because of the space in the variable and that bash silently ignored the line.
On the other hand, a simple declarative text file is certainly more elegant. New sysadmins are just lucky, older sysadmins with a good taste will be happier too, after they spend a few hours to learn some new tricks.
evolution Posted Jan 27, 2013 5:01 UTC (Sun) by Aliasundercover (subscriber, #69009) [Link]
This is my complaint with scripts as well. Even if well written for clarity they present a hard challenge because they can do anything. I find a plain declarative configuration file easier even if it is one I don't know yet because its scope is bounded.
evolution Posted Jan 29, 2013 7:26 UTC (Tue) by Seegras (subscriber, #20463) [Link]
"Some old-school Unix habits have persisted long past
the point that they're even remotely sane. Shell programming at any volume above a few lines of throwaway code is one of them - it's *nuts* and we should *stop doing it*." -- ESR on shell scripts. http://lwn.net/Articles/527308/
ESR does not speak for me Posted Jan 31, 2013 13:12 UTC (Thu) by ncm (subscriber, #165) [Link]
This recommendation is almost enough to make me take up shell programming again. Or sed.
ESR does not speak for me Posted Jan 31, 2013 15:29 UTC (Thu) by HelloWorld (guest, #56129) [Link]
I agree about ESR, but even a broken clock is right twice a day ;-)
evolution Posted Jan 28, 2013 14:40 UTC (Mon) by drag (subscriber, #31333) [Link]
* Get me a list of all system services running.
* Get me their status. * IF they are running then find me the parent PID number and any other processes that belong to the parent. Get me the last few lines of the logs for those services. * IF it has failed to start up get me the exit code for the service and then the last few lines of the logs relevant for those processes.
All this stuff is deadly simple with systemd.
systemctl status vdsmd
for example.
This is a huge boost in productivity for system administrators to be able to have all the information in one spot.
evolution Posted Jan 29, 2013 19:02 UTC (Tue) by dfsmith (guest, #20302) [Link]
I'm not sure I like the adverb "deadly" simple.
evolution Posted Jan 28, 2013 18:05 UTC (Mon) by iabervon (subscriber, #722) [Link]
I'm fine with the system booting regularly with declarative text files that I didn't write instead of shell scripts I didn't write. But I like to be able to boot with init=/bin/bash and fix things, and be able to configure networking (in order to download a non-broken version of a package, for example) with the usual mechanism. While I would ordinarily have systemd running as pid 0, I think it's important that programs (in particular, the other executables in the systemd tarball, which are not supposed to be part of the same monolith) to function if systemd isn't running, or if something else is pid 0. What I've seen from systemd developers suggests that I can't get an environment where services haven't been started in general, but I can interactively start them and also run "avahi-browse | less" and my text editor. (I'd look at the documentation of systemd debugging, but I get a 503 from the link Lennart provided.)
(I don't use an early userspace, so init=/bin/bash actually does work for me presently.)
evolution Posted Jan 28, 2013 18:22 UTC (Mon) by iabervon (subscriber, #722) [Link]
Actually, now that that page loaded, I see that systemd debugging is actually much like I described. So my complaint is just that the first-level myth busting didn't say that, but hid it behind a flaky link. Lennart says "Some people try to imply that the shell was a good debugger." but (a) the shell actually is a great debugger, when you have good command-line tools and (b) that's what systemd actually provides. I think this exemplifies the biggest myth about systemd, which is that, in order to get any benefit from it, you have to entirely redo your system and learn all new stuff; this mostly comes from systemd developers saying (probably accurately) that each thing in your old system is terrible and you'd be better off replacing it.
evolution Posted Feb 6, 2013 3:17 UTC (Wed) by vonbrand (subscriber, #4458) [Link] Sorry, but my extensive experience with assorted shell scripts handling system-y stuff is that they are about as easy to debug as your running kernel, irrespective of tools available (and when things really go south, the requisites for any tools higher up than a well-placed echo just aren't available at all).
evolution Posted Jan 28, 2013 21:54 UTC (Mon) by smurf (subscriber, #17840) [Link]
Well, with SysV init you remember to type "init=/bin/bash" for a basic root shell with which to attempt to fix stuff.
With systemd it's "systemd.unit=emergency.service". Somewhat more verbose, but I just set my alternate boot command line to it and I'm done.
>> systemd developers suggests that I can't get an environment
Who suggests that, and where? It's patently false. In an emergency.service environment you can "systemctl start foo.service" just like you normally do.
evolution Posted Jan 28, 2013 23:27 UTC (Mon) by iabervon (subscriber, #722) [Link]
The statement:
"Some people try to imply that the shell was a good debugger. Well, it isn't really. In systemd we provide you with actual debugging features instead. For example: interactive debugging, verbose tracing, the ability to mask any component during boot, and more."
suggests to me that, if you have some problem booting with systemd, you get a special systemd debugger rather than the shell. This makes me worried, because I suspect that I might have problems unrelated to systemd, and might actually have to run the configuration tool for some other service that's needed in order to authenticate users, and a systemd-specific debugger might not make that feasible. However, the truth is that the shell is a good debugger, and it's what systemd actually provides, along with command-line tools to help debug systemd in particular. This is a particularly unfortunate statement, because it plays into the impression people have of systemd that the developers think the tools you understand aren't good and you need to use their new thing instead in order to work with systemd.
evolution Posted Jan 28, 2013 23:56 UTC (Mon) by HelloWorld (guest, #56129) [Link]
> suggests [...] suspect [...] might [...] impression
Really, whom is this kind of discussion supposed to help? Grown-up people in computing ought to be able to make an argument based on facts.
evolution Posted Jan 29, 2013 11:37 UTC (Tue) by nix (subscriber, #2304) [Link]
Facts?! In *this* industry?
Come on now. Why dirty a nice flamewar with nasty facts when you can have a stew of speculation and imputations of bad faith and attacks based on myths which are debunked in the very article this is a comment thread for?
The only thing we're missing is a nice car analogy! So let me provide one.
systemd's an Edsel with the trailer and aircraft-carrier-catapult attachments, sysvinit is a Peel Trident. (I just want a Volvo.)
evolution Posted Jan 31, 2013 13:37 UTC (Thu) by ncm (subscriber, #165) [Link]
systemd is a flying submarine. sysvinit is a boat anchor with feathers.
evolution Posted Jan 29, 2013 7:49 UTC (Tue) by smurf (subscriber, #17840) [Link]
>> suggests to me that, if you have some problem booting with systemd,
>> you get a special systemd debugger rather than the shell
Wrong. You get a shell.
Of course you'd then use systemctl commands to figure out what's wrong with your boot (start services individually, etc.), but that's a Good Thing – you want to start your bootup jobs in the same environment as when booting regularly, otherwise you might mask the problem.
evolution Posted Jan 29, 2013 8:53 UTC (Tue) by iabervon (subscriber, #722) [Link]
That's what I said: "However, the truth is that the shell is a good debugger, and it's what systemd actually provides, along with command-line tools to help debug systemd in particular."
Of your comment, my comment, systemd's actual behavior, and Lennert's original post, the only one that doesn't say that a shell plus systemctl is the right thing is Lennert's original post. That's why I said that *Lennert's writing* gives the wrong impression, and never said that systemd's *actual behavior* was wrong.
evolution Posted Jan 29, 2013 17:33 UTC (Tue) by raven667 (subscriber, #5198) [Link]
I think the point was supposed to be that there is a bunch of debug logging available in the systemd tool kit that isn't available in shell languages beyond 'set -x', maybe because in shell that doesn't show you the environment or working directory or other things or because debugging shell requires modifying the scripts to print out what they are doing rather than having built-in logging.
evolution Posted Jan 29, 2013 16:18 UTC (Tue) by s0f4r (subscriber, #52284) [Link]
Just typing "emergency" will also drop you in emergency mode - it's shorthand for "systemd.unit=emergency.service"
|
|||||||||||||