Recent Features
| |||||||||||||
LCE: Systemd two years onLCE: Systemd two years onPosted Nov 8, 2012 13:49 UTC (Thu) by nix (subscriber, #2304)In reply to: LCE: Systemd two years on by gb Parent article: LCE: Systemd two years on
All this 'fast boot' stuff seems terribly... academic to me: the slowness of booting my systems is not caused by sysvinit, nor by the kernel, but by the BIOS, which systemd cannot touch. No PC I have ever owned has got out of POST in less than twenty seconds: my current server-class hardware takes well over a minute. Ditching shell scripts for init to shave a second or two off that seems a massive change for a very small gain. (But it is true that ditching shell scripts for the common case has a lot of other advantages too. sysvinit shell scripts *are* disgusting.)
Maybe all this applies to laptops resuming from suspend too (but they don't follow the normal boot path!). The one laptop I own takes 'only' ten seconds to POST, so perhaps they are generally faster to boot as well...
(Log in to post comments)
LCE: Systemd two years on Posted Nov 8, 2012 14:56 UTC (Thu) by cortana (subscriber, #24596) [Link]
IME, computers sold to end users (desktop and laptops alike) have much faster POSTs than motherboards that are sold to enthusiasts. Servers are of course in a class of their own. So the impact of speeding the boot time will be felt more on consumer-oriented systems.
LCE: Systemd two years on Posted Nov 8, 2012 15:38 UTC (Thu) by gb (subscriber, #58328) [Link]
From my point of view, problem of this approach that 'fast boot time' is the only criteria, not maintainability, not reliability, not fault-tolerance, not easiness to learn, not reconfigurability. The only criteria praised is very end-user oriented 'boot time', which actually... doesn't matter! On user machines i guess it's much faster to do suspend to disk. On servers startup time doesn't matter, you need reliability there and maintainability. So where do you need fast boot time??? I know only one application - embedded devices, but still, they may use suspend to disk, it would be also real hell i guess to debug such binary boot on embedded device.
LCE: Systemd two years on Posted Nov 8, 2012 17:57 UTC (Thu) by admax88 (subscriber, #75035) [Link]
As an end-user, I appreciate when projects take end-user oriented criteria into account.
LCE: Systemd two years on Posted Nov 8, 2012 22:54 UTC (Thu) by jtc (subscriber, #6246) [Link]
"From my point of view, problem of this approach that 'fast boot time' is the only criteria, not maintainability, not reliability, not fault-tolerance, not easiness to learn, not reconfigurability."
Are you saying that the only criterion of systemd is fast boot time? (Or are you talking about something else?) If so, this appears to completely contradict what the systemd author's claim are the goals of systemd. For example, the article says:
"That repackaging allows a more integrated approach to the boot process that also eliminates some code and feature duplication that occurred across the formerly separate components. By eliminating duplication, and providing a more integrated approach to the boot components, the resulting system is easier for system administrators to manage."
Are you implying that this claim is a lie? And how do you come to the conclusion that maintainability, reliability, etc. are not part of the goals of systemd?
LCE: Systemd two years on Posted Nov 9, 2012 1:56 UTC (Fri) by marcH (subscriber, #57642) [Link]
> "That repackaging allows a more integrated approach to the boot process that also eliminates some code and feature duplication that occurred across the formerly separate components. By eliminating duplication, and providing a more integrated approach to the boot components, the resulting system is easier for system administrators to manage."
> Are you implying that this claim is a lie?
A lie, probably not.
A attempt to disguise an enjoyable and beautiful engineering exercise as something performed to solve important problems users loudly complained about; maybe yes.
Don't get me wrong: many good engineers tend to be guilty of this. As recently posted here: http://www.jwz.org/doc/cadt.html
LCE: Systemd two years on Posted Nov 9, 2012 9:15 UTC (Fri) by BradReed (subscriber, #5917) [Link]
A jwz comment from 2003 is recent?
LCE: Systemd two years on Posted Nov 9, 2012 23:26 UTC (Fri) by artem (subscriber, #51262) [Link]
'Here' in this context means another lwn thread where that 2003 comment was mentioned recently.
LCE: Systemd two years on Posted Nov 9, 2012 12:23 UTC (Fri) by gb (subscriber, #58328) [Link]
> Are you saying that the only criterion of systemd is fast boot time?
Read this:
http://0pointer.de/blog/projects/systemd.html
What i see in that design? "Do fast, do parallel, start less, integrate everything".
What i expect?:
There is even no such words in grounding ideas of systemd!
LCE: Systemd two years on Posted Nov 9, 2012 17:46 UTC (Fri) by develop7 (guest, #75021) [Link]
> be predictable
well, it is. as soon as you'll read man. > be easy to learn done. > be easy to maintain it is. > be reliable check > reuse as much existing tools as possible Yeah. We definitely should use /usr/bin/ionice instead of appropriate unit config parameter (IONice=). Who cares 90% of ionices' code is about CLI switches and environment variables handling. It's 21st century after all, our CPUs are fast enough anyway.
LCE: Systemd two years on Posted Nov 9, 2012 21:11 UTC (Fri) by gb (subscriber, #58328) [Link]
You see ionice? I see years of different high skilled people work and thousands lines of high-quality code.
LCE: Systemd two years on Posted Nov 9, 2012 23:47 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
A nice argument.
"You see 1000 lines of tangled COBOL code? I see years of different high skilled people work and thousands lines of high-quality code."
LCE: Systemd two years on Posted Nov 9, 2012 23:51 UTC (Fri) by nix (subscriber, #2304) [Link]
You picked a really bad example. ionice.c is a mere 200 lines long, and utterly horrible (e.g. using numeric arguments where the actual interface uses a named #define, but apparently exporting that name to the user would have been too hard, just use the numbers dammit).
LCE: Systemd two years on Posted Nov 9, 2012 0:03 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
I've converted my embedded devices to systemd and socket-based activation. I can say that it was much easier than writing sysvinit-based infrastructure in the first place.
On servers systemd also allows to cleanly separate various services into hierarchies. It has already saved me from a memory leak in one app taking down other innocent apps.
LCE: Systemd two years on Posted Nov 9, 2012 19:09 UTC (Fri) by speedster1 (subscriber, #8143) [Link]
A friend of mine has been showing off Linux booting from scratch (not waking from suspend) on an i5 tablet within a couple seconds. People using tablets have been trained to expect this sort of fast response, so this is the a much more relevant use-case for fast boot than those servers with poky bioses.
I really wish server bioses weren't so darned slow as to make fast boot almost completely moot though, since one of my contracts involves developing Linux installs for both servers and workstations... trust me, servers used for testing custom kickstarts get booted a LOT more frequently than typical operational servers.
LCE: Systemd two years on Posted Nov 10, 2012 21:56 UTC (Sat) by zlynx (subscriber, #2285) [Link]
A big chunk of that server BIOS time is ECC init. It might be nice if there was some sort of BIOS flag that could tell the OS, "Hey, I have done ECC init on the first megabyte. Have fun: do the rest yourself."
Then Linux could boot and hot plug each new piece of memory as ECC init completed.
Your system would be a little odd: during the first minute it'd have less than a gigabyte, growing toward the full 64 GB as time went on.
LCE: Systemd two years on Posted Nov 10, 2012 23:09 UTC (Sat) by nix (subscriber, #2304) [Link]
OK, hardware idiot here. Why's ECC init any slower than normal RAM? Even filling all of RAM with a known value doesn't take anywhere near as long as some server boards take to start.
LCE: Systemd two years on Posted Nov 10, 2012 23:32 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]
In a lot of cases the BIOS is actually testing the memory, not just seeing if it exists.
This is a huge waste of time, except when it finds a problem.
In addition, Server boards tend to have other things on them that are careful in their initialization, and have timeouts to detect if things have been connected to them or not.
There is a lot of logic in these peripheral processors, and the BIOS is conservative and serializes all the initialization.
Servers don't tend to reboot that frequently, so the boot time is not a big deal (or if you think it is, you need to be running your app on a cluster anyway, at which point the boot time of any individual server is again not a big deal)
I have some systems at work with large RAID arrays and lots of RAM that take long enough to go through their boot that I can take a CD, boot a fast system that doesn't have all these extras, run my (custom) OS installer, pull the CD out and put it in the slow machine before it gets around to looking for the disk.
LCE: Systemd two years on Posted Nov 15, 2012 9:25 UTC (Thu) by HelloWorld (guest, #56129) [Link] From my point of view, problem of this approach that 'fast boot time' is the only criteria, not maintainability, not reliability, not fault-tolerance, not easiness to learn, not reconfigurability.systemd-managed systems are easier to maintain because unit files are easier to write than init scripts, and because most dependencies don't have to be configured explicitly because of socket/d-bus/etc. activation. They're more reliable and fault-tolerant because systemd isolates services with cgroups, file system namespaces, resource limits, syscall filters etc.. It's easier to learn because of the trivial unit file format and the superb documentation, not to mention the GUI that comes with it. And it's at least as configurable as sysvinit, since you can easily launch a shell script when starting a service.
LCE: Systemd two years on Posted Nov 8, 2012 15:59 UTC (Thu) by engla (guest, #47454) [Link]
The systemd project is doing us a huge favor by integrating together kernel, udev, and services properly. Race conditions are revealed and fixed properly (sockets, dbus IPC). Processes are properly tracked (cgroups) and reliably logged (journald).
Systemd is going by correct first and then fast. Faster boot is not very important to me, my personal vision is *instant* boot, now that would be a game changer! Faster boot is an acceptable stepping stone.
Fast boot Posted Nov 8, 2012 16:30 UTC (Thu) by man_ls (subscriber, #15091) [Link] For me on my new amd64 machine, fast boot is a very important feature: I switch it off every night and turn it on in the morning. However, with Debian testing I am getting a solid ten seconds from pressing enter in GRUB to operative state, of which I estimate that five are spent by the kernel and another five by various tasks and X. (Before there are about 5 seconds wasted by the BIOS and GRUB, and after there are still some apps starting like Firefox or Terminal. Yes, the BIOS in my delicious and cheap Asus mini-ITX P8H61-I is quite fast.) So I am booting my services in five seconds without systemd.You are right that init shell scripts are ugly, but I can edit them in a minute if there is anything wrong with them. Hackability is a more important feature to me than the couple of seconds that I can shave off the total boot time. Luckily Debian provides for all choices here.
Fast boot Posted Nov 8, 2012 20:24 UTC (Thu) by Eckhart (guest, #74500) [Link]
> You are right that init shell scripts are ugly, but I can edit them in a minute if there is anything wrong with them.
You are implying that the classic base system is so badly written that it needs frequent edits – and your conclusion is to *not* rewrite it in a maintainable programming language? Seriously?
Fast boot Posted Nov 8, 2012 21:32 UTC (Thu) by man_ls (subscriber, #15091) [Link] That is a good point indeed. But please note that no system is perfect and that edits and adaptations will be inevitable during its usable life. Especially considering that the init system is not alone and it has to interact with a large amount of base software, and that not everyone updates their full OS every time a new version comes out.For example, I've had to hack on the Linux driver for the fan on my Asus motherboard (it87); nothing serious, just make the C code think that my chip is an it8721 which was the only one that worked. Well, I can tell you that it was much more painful than hacking on an init script to add a new command or adapt it to a different situation. In fact you can add whatever commands you may need, and it is trivial to test your changes.
Fast boot Posted Nov 9, 2012 1:35 UTC (Fri) by marcH (subscriber, #57642) [Link]
> You are implying that the classic base system is so badly written that it needs frequent edits
He is not. On the other hand, you seem to be implying software can be perfect and never require minor bug fixes, workarounds or adaptations.
> ... in a maintainable programming language?
While Bourne shell scripting shows its age and has a number of significant problems, as a higher level language it also has a number of desirable properties that C has not. Not requiring compilation is only one of them.
Fast boot Posted Nov 9, 2012 2:50 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
Requiring C compilation for each change is a strawman.
You need to change SystemD code only for very major new features. Small changes can be done just fine by using wrappers over executable files and/or script hooks (basic systemd functionality).
Fast boot Posted Nov 9, 2012 11:57 UTC (Fri) by gb (subscriber, #58328) [Link]
Wrappers and hooks. Hope that Debian will never integrate this.
Fast boot Posted Nov 9, 2012 12:11 UTC (Fri) by mpr22 (subscriber, #60784) [Link] systemd is available in wheezy, as are upstart, sysvinit, and runit.
Fast boot Posted Nov 9, 2012 12:12 UTC (Fri) by gb (subscriber, #58328) [Link]
I meant never switch completely to it without possibility to choose something else.
Fast boot Posted Nov 9, 2012 13:30 UTC (Fri) by anselm (subscriber, #2796) [Link] Too late. Systemd is already available in Debian for those who want to install it. The jury is still out on whether it will eventually become the default init system for Debian (at least on Linux). There are reasonable arguments both in favour and against.
Fast boot Posted Nov 9, 2012 18:10 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
What's wrong with them?
Oh, and start-stop-daemon (present in almost every Debian initscript) is very much a wrapper already. And an ugly one at that.
Fast boot Posted Nov 9, 2012 11:55 UTC (Fri) by gb (subscriber, #58328) [Link]
> You are implying that the classic base system is so badly written that it needs frequent edits – and your conclusion is to *not* rewrite it in a maintainable programming language? Seriously?
There is big difference between flexibility and problem solving. There are many reasons to change the scripts: learning, configuring, debugging unrelated issues, making a copy. The ability to use system in ways not expected ways is highly valuable thing.
So, ability to easily read and change the scripts has not relation to be "badly written".
And scripts written in bash are significantly more "maintainable" than written in C.
Fast boot Posted Nov 9, 2012 13:42 UTC (Fri) by intgr (subscriber, #39733) [Link]
> And scripts written in bash are significantly more "maintainable" than written in C.
Init "scripts" in systemd aren't written in C either. They're written in a custom declarative language, which is straightforward and well documented. It's very easy to customize these configuration files -- infinitely easier than 100+ line bash scripts dealing with PID files, exit statuses, "sleep" hacks to work around race conditions and distro-specific process management commands that were designed to help write init scripts, but are each inadequate their own way.
But as for maintainability of bash, I still disagree. I'm no fan of C, but when you read a C program, it's usually clear what's happening and how it happens. bash scripts, in comparison, typically consist of some commands duct-taped together with grep, awk, cut, tr etc. There's no way to know what they're doing other than running the command and then reverse engineer which bits of the output it is trying to extract.
Fast boot Posted Nov 9, 2012 16:43 UTC (Fri) by marcH (subscriber, #57642) [Link]
Scripts are not easier to understand than C code because the language is clearer - you are right the Bourne shell is too old and sucks.
Scripts are easier to understand than C code because they're using a higher level language which means comparable things are done in code several times smaller. They are also "faster" to understand because you don't need to find and download the right source code version. They are also faster to understand because, when you are not sure, you can add traces and more generally hack and experiment with them in the blink of an eye with a simple editor (everyone around my cube is able to do that while few people can do similar things in C).
Yes system V init scripts suck in so many ways, yes Bourne shell is the oldest and ugliest of scripting languages, but as a high-level and interpreted language it has a number of desirable features that C - a fantastic but extremely low level language - will never have.
I can't believe I have to explain the most basic characteristics of scripting languages in a forum like this...
Fast boot Posted Nov 9, 2012 17:21 UTC (Fri) by intgr (subscriber, #39733) [Link]
Let me say it again: systemd services are NOT written in C. systemd replaces bash with a new declarative language, which does not have the downsides of bash. If you want to change the way that a service is launched, you change this config file -- you don't have to download or write or compile any C code, making your rant irrelevant to the systemd debate.
> Scripts are easier to understand than C code because they're using a higher level language
You're stating this as if it were a fact, but it's not -- it depends on the task. I won't take this further because it's a red herring to direct attention away from the real argument.
> I can't believe I have to explain the most basic characteristics of scripting languages in a forum like this...
Wow, that's a nice way to say "I'm right and you're stupid because you disagree with me"
Fast boot Posted Nov 9, 2012 21:33 UTC (Fri) by boklm (subscriber, #34568) [Link]
> Scripts are easier to understand than C code because they're using a higher level language which means comparable things are done in code several times smaller.
And domain specific language (such as what systemd uses for its unit files) are also several times smaller and easier to understand than the same things done in a general purpose language like bash.
Fast boot Posted Nov 9, 2012 22:50 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
If it eliminated the need to learn Bash you might have a point. However it doesn't eliminate the need to learn Bash, so it's 'yet another language to learn'
At that point, you have to question if the new language is valuable enough to have to exist instead of re-using one that's already required.
Fast boot Posted Nov 9, 2012 23:09 UTC (Fri) by boklm (subscriber, #34568) [Link]
Actually this is not really a new language, just simple configuration files, so there is no new language to learn.
You need to understand what the options mean, but it is usually obvious with the name, and fully documented in man pages.
When looking at a bash init script, you also need to understand what the variables mean. You do this by looking at the code to find what it is doing. In systemd you look at the man page instead. But only the first time, because the same options are used in all unit files so it's easy to remember, while sysv init script always re-implement the same things in a different way so you need to read everything.
Fast boot Posted Nov 15, 2012 9:47 UTC (Thu) by HelloWorld (guest, #56129) [Link]
There's no new language to learn, systemd's configuration file use the same ini-style format as freedesktop's .desktop files.
Fast boot Posted Nov 15, 2012 9:46 UTC (Thu) by HelloWorld (guest, #56129) [Link] Scripts are easier to understand than C code because they're using a higher level language which means comparable things are done in code several times smaller. Brevity alone doesn't help. intgr's point is that every time you read a command such as And by the way, that's not just a limitation of the bash language but of UNIX shells in general, as their primary means of communication is an unstructured byte stream.
Fast boot Posted Nov 10, 2012 7:50 UTC (Sat) by Eckhart (guest, #74500) [Link]
> There is big difference between flexibility and problem solving. There are many reasons to change the scripts: learning […]
Nothing prevents you from doing that with C files: http://www.freedesktop.org/software/systemd/
> […] configuring […]
You see, this is the main problem with "hackers" (compared to actual programmers): they fail to understand that code and configuration are two different things. "gcc config.c && ./a.out" is *not* a great audio player with a rather complex configuration file.
> […] debugging unrelated issues […]
If you need to change the internals of one component to debug unrelated issues, then your encapsulation is probably wrong.
> […] making a copy
There is no DRM, feel free to copy.
Fast boot Posted Nov 15, 2012 9:31 UTC (Thu) by HelloWorld (guest, #56129) [Link]
So you're saying that you can edit shell scripts in a minute if anything is wrong with them, but editing a systemd unit file is beyond your abilities?
LCE: Systemd two years on Posted Nov 8, 2012 16:35 UTC (Thu) by mirabilos (subscriber, #84359) [Link]
Besides, how often do you boot your Unix systems?
LCE: Systemd two years on Posted Nov 8, 2012 20:17 UTC (Thu) by nix (subscriber, #2304) [Link]
Well, I suspend/resume to disk every night (or I do when it works, which it hasn't for the last few kernel releases: I suspect a radeon problem but haven't done anything to verify this). And every resume requires... a POST. :(
|
|||||||||||||