[arch-general] Re: My end-user $0.02 on /etc/rc.conf splitting.
The 23/07/12, Kevin Chadwick wrote: > Ignoring systemctl output which is still less clear and slowed me down. I don't agree. > Show what daemons will be running if you were to boot a filesystem > which isn't running and tell me it's as quick to work out on a systemd > system. http://fedoraproject.org/wiki/How_to_debug_Systemd_problems http://0pointer.de/blog/projects/self-documented-boot.html -- Nicolas Sebrecht
[arch-general] Re: My end-user $0.02 on /etc/rc.conf splitting.
The 25/07/12, Kevin Chadwick wrote: > > If a service is not provided: > > - with SysVinit you have to write the whole script usually relying on > > whatever library the distribution provides (which tend to be > > error-prone); > > - with systemd, you just write a configuration file. > > > > Well arch has some includes to make it prettier. Look: > On OpenBSD you have <...> > or <...> > or <...> I don't find that pretty nor even smart at all. > This also demonstrates how easy shell can be Or not. Come back to reality (and I won't talk about BSD systems which are not the Linux world), shell scripts for init are a nightmare for plenty of reasons: - various API; - API not always fully respected in all the scripts; - no real journal; - almost nothing in API for detailed logs; - bad experience with parallelism; - static dependencies; - not events aware (except for TCP sockets); - slower; - almost no cgroup isolation support (and so goes for resource limits strategies); - almost anything for IO class and priority; - nothing well-defined to wait for availability of resources (remote fs, advanced authentication protocols, etc); - tracking of jobs/daemons sucks; - respawing absent; - no D-BUS interface; - no possibility to select which daemons to start from kernel command line (so multi-environments configuration for laptops often sucks); - relying on large binaries (starting from the shells); - etc, etc. Nobody will convince me that the pretended easy, smart, robust, hacking-friendly, etc world of init scripts is a wonderfull world which just worked for ages. I've had too many glitches for years (often hard to resolve) ― sometimes indirectly related from so unexpected pieces of the system ― to believe such thing, sorry. The ini style for configuration files of systemd or the rc.conf split into 3 or 5 files looks to be nit-picking to me. > One of the founding principles of UNIX is that small tools that do > a single job well allow complete flexibility whereas large tools do > what the devs foresee very well but will likely hinder users or the > unforeseen uses (hacking). Hackers know C. Admins don't hack and write scripts, too often poorly; whatever my statement will hurt readers or not. -- Nicolas Sebrecht
[arch-general] Re: My end-user $0.02 on /etc/rc.conf splitting.
The 25/07/12, Heiko Baums wrote: > And this is against UNIX philosophy and makes it like something > proprietary, at least it's anything else than comfortable. Why not just > using a simple text file where I can list every "service" that I want > to have started? systemd could easily read this file and do whatever it > thinks to have been done internally. Right. I don't pretend systemd is perfect. This concern is more about how to configure systemd, so it's more configuration interface thing rather than not following "Unix philosophy" by internals. Now, the CLI problem is limited to enabling/disabling daemons. Saying systemd is against Unix philosophy only because of that is a bit exaggerated, IMHO... Oh wait, there's also the ini configuration files. Well, this is still limited to the user interaction. > Btw., it's called "daemon" in Linux and UNIX. It's called "service" in > Windoze. So one more step towards a second Windoze. The naming scheme > in systemd is also not really the best. Sorry to have affect you because of my semantic. > Why do I have to tell systemd in all of those init scripts what > "service" has to run before or after this "service"? In DAEMONS in > rc.conf I just have a list of daemons I want to have started in one > single line. And the order in which they have to be started is the > order in which I list those daemons. Just plain and simple, and can > easily be parsed. This might be true for a given distribution. Each has its own API and glitches. In a bigger perspective this is wrong. Let's manage more than a distribution to understand what I'm talking about. It's worse when you know that all daemons in a distribution might be configured than /one/ init system. This is the case for Ubuntu where all daemons are not upstart ready, for example... Enjoy! > > This is systemd internals. It's not expected from the user to play > > with symlinks. > > Just like in proprietary software. Once again: Why does it need such > symlinks in some cryptic directories? The point is, I want to have full > control over my system and not to rely on some software's internals. Again, this sounds somewhat exaggerated. Other tools work this way (configuration files + CLI) whithout hurt: mdadm, udev, sysclt, grub... > And I don't want to read source codes to know what an init system is > doing. And full control includes knowing what file is saved where and > doing what. No. Full control is a licence issue, ONLY. What you're talking about is a totally different thing. It's wrong to talk about control for a software where the user interface is giving the _feeling_ that YOU have control over the software. > > No, I won't assume something that the software is going wrong. I > > assume the change raise fear, whether it is well-founded or not. > > Wrong, if there's such a long discussion, there is something going > pretty wrong. We just disagree here. No matter, it's just a matter of taste about the interpretation if this thread. > If this software would be that well-founded, nobody had a > problem with it, nobody would fear anything, Notice that "a well-founded software" and "users having a problem with it" are uncorrelated, to me: - A "well-founded software" is a software which matches what it has been written for. - A "user having problem" can either be a real problem from the software or anything about the user feelings. -- Nicolas Sebrecht
[arch-general] Re: My end-user $0.02 on /etc/rc.conf splitting.
The 26/07/12, Heiko Baums wrote: > Principally right again. But I have a problem with booting daemons in > parallel, on Gentoo as well as on Arch. Made several problems. But I > can't tell anymore which. So I prefer booting in serial, even if it's > slower. Right. It's not much surprising that Gentoo and Arch had problem while trying to get init start daemons in parallel because none of these init scripts were initially designed for that purpose. > If I recall correctly this was also one of Arch's advantages > over Gentoo that I just could add the daemons to the DAEMONS array in > rc.conf and choose the order myself. I expect from systemd to highly change such bad user experience in the world of parallel init. > I must admit that I didn't use OpenRC and Upstart, yet. I switch to > Arch right before OpenRC was introduced in Gentoo. I have Gentoo systems and enabling parallel in them made systems ran into problems, here. -- Nicolas Sebrecht
[arch-general] Re: My end-user $0.02 on /etc/rc.conf splitting.
The 25/07/12, Heiko Baums wrote: > In Linux I have/had some simple text files with which I can/could > configure the whole system, while I had a terrible, cryptic registry on > Windoze. I can find anything in systemd which could make think of the registry on Windows. > In Linux I just can/could add a daemon to rc.conf to have it > run. From what I read so far about systemd in all those discussions, in > systemd I have to run a special command to have a daemon started at > boot time (which I additionally have to remember), I have to write such > an ini file instead of just writing or editing a simple and small > config file or shell script You are mixing up two things: - adding/removing services on boot; - configuring the services. The first - adding/removing services - changes with systemd. Yes, it is done using a dedicated command (which comes naturally with autocompletion, here with zsh at least). This is for services provided by the distribution. If a service is not provided: - with SysVinit you have to write the whole script usually relying on whatever library the distribution provides (which tend to be error-prone); - with systemd, you just write a configuration file. For the second, whether you use systemd or SysVinit, configuring a service is typically done by editing the configuration file dedicated to this service. In systemd, the file is declared like this EnvironmentFile=/etc/conf.d/nfs which is by itself much easier to hack (rather than reading in a shell script to find where and how such a file is used). > then systemd creates some symlinks of > files into another directory whose name is also totally cryptic, at > least way to long. This is a total mess, if this is really true, and > it's absolutely a step towards a second Windoze. This is systemd internals. It's not expected from the user to play with symlinks. > But if there's such a long discussion and if there are so many > complains about a software or a change, then you can assume that > there's something going pretty wrong. No, I won't assume something that the software is going wrong. I assume the change raise fear, whether it is well-founded or not. > I never ever have > read such long discussions and so many complains about a software like > about the software of Lennart Poettering (PulseAudio and systemd). OTOH for the systemd case, we are changing of paradigm for the boot process. I'm not aware of such a change in the boot process for years. All recent event-based init systems have raise fear. -- Nicolas Sebrecht
[arch-general] Re: My end-user $0.02 on /etc/rc.conf splitting.
The 24/07/12, Kevin Chadwick wrote: > > > Did you read this before posting. It's obvious that reviewing the config > > > files and getting the source and finding the bug in C is much easier of > > > course and can be fixed immediately by anyone without another OS or > > > machine. > > > > Did you read this before posting. It's obvious that when a service is > > failing, everybody first think it's because of the init process and try > > to fix the bug in the /sbin/init C sources. > > It's funny how you think init which was designed to be as simple as > possible is likely to have as many bugs as systemd. It's funny how you think init scripts ― without consistant/sensible design over them, not deployed as widely as systemd and touched by so many people ― are likely to have as many bugs as systemd. -- Nicolas Sebrecht
[arch-general] Re: My end-user $0.02 on /etc/rc.conf splitting.
The 23/07/12, Kevin Chadwick wrote: > Did you read this before posting. It's obvious that reviewing the config > files and getting the source and finding the bug in C is much easier of > course and can be fixed immediately by anyone without another OS or > machine. Did you read this before posting. It's obvious that when a service is failing, everybody first think it's because of the init process and try to fix the bug in the /sbin/init C sources. > 'silently failing', only if it's meant to. A running software does exactly what was written from all the involved sources. What next? -- Nicolas Sebrecht
[arch-general] Re: My end-user $0.02 on /etc/rc.conf splitting.
The 23/07/12, Fons Adriaensen wrote: >Please tell me why you think > I need it. Mount usb keys as a normal user ? So, you're more aware of some benefits than what you stated before. > I can arrange > that without ck. So, requiring that someone has to "arrange" things is not the choice done by upstream. Does it have to do with Arch? No. Precisely _because_ Arch wants itself to KISS. > that without ck. Change ownership of some things to a > 'local' login ? I don't want that to happen. You're free to fight again changes or improvements. The simplest way I know consist in installing a 70th year old system and don't update it. -- Nicolas Sebrecht
[arch-general] Re: My end-user $0.02 on /etc/rc.conf splitting.
The 23/07/12, Heiko Baums wrote: > Am Mon, 23 Jul 2012 09:36:05 +0200 > schrieb Nicolas Sebrecht : > > Who is manually editing each configuration one after the other need > > lessons on administration tasks. > > I don't think so. Who manually edits config files just don't trust all > those merging tools, because he has made bad experience with those > tools or has other reasons and wants to keep full control over his > config files. And believe me, checking if the merging tools made what > they are expected to do is much more time consuming than manually > editing those files. I think we are not talking about the same thing. I'm talking about merging tools. I don't know of any merging tool on earth doing the choice of patching whithout asking for conflict resolution from the user. > I don't need to edit those files so many times. And if I have only one > short file like /etc/rc.conf I have all my settings at a glance and > only need to type "nano /etc/rc.conf" only once instead of several > times "nano /etc/vconsole.conf", "nano /etc/hostname.conf" or whatever. > This is a lot more time consuming. No, no. Even without merging tool, 3 or 5 files instead of one is not time consuming. What is time consuming is a system strongly damaged because of human mistake in a configuration file, more likely to happen with a one-central-configuration-file-for-non-related-things-around. > One single /etc/rc.conf is a bit more KISS. One single rc.conf is not KISS. :-) I think this principle is mainly misunderstood. KISS principle makes sense for integration from upstream. It's definetly NOT about "how simple it looks like". -- Nicolas Sebrecht
[arch-general] Re: My end-user $0.02 on /etc/rc.conf splitting.
The 22/07/12, Fons Adriaensen wrote: > Simple example: I didn't have consolekit for some years, and I don't > care about whatever it has to offer. ...This may be why you don't understand benefits of such tools... >So far it hasn't done anything evil except being useless and > consuming system resources (50 or so threads). ...and why you think it's only comsuming resources. >Same about polkit Erf! Same causes, same consequences? Do you really think upstream developers are all doing the bad choices in order to make you feel less compliant with the so-loved historical Unix philosophy? Come'on guys. You can't make serious argumentation wihout making a bit of expected normal researches or by starting in the /same/ mail "I don't care about whatever it has to offer". Upstream choices is not about feelings. -- Nicolas Sebrecht
[arch-general] Re: My end-user $0.02 on /etc/rc.conf splitting.
The 22/07/12, Shridhar Daithankar wrote: > > I was on systemd once, about an year back.. just to find out first-hand, what > the hoopla is all about. It worked, no fuss but nothing great over current > initscripts for a typical developer workstation/desktop. > > However one fine day, an abrupt power-cut later, my home partition was no > longer mountable under systemd. Initscripts worked fine. So I switched back.. > didn't miss a thing.. You're wrong. SysV init scripts _are_ broken, today. But it's silently failing without even noticing it to users in many cases. Finding such boot errors is painfull and time consuming. > -- Nicolas Sebrecht
[arch-general] Re: My end-user $0.02 on /etc/rc.conf splitting.
The 22/07/12, Heiko Baums wrote: > That said, Gentoo always had separate config files located > in /etc/conf.d. So the idea of not having one single rc.conf is not > this new. Nevertheless one single /etc/rc.conf makes the administration > a bit more comfortable, because you have all settings at a glance and > don't need to cat or edit several files. Sounds like you (don't take this a personal critism, you're not alone) have poor administration practices. Editing multiple files instead of one in not a problem at all. In fact, it's the exactly opposite. The pain is the need to merge new changes while updating. Some tools (like pacdiff) can help with the job but it's very frustrating to have one configuration file and merge lot of changes in it. Especially when it comes to cosmetic/comments changes. Having one big configuration file means it's much easier to make mistakes in it and have strong problems because of that. Dedicated files to services/requirements make such problems more isolated. So, we're going a better robustness, better expectations compliance for new incoming users (and admins having more than one arch desktop to maintain). Who is manually editing each configuration one after the other need lessons on administration tasks. If merging tools are not good enough, then let's improve them. But please all, don't make a shoot on current changes. What Tom is doing is exactly what most of ArchLinux users expect. And the philosophy, KISS principle or whatever theory that you think is good in Archlinux is not beeing broken at all. -- Nicolas Sebrecht
