On Wed, Mar 21, 2012 at 10:49:09AM +0100, Martin Wuertele wrote: > * Marco d'Itri <m...@linux.it> [2012-03-21 09:34]: > > > On Mar 21, Svante Signell <svante.sign...@telia.com> wrote: > > > > > And how do you expect non-experts be able to solve problems when they > > > pop up. Buying consultant services from the experts? > > Non-experts are not able to solve any problem, so this is not an issue. > > But they can provide debugging info and some level of analyses that > helps to triage the problems (and if it's a simple set -x in init > scripts).
This has been asserted quite a few times in the thread, and I think it's an oversimplification of the matter. We have: startpar init systemd ------------- ------------- (lots of) (lots of) shell scripts unit files There's an important distinction between debugging a buggy service (be it a shell script or unit file) and a buggy init implementation (be it sysvinit/startpar or systemd or upstart). Debugging the core sysvinit or systemd code does require programming expertise, but it only needs doing once. Once it's tested and known to work well, the chance of a user running into problems with it is very small. We initially had problems when startpar was introduced: it was buggy in certain cases, and some init scripts had incorrect dependency information, resulting in boot problems. It's now well tested and works well. I'm sure the same will apply to systemd, but it will work very well once the initial teething problems are fixed. It's not common for users to run into major problems with an individual init script, but when they do, I don't agreee that it's easy to debug. init scripts are, by their very nature, full of horribly complex shell script, and understanding what everything does for a single service often requires initimate knowledge of how the service works. While it's possible to manually fix up a script to work by editing it, the reality is that only a few people have the expertise to do that. And the most important point, is that with unit files, you never need to do that: they are so simple, they should be obviously correct. The chance of there being a problem in the first place is vastly reduced. While it's true that if something goes wrong with systemd, diagnosing it and fixing it might be difficult, this is mainly due to our (collective) lack of experience with it rather than there being anything intrinsically more difficult about it. If anything, it promises to be vastly simpler and more robust than the spaghetti mess of shell we currently have to deal with. If there are corner cases where the boot hangs, that's simply something which needs finding and fixing. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120323104431.gc24...@codelibre.net