| |||||||||||||
LCE: Systemd two years onLCE: Systemd two years onPosted Nov 8, 2012 15:38 UTC (Thu) by gb (subscriber, #58328)In reply to: LCE: Systemd two years on by nix Parent article: LCE: Systemd two years on
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.
(Log in to post comments)
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.
|
|||||||||||||