| |||||||||||||
Fast bootFast bootPosted Nov 8, 2012 16:30 UTC (Thu) by man_ls (subscriber, #15091)In reply to: LCE: Systemd two years on by nix Parent article: LCE: Systemd two years on 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.
(Log in to post comments)
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?
|
|||||||||||||