2012/7/22 Myra Nelson <myra.nelson@hughes.net>:

On Sun, Jul 22, 2012 at 12:26 AM, <kingfisher@almus.net> wrote:

...

...

Hello.

I've read all the arguments of Tom and Ionut. Here is my own $0.02 on it. When I started using archlinux back in end of 2008, the winning point was this file. A centralized one where you can set up a lot of single options.

It is *far* simpler to edit /etc/rc.conf to load daemons or modules than editing 2 or 3 files.

"Killing" /etc/rc.conf can't be do so soon. Or you'll see a lot of old users moving their on other distributions. For me it will be a one way ticket to fedora. And I *do hate* this idea.

But developpers must know better than users what is the best for the distro. Killing /etc/rc.conf ? Why not. But for me, it is more KISS oriented than /etc/locale.conf, /etc/vconsole.conf, /etc/modprobe.d/*.conf files.

As I said, it is my $0.02. Excuse my bad english, I'm no really awake !

-- Frederic Bezies fredbezies@gmail.com

That's exactly my thoughts ... *BSD will be next, if rc.conf been deprecated. Sorry for my English too

I complained about this switch. I tried systemd some time ago and had problems. It took me about 30 minutes of reading and editing to get my system booted and working properly. I'm amazed and if I can do it that quickly anyone can.

I will be too. I'm testing fedora in a virtualbox session, and besides some software not being truly "bleeding edge". This version of simplicity is simply a way to make a lot of users - and some old ones - going to swich on others distros. Which could be very very bad. I really love Archlinux. It is my home distribution for nearly 4 years. I made about an half-dozen people switching to arch. I know arch is a "geeky" distribution. But making it a "die-hard geeky" distribution could kill it. Sorry for being upset and I'm sorry if my words are surprising some people.

Myra

-- Life's fun when your sick and psychotic!

-- Frederic Bezies fredbezies@gmail.com

On Sun, 22 Jul 2012 09:18:50 +0100 Jorge Almeida <jjalmeida@gmail.com> wrote:

I have many customizations, and a rolling release seems essential to me. So, what to do?

Probably it's not ideal, but I'm considering to switch to Frugalware (already running frugalware-current on my netbook). It's systemd-based, but there is no need for AUR, hooks support for pacman... Sincerely, Gour -- One must deliver himself with the help of his mind, and not degrade himself. The mind is the friend of the conditioned soul, and his enemy as well. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810

Am 22.07.2012 10:58, schrieb gt:

You can try aptosid, or linux mint debian edition.

Really Mint ? I switched FROM Mint TO Arch because upgrading Mint ended up in a re-installation of the whole system :-(

On Sun, Jul 22, 2012 at 02:39:35PM +0200, Nelson Marambio wrote:

Am 22.07.2012 10:58, schrieb gt:

...

You can try aptosid, or linux mint debian edition.

Really Mint ? I switched FROM Mint TO Arch because upgrading Mint ended up in a re-installation of the whole system :-(

On Sun, Jul 22, 2012 at 03:38:52PM -0700, David Benfell wrote:

On 07/22/12 05:39, Nelson Marambio wrote:

...

Really Mint ? I switched FROM Mint TO Arch because upgrading Mint ended up in a re-installation of the whole system :-(

Yes, dist-upgrade simply doesn't work anymore because Ubuntu, Mint, and I assume Debian are all making changes between releases that break the upgrades. That, too, is why I switched to Arch Linux.

Nelson, David LMDE is not the usual mint. It is rolling release based on debian testing, so no dist-upgrade stuff. Frankly, I haven't tried it, but I don't think it will break stuff anymore than arch does. All I have heard is praise about it, but I am too engrossed in arch to give it a thought, yet.

Hi, Am 22.07.2012 10:18, schrieb Jorge Almeida:

what should they do when the KISS principle is in a collision course with upstream trends?

You could easily argue that a single rc.conf file is *not* very KISS, whereas on the other hand a bunch of small files - with a name already telling you what it is supposed to do - is *very* KISS. I'm running Arch for a few years myself and to be honest, I never quite liked the idea of rc.conf, as this was something very specific to Arch. Furthermore this whole effort of trying to stop this change by a kind of blackmail is lame, especially the threat that some of you would switch over to Fedora when considering that Fedora is already implementing all of this and probably will always be the first to do so in the future. If you really want to stop it, you should come up with some technical reasons. I haven't heard any so far and I'm not even sure whether there are any. Arch was always - if nothing else - about upstream compatibility and this is just the next step. Considering that you don't change this stuff often anyway, I don't see a problem here, especially because your old rc.conf's will work just fine in the near future. Best regards, Karol Babioch

Hi, Am 22.07.2012 14:43, schrieb Fons Adriaensen:

Fair enough, but for this sort of thing, who is 'upstream' ?

Then let us call it commonality in this case. Although it was introduced by systemd, in principal it has nothing to do with it. Probably most of the major distributions will implement this (and/or already have). Anyone who had to work with different distributions knows what pain in the ass it can be to deal with this kind of differences between distributions. I'm not arguing that every distribution should handle everything in the same way, but some agreement on trivialities like this, is always appreciated. Best regards, Karol Babioch

On Sun, Jul 22, 2012 at 03:02:05PM +0200, Heiko Baums wrote:

Am Sun, 22 Jul 2012 12:43:39 +0000 schrieb Fons Adriaensen <fons@linuxaudio.org>:

...

Fair enough, but for this sort of thing, who is 'upstream' ?

In this case the super-ingenious Lennart Poettering, I guess.

I switched to Arch some years ago to get rid of all that Poetterix stuff. It's become near impossible on most distros. If Arch goes the same way, I'll have to look for something else. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)

On Sun, Jul 22, 2012 at 04:17:13PM +0200, Karol Babioch wrote:

Am 22.07.2012 15:36, schrieb Fons Adriaensen:

...

to get rid of all that Poetterix

Once again this is not a technical argument, but a very subjective reason with - at least for me - no basis. Its more of a philosophy and that's not what this should be about.

If you *really* like an audio stack without PulseAudio (which I would consider quite useless on a modern desktop) and an init system based upon something as old, "stupid" and slow as SysVinit, then you are free to stick with it. Nobody forces you to use PA and/or systemd, and you are always free to come up with something better than that. But don't try to force your personal agenda against Poettering onto others.

For any serious audio (music production, acoustic research, etc.) the first thing to get rid of is PA. It maybe great for the typical desktop user but is quite useless and a pita otherwise. The reason to go to Arch years ago was very technical. I was building a system using 5 PCs to drive a total of 320 audio channels. All but one of those are headless, and everything done on them is via ssh or remote control protocols. So there is no 'local' login or any concept of 'session' on those machines. Yet the processes running there (for normal users, not root) need e.g.access to the audio hardware and other privileges. So what should I do with a system like (at the time) Fedora that forces polkit and consolekit on me, together with their stupid 'session' and 'seat' based logic ? Oh, yes all this could probably have been bypassed or configured, but why should I have parallel security systems anyway. So dump it, and find a distro without that madness. Of course pk and ck have nothing to do with L.P., but they are part off the same movement as Poetterix. If I'd want a system like those people are dreaming I'd buy a MAC. But I prefer one without a zillion daemons trying to outsmart me and making any secure, static system configuration near impossible.

Maybe this is what it is really about: These changes come - more or less - from Poettering and there is quite a bunch of people who for whatever reasons don't like that idea.

I've no personal gripes with Lennart. I had the pleasure to meet him and he's quite a nice person. I just don't like the way some people are trying to 'improve' Unix or redefine Linux. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)

On Sun, Jul 22, 2012 at 5:41 PM, Jorge Almeida <jjalmeida@gmail.com> wrote:

Wrong, they are going to ram systemd down our throats. Believe you me. And why is the onus always on the end-user?

Most of us who work on initscriptst agree that systemd is superior and that most people will move to it one day. However, we are trying very hard to make initscripts a viable option as long as possible. So, no, we are not trying to ram anything down anyone's throats. If you think initscripts is superior, great! We could need more help with testing and feedback on patches at arch-projects@archlinux.org. -t

On Sun, Jul 22, 2012 at 6:17 PM, Nicholas MIller <nick.kyky@gmail.com> wrote:

I'm also curious how the people who work on initscript believe systemd is superior.

I think it's a consensus! Take a close look, there is no doubt. -- Sébastien "Seblu" Luttringer www.seblu.net

On Sun, Jul 22, 2012 at 4:59 PM, Tom Gundersen <teg@jklm.no> wrote:

On Sun, Jul 22, 2012 at 5:41 PM, Jorge Almeida <jjalmeida@gmail.com> wrote:

...

Wrong, they are going to ram systemd down our throats. Believe you me. And why is the onus always on the end-user?

Most of us who work on initscriptst agree that systemd is superior and that most people will move to it one day. However, we are trying very

That's what worries me, that you sincerelly find it superior. I don't doubt your good intentions.

hard to make initscripts a viable option as long as possible. So, no, we are not trying to ram anything down anyone's throats.

I didn't mean the Arch devs, I meant Mr. Poettering & friends. I made clear that I think the Arch devs have a difficult task, trying to keep the Arch spirit while keeping in sync with upstream. This may prove impossible if "upstream" is taken over by a couple of devs with a huge superavit of self-esteem and a deficit of esteem for Unix. Again, having contempt for Unix is perfectly legitimate, but they should assume it and start their own OS. One can always hope that things will change for the better upstream. J.

On Sunday 22 Jul 2012 6:28:58 PM Tom Gundersen wrote:

On Sun, Jul 22, 2012 at 6:22 PM, Jorge Almeida <jjalmeida@gmail.com> wrote:

...

I didn't mean the Arch devs, I meant Mr. Poettering & friends.

Ah, I see.

...

I made clear that I think the Arch devs have a difficult task, trying to keep the Arch spirit while keeping in sync with upstream. This may prove impossible if "upstream" is taken over by a couple of devs with a huge superavit of self-esteem and a deficit of esteem for Unix. Again, having contempt for Unix is perfectly legitimate, but they should assume it and start their own OS. One can always hope that things will change for the better upstream.

I'd like to point out that systemd upstream is very easy to work with, and I have never had problems getting in changes (except for when I was wrong of course). If you have technical concerns and phrase them in a technical way they will be taken seriously. Admittedly there is not much patience for non-technical objections.

Just a satisfied long time user voting in :) I support keeping exiting init system as far as feasible. Its not broken, why change it and all.. having systemd and initscripts running side by side, is best of both the worlds.. BUT rc.conf is merely the front end to it, and matters only so much. If it is replaced by various config files, so be it. So long as they work as documented( and they do, thanks to the arch developers), front end does not matter. systemd is a big project and it will take time to be as reliable as current init scriptS(may be it already is.. haven't tried for an year or so). <anecdote> 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.. </anecdote> And to all the people considering BSD, have you considered that freebsd just got binary updates(dunno about signed packages there), a release back and they are going thr. a major C++ runtime overhaul that will take couple of release to shake down and an year down the line, they will struggle once wayland goes mainstream? arch is the best base OS out there. Its stable by philosophy, has rolling releases and has linux(for comparison with BSD and hardware supports). Nothing else come any closer. -- Regards Shridhar

...

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.

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. 'silently failing', only if it's meant to. -- ________________________________________________________ Why not do something good every day and install BOINC. ________________________________________________________

On Tue, Jul 24, 2012 at 4:38 PM, Nicolas Sebrecht <nsebrecht@piing.fr> wrote:

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.

Its a common fallacy some seem to hold that the only way to fix/debug/customize systemd is to edit the sources. Obviously those who believe so have no idea what .service files are.

...

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. You can batch test a group of scripts quickly if you have to fall back to trial and error. Cross platform peer reviewed scripts would be good of course. -- ________________________________________________________ Why not do something good every day and install BOINC. ________________________________________________________

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.

No one thinks many init systems are better than a couple possibly with a universal interface. (competition being healthy)

-- Nicolas Sebrecht

-- ________________________________________________________ Why not do something good every day and install BOINC. ________________________________________________________

Hi, Am 22.07.2012 17:07, schrieb Fons Adriaensen:

For any serious audio (music production, acoustic research, etc.) the first thing to get rid of is PA. It maybe great for the typical desktop user but is quite useless and a pita otherwise.

Yeah, PulseAudio is mainly aimed for the desktop. If you have special needs, you'll probably need special solutions. That's nothing new, is it?

The reason to go to Arch years ago was very technical. I was building a system using 5 PCs to drive a total of 320 audio channels.

You can't blame the major distributions for something like that, can you. They are aimed for the average desktop of normal people. Something with 320 audio channels is simply not something they aim for.

Of course pk and ck have nothing to do with L.P., but they are part off the same movement as Poetterix. If I'd want a system like those people are dreaming I'd buy a MAC.

No. I want a PC and/or laptop with good multimedia support without being forced to go for a MAC. I would argue that PulseAudio (among others) provides just that.

But I prefer one without a zillion daemons trying to outsmart me and making any secure, static system configuration near impossible.

Well, unfortunately that is something that seems not to be possible. With so many components, there is quite a bunch of daemons running. Obviously you can try to unite them, but that wouldn't be very Unix-like and it is the main point of criticism against systemd.

I just don't like the way some people are trying to 'improve' Unix or redefine Linux.

I'm not sure there ever was a clear "Unix" and/or "Linux" way of doing things. Furthermore Unix was never designed to run on today's hardware. With so many changes during the last few decades, we will always have to "improve" or "redefine" things a little bit in order to suit our needs.

I already suggested a very descriptive name for their new OS. But we end-users of Linux have a reasonable expectation that by using Linux we use a OS that --is Unix-like --is under the user's control and not the other way around

I don't see any of these points violated by the rc.conf splitting. To the contrary: I think it makes it easier an is therefore more Unix-like.

Wrong, they are going to ram systemd down our throats. Believe you me.

I hope they will ;). Personally I'm already using systemd and absolutely do like it.

*There is* something better, namely the BSD init system and the SysVinit init system.

They are both old, slow and "stupid".

Is SysVinit stupid?

By stupid I mean the following: They assume that I, as a user, have to care about dependencies and things like that.

By all means, produce something better if you feel you're better that the author(s) of SysVinit.

I'm just saying that these systems are quite old and there was a time they suited the need just fine. But nowadays parallelization is something that should absolutely be part of an init system. There is a whole lot more to it, and it is well explained in the blog posts of Lennart [1]. If you would have read it, you wouldn't try to argue for SysVinit.

Do you *really* have to use a different init system? runit and s6 do that.

I *really* need something better than the plain/old SysVinit after having seen the benefit of systemd. It's fast, it's reliable and it offers a lot more advantages over SysVinit (once again, take a look at [1]).

What they won't do is to replace other unrelated programs like *chron, and for a good reason: they are made by Unix people.

Maybe there is a reason for that? Like, I don't know, maybe a bunch of

Maybe I'm just ignorant, but what is "*chron" supposed to be? I suppose you mean "cron", but I don't get why systemd would replace that? Just because systemd has some support for timer events, it isn't replacing cron. people

find advantageous to run a unix-like system?

Once again: I'm not sure whether there ever was something like a "Unix" system. Furthermore I don't get why systemd is not Unix-like. I would argue that it is a response needed in order to get the maximum out of our hardware, which differs quite extensively from the one Unix was originally designed for. Am 22.07.2012 18:17, schrieb Nicholas MIller:

I'm also curious how the people who work on initscript believe systemd is superior.

Just take a look at [1]. Am 22.07.2012 18:22, schrieb Jorge Almeida:

That's what worries me, that you sincerelly find it superior. I don't doubt your good intentions.

I'm not aware of anyone who has looked into it and doesn't find it superior. How else would you explain that all the major distributions are switching over and/or already have? Even before systemd there was "Upstart", because Canonical "discovered" that the old way of booting is not up to make most out of today's hardware. Best regards, Karol Babioch [1] http://0pointer.de/blog/projects/systemd.html

Once again: I'm not sure whether there ever was something like a "Unix" system. Furthermore I don't get why systemd is not Unix-like.

The Unix philosophy of write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface (Doug McIlroy)

I would argue that it is a response needed in order to get the maximum out of our hardware, which differs quite extensively from the one Unix was originally designed for.

That is exactly what unix was designed for in various flavours but performance and so cpu handling depends on the application. Systemd is larger than init, so for embedded it may well quadruple boot time.

Am 22.07.2012 18:17, schrieb Nicholas MIller:

...

I'm also curious how the people who work on initscript believe systemd is superior.

Just take a look at [1].

A list made to impress. If you actually look at what it means to you, is it so attractive.

Am 22.07.2012 18:22, schrieb Jorge Almeida:

...

That's what worries me, that you sincerelly find it superior. I don't doubt your good intentions.

I'm not aware of anyone who has looked into it and doesn't find it superior. How else would you explain that all the major distributions are switching over and/or already have? Even before systemd there was "Upstart", because Canonical "discovered" that the old way of booting is not up to make most out of today's hardware.

Is debian switching if not I believe ubuntu and debian probably make up far more share than perhaps all the others. -- ________________________________________________________ Why not do something good every day and install BOINC. ________________________________________________________

On Mon, 23 Jul 2012 17:57:46 +0200 Tom Gundersen <teg@jklm.no> wrote:

On Mon, Jul 23, 2012 at 5:35 PM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:

...

Systemd is larger than init, so for embedded it may well quadruple boot time.

What utter bullshit. Please, Kevin, if you are going to throw around numbers, do some measurements first.

systemd is so far even more successful in embedded environments than in desktop ones (i.e. embedded people seem to be more eager to ship it), I doubt that would be the case if it is four times slower to boot. I'm currently using it on my raspberry pi, without any problems. I have not done any performance measurements, but there are very good reasons why initscripts are expected to be slower than systemd (on the same setup) and it has nothing to do with bash versus C, or the size of the binaries.

To add, in general sysVinit does not see much use in modern embedded systems. For instance, (open)webOS (and probably android) has gone the upstart way. So far, only network appliances use sysVinit, but these are pretty conservative, e.g. many are still on 2.4 kernels (stock cisco, tomato, dd-wrt, etc).

...

Is debian switching

That remains to be seen. There are certainly lots of debian people involved with systemd upstream, and there are people working on systemd integration in debian.

-t

-- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D

On Mon, Jul 23, 2012 at 05:57:46PM +0200, Tom Gundersen wrote:

...

Is debian switching

That remains to be seen.

If Debian intends to continue support for Hurd and KfreeBSD they can't move to systemd -- which relies on Linux kernel features to work. That debian has a disincentive is not the same as Arch having a disincentive, tho'. I would rather we use DJB's daemontools as process 1 but I know exactly how these arguments tend to go.

...

Systemd is larger than init, so for embedded it may well quadruple boot time.

What utter bullshit. Please, Kevin, if you are going to throw around numbers, do some measurements first.

You keep picking on other subjects too at one tiny part without considering all that I have said. /sbin/init 32K actually larger than I thought considering it's job was designed so tightly bound. /bin/systemd > 800K (26 times as large) I have an embedded board sitting right here that can run Linux and has 64K of SRAM by default. As I have said you are talking about Linux systems that are nearer the top smaller end of the embedded and actually my Android probably takes longer to boot than my desktop, maybe when I get time as Sony aren't providing updates as they promised I will mod cyanogen to boot a bit quicker or stop it slowing down further if systemd lands with a simple init. My real point was that the systemd speed argument was pointless and the bloated argument in violation of UNIX principles wasn't. There is nothing stopping building concurrency on top of init like Upstart which obviously has major issues. Do you have any numbers on how much time it saves you. I know Gnome takes many many times longer to load than systemd saves! -- ________________________________________________________ Why not do something good every day and install BOINC. ________________________________________________________

On 07/24/2012 09:09 AM, Tom Gundersen wrote:

...

...

...

Systemd is larger than init, so for embedded it may well quadruple boot time. What utter bullshit. Please, Kevin, if you are going to throw around numbers, do some measurements first. You keep picking on other subjects too at one tiny part without considering all that I have said. You win. I usually try to answer all emails aimed in my general

On Tue, Jul 24, 2012 at 1:38 PM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote: direction, however with the last onslaught of spam from you, I just can't find it in me any more.

Anyone with the least bit of clue will by now have realised that you don't know what you are talking about. So anything I add will just be a waste of everyone's time.

-t

I am sorry you think any thing you have will be a waste of time. I am looking at this "problem" of moving to systemd, staying with current init scripts or moving in the LSB init scripts direction. In order for one to make an informed decision one needs to consider all the facts. Without your insight or wisdom how would/will I do that? Discussion is healthy

On Tue, Jul 24, 2012 at 3:24 PM, Baho Utot <baho-utot@columbus.rr.com> wrote:

...

I am sorry you think any thing you have will be a waste of time. I am looking at this "problem" of moving to systemd, staying with current init scripts or moving in the LSB init scripts direction. In order for one to make an informed decision one needs to consider all the facts. Without your insight or wisdom how would/will I do that?

Discussion is healthy

I'm happy to discuss and answer any questions. However, Kevin's emails were: off-topic (this thread was not on systemd, but on rc.conf), irrelevant (the kind of embedded systems he is talking about would never run Arch),

Well you brought them on topic by saying at some point we will have to embrace systemd and I wasn't the one who commented first. I wonder if ArmArch will run systemd. They may not run arch but they have code and scripts ported over. Of course those scripts can easily be wrote. Also with the 3.4 kernel recently getting NOMMU support. I hope desktop and embedded will get closer not further away. I also wonder if every original process is forked from systemd like init? Is it? Then does that mean a megabyte rather than 32k of memory is being copied even when transforming into other far smaller processes. That shouldn't go down well in any embedded world where ram may actually be a rom.

To give a couple of comments, for those who have not looked at systemd yet:

Firstly, systemd is bigger and does more than sysvinit. The reason for this is that it moves functionality out of the individual daemons and into init. This functionality is stuff that would otherwise have been implemented over and over again in every daemon or rc script, each time it is implemented it would be a potential for bugs. Now we have it all in one place, where we can all work together to test and review it. The kind of features implemented in this way are for the purposes of security and reliability of the daemons on your system (i.e. it will monitor them and deal with crashes, it will lock down the kinds of things a daemon is allowed to do, what directories it can read/write to, what system calls it can make, what user it is run as, etc). I would not call this bloat, quite the opposite. It means that the total amount of code on your system, and the total amount of potential for bugs drastically decreases.

Secondly, most of the functionality of systemd is separated out in separate processes/tools, and are not part of PID1. In fact, we use these tools also in initscripts, and this is why I believe we will be able to maintain initscripts, even if systemd should take over for most users. Initscripts currently use the following systemd tools:

systemd-module-load systemd-udevd systemd-cryptsetup systemd-tmpfiles systemd-sysctl systemd-binfmt systemd-random-seed systemd-vconsole-setup systemd-remount-fs

HTH,

Tom

plain wrong (his descriptions of how systemd works and how to use it has nothing to do with reality).

Please give references if you are going to flame me in future. I don't believe I described how systemd works or how to use it. I hope you don't mind me sharing part of a private mail. We seem to disagree on imposing limits onto the user and I assume init halting being good or bad and your comments at the bottom may also prevent anyone moving away from Arch.

The point is that there is no limit to what you can put in rc.conf.

That's the beauty of it and the essence of UNIX. Which yes has led to variation and perhaps difficulties for the mass market. Atleast systemd has led to the co-operation that may reduce this variation for init scripts users too.

...

...

I'm sorry if I take this with a pinch of salt, but previous claims I have seen you make often prove to be unsubstantiated.

In your opinion, many agree with me and moreso those who have a decent understanding of UNIX.

No, not in my opinion. It is objective fact. You keep on making claims (such as A is more secure/smaller/faster/more accurate than B), and then admit that you actually haven't checked/don't know for sure. I assume the same is the case here. You haven't actually read the systemd documentation or the systemd code.

Not all of it of course but with /sbin/init I didn't need to. There are many ways to skin a cat, which is where I think we are getting crossed wires here. It is clear that 800K of pid 1 is going to have bugs. It is also clear that if this daemon is able to do so much such as starting services upon events that there will be major exploits. It is also almost certain that all systems are not going to require all of the functionality that the 800k represents. I am glad it has some modular nature however. I had already considered that there may be some feature I haven't considered that would have made adoption difficult as IPC would be required otherwise. I guess I wouldn't need that function though too. I'm sure raising the size of pid 1 was a thorn the developer had to contend with in any case. I just hope it wasn't features that overrid the complaints. I may have to find time to look at the systemd list archive. The question is do I want to run systemd. It looks like I don't have to answer that for atleast a long time after which some bugs will have been ironed out and it may have become more modular. Is that correct?

I would assume we would get greater modularity and fewer bugs over time (recently we moved all the sysv compatibility logic out of PID1 and into separate processes, just to give an example).

As to when Arch will require systemd: I have said that I will help with whatever the other devs decide. However, I will not take the lead on a move to systemd, simply because I don't want to deal with the flames.

I am working to make it possible to support both initscripts and systemd "forever". That said, I imagine that the other devs at some point will decide that maintaining our rc scirpts (i.e. the ones shipped with the different packages, not the ones in initscripts) is too much of a hassle and discontinue them. I have no idea when this will happen, if at all, nor do I have any intentions of trying to influence the decisions/timing.

-- ________________________________________________________ Why not do something good every day and install BOINC. ________________________________________________________

On Tue, Jul 24, 2012 at 6:06 PM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:

...

I wonder if ArmArch will run systemd.

ArchLinux ARM ships systemd, just like we do. On my ARM machine (a Raspberry Pi running ArchLinux ARM) I use it, and as I mentioned it works great.

...

I hope desktop and embedded will get closer not further away.

I agree.

But I include uClinux etc. in that which is what the recent support may allow without patching

...

I also wonder if every original process is forked from systemd like init? Is it? Then does that mean a megabyte rather than 32k of memory is being copied even when transforming into other far smaller processes. That shouldn't go down well in any embedded world where ram may actually be a rom.

This is the sort of comments I refer to. By throwing out these statements without even checking/trying first, you are spreading FUD. You preface it with "I wonder", but the effect is still the same.

Ok I'm glad it's not something I still think is a certainty. I find mailing lists can be quite informative and a good place to make people think, that's all. A fork does copy the parent initially. -- ________________________________________________________ Why not do something good every day and install BOINC. ________________________________________________________

On 07/25/12 at 01:47am, C Anthony Risinger wrote:

to reiterate the above ... it works fantastic. the Pandaboard runs 9 custom unit files (1/2 of which are just mods to the shipped unit files):

u.dhcpd4.service u.dnsmasq.service u.fwknopd.service u.hostapd.service iptables.service u.net.dhcp@.service u.net.static@.service u.openvpn.service (writing now :-) u.services.target

What does u.net.static@.service do? If something similar to ifplugd, I'm interested :) Manolo

...

...

Wrong, they are going to ram systemd down our throats. Believe you me. And why is the onus always on the end-user?

Most of us who work on initscriptst agree that systemd is superior and that most people will move to it one day. However, we are trying very

That's what worries me, that you sincerelly find it superior. I don't doubt your good intentions.

I've worked as a Linux sys-admin for 12 years now, and I've always found sysvinit and the bunch of shell scripts, hard to manage and lacking in basic features. What systemd provides now is total knowledge of the state and origin of your processes. That wasn't possible with the sysvinit scheme. It's a great help to anyone working wit Linux professionally. The declarative unit files are also a step in the right direction IMHO, since you can't break them, and with it the whole boot process. BUT, this thread was not about systemd. This was about splitting /etc/rc.conf in Arch, and unifying at least part of the system config with other distros. Debian, Fedora and OpenSuse will use the same files now - and I think it's great that we see some consolidation. It doesn't make much sense to have 100 schemes for configuring these basic stuff. Also, by splitting it in different files you make it more robust. You don't want to bork your network setup just because you were editing your locale and forgot to close a quote. -- дамјан

On 22 July 2012 13:41, Damjan <gdamjan@gmail.com> wrote:

Also, by splitting it in different files you make it more robust. You don't want to bork your network setup just because you were editing your locale and forgot to close a quote.

@Damjan: this isn't completely true because if the config file parser is well coded it just can ignore the faulty locale line while correctly parsing everything else, that's what I do when I need to parse a file: if a line has a typo or a value is out of range or plain wrong I make the parser show a warning message and keep parsing the config file :) My 2 cents regarding rc.conf (as a 2-years Arch fan): Seems I've been out of sync lately because I was totally unaware about this grand change. First of all I want to say I'm admitedly in love with Arch (as strange as it sounds, being in love with software): for a lazy guy like me Arch is both easy and simple, in fact easier and simpler than any other GNU/Linux distro out there (may be with the only exception of Slackware). It has a clean file layout, the packaging system is one of the best out there -if not the best- and it's easy to see The Arch Way is implemented system wide. One of the great things I specially love about Arch is /etc/rc.conf and it's whole sysconfig scheme: it's plain *awesome* to have init configuration centralized in one slim file instead scattered through god-may-know where; /etc/rc.conf is almost *perfect* specially if I compare it with SysV Init cumbersome scheme, with plenty of directories and S and K files, come on, that really sucks. But as things change and as systemd is becoming a de-facto on GNU/Linux distros, and there's nothing that can be done to keep the awesome rc.conf from being splitted, I vote for EMBRACE THE CHANGE AS SOON AS WE CAN. If rc.conf has it's days counted, then don't delay what must be done: Arch is bleeding edge so let's honour it. While I don't like the idea of losing rc.conf and I know I will miss the 'good old days' I don't want to delay a change I know it's unavoidable :'( Since I first met Arch Linux and since I first read The Arch Way I instantly knew this was the distro I was looking for since so much time, it was already packed with nothing else than awesomeness. Because that I strongly believe devs and TUs and everyone else who contribute to the distro development knows what's the best way to keep up with the The Arch Way and to keep Arch Linux a simple, minimalist, clean, easy and lightweight GNU/Linux distribution. Cheers =) -- -msx

...

to get rid of all that Poetterix

Once again this is not a technical argument, but a very subjective reason with - at least for me - no basis. Its more of a philosophy and that's not what this should be about.

If you *really* like an audio stack without PulseAudio (which I would consider quite useless on a modern desktop) and an init system based upon something as old, "stupid" and slow as SysVinit, then you are free to stick with it. Nobody forces you to use PA and/or systemd.

Tested, simply sophisticated and as fast as you make it. Once you get to desktop level and SSDs, who cares about a few seconds. The fastest booting systems (< 1 second) use init and won't use systemd. It would be good if you would practice what you preach especially when he has made hugely valid contributions that can't be fixed using systemd. Systemds functions can be replicated in the unix style of many tools doing a single job well. WRT pulse audio it won't run under a grsecurity kernel so first I'd say define modern desktop. How functional, how secure. -- ________________________________________________________ Why not do something good every day and install BOINC. ________________________________________________________

Hi,

Am 23.07.2012 17:29, schrieb Kevin Chadwick:

...

Tested, simply sophisticated and as fast as you make it.

There is no parallelization, no socket activation and no auto mounting. In no way can it be as fast as systemd.

init=/bin/sh That happens a lot in embedded.

...

Once you get to desktop level and SSDs, who cares about a few seconds.

It's not only about speed, but speed is a nice bonus. Its also about reliability. But I'm not going to enumerate the advantages of systemd over and over again. Just read the blog posts by Lennart ;).

That is completely debateable. I hope you look at counter arguments too. I like what systemd does in code in the main. I just think it needs a re-design to be more usable on the commandline and be more modular so pid1 is small if it cannot stay as init.

...

The fastest booting systems (< 1 second) use init and won't use systemd.

Which systems do you have in mind? Personally I can tell you out of experience that my system boots up faster with systemd.

Low memory embedded devices such as an mp3 player. I would also rather desktop and embedded systems shared pid1 as a simple init like upstart does.

...

WRT pulse audio it won't run under a grsecurity kernel so first I'd say define modern desktop. How functional, how secure.

On a "modern desktop" you probably have bigger concerns regarding security then running grsecurity. That said it should run fine with SElinux, which Fedora is using by default. Furthermore grsecurity seems to focus on servers anyway, so I'm not sure why you even bring this up?

Not really, it is used less on desktops because more code like Adobe Flash breaks without intervention. My Arch desktops run grsecurity kernels.

Best regards, Karol Babioch

-- ________________________________________________________ Why not do something good every day and install BOINC. ________________________________________________________

On Sun, Jul 22, 2012 at 02:52:49PM -0500, Leonid Isaev wrote:

I wonder why everyone thinks that Archlinux is about a single config file... It is the same myth as "Arch is faster than distro XYZ" or the "simple BSD init".

A single config file or a few of them won't matter. As long as you can stay in control without having to waste time bypassing or removing things that you don't need but that are pulled in as dependencies of something you do need. Simple example: I didn't have consolekit for some years, and I don't care about whatever it has to offer. Recent updates of xdm have pulled it in. So far it hasn't done anything evil except being useless and consuming system resources (50 or so threads). Same about polkit, it's pulled in only as a depency of gconf which in turn is only there because the Emacs package wants it. How much more of this useless stuff is going to be added without any way to opt out in the future ? I can perfectly understand that those things could be useful on a typical bloated consumer desktop. But they shouldn't be required unless you install such a thing. Systemd is similar, whatever it has to offer (e.g. on-demand running of services) I prefer to do without, just because that is simpler and without any doubt more secure.

Arch is about hackability and upstream compliance. AFAICT this is not going away. Besides, archlinux users should be experienced enough to manage 5 config files instead of 1. So if there is a single technical argument to use systemd syntax standard, it should overweigh 10 aesthetic predespositions.

So far I have not seen any really technical arguments, whatever has been presented as such is as questionable as any 'aesthetic' ones. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)

Hi, Am 22.07.2012 22:26, schrieb Fons Adriaensen:

Simple example: I didn't have consolekit for some years, and I don't care about whatever it has to offer. Recent updates of xdm have pulled it in. So far it hasn't done anything evil except being useless and consuming system resources (50 or so threads). Same about polkit, it's pulled in only as a depency of gconf which in turn is only there because the Emacs package wants it.

But this does not have anything to do with the recent proposal / change of the "rc.conf" and the split up coming along with this. So you shouldn't mix things up here. Am 22.07.2012 22:26, schrieb Fons Adriaensen:

How much more of this useless stuff is going to be added without any way to opt out in the future ? I can perfectly understand that those things could be useful on a typical bloated consumer desktop.

You are always free to change the PKGBUILD. The really easy packaging system Arch is providing is a real advantage over any other distribution I've seen so far. What do you expect the maintainer of these packages to do anyway? In order to provide useful packages for the majority of people they have to pull this things in, there is just no way around it. Of course you could complain directly upstream, but in general there are good reasons why they make use of things Polkit and ConsoleKit. Otherwise each and every program would have to implement the functionalities these packages provide for them self, which would be even worse. I think the key here is to accept these things as necessary and don't bother too much about them. Best regards, Karol Babioch

On Sun, 22 Jul 2012, Fons Adriaensen wrote:

...

What do you expect the maintainer of these packages to do anyway? In order to provide useful packages for the majority of people they have to pull this things in, there is just no way around it.

Yes there is. Take again the xdm example. Why do we have dynamic libs ? There is really nothing to stop the xdm developer to write his code such that it will use consolekit *if it is installed* and do without it otherwise. It doesn't have to be a dependency, that is just bad design. And anyway, if a login has to be declared as a consolekit session that could as well be done outside xdm. This sort of thing shoulnd't be hardcoded into binaries.

A little OT (hence changed subject), but I've sometimes wondered - shouldn't it be possible to create a "stub" version of libdbus, libconsolekit, et al that does nothing but the least necessary to get the calling program working correctly? With dynamic linking, such libraries would be installed in place of those bloated messes and result in a nicely-running system even for programs that have hard-coded dependencies on dbus and the rest? It's admittedly not the cleanest solution (better to remove those dependencies altogether), but I think it would be a pretty useful hack to "back-port" such software to cleaner systems. Is there a good technical reason why this is impossible or impractical? -- Scott Lawrence Linux jagadai 3.4.4-3-ARCH #1 SMP PREEMPT Tue Jul 3 14:36:44 UTC 2012 x86_64 GNU/Linux

On Sun, Jul 22, 2012 at 11:24 PM, Fons Adriaensen <fons@linuxaudio.org>wrote:

The dumbest thing I've come across was in Fedora 8 or so where some well hidden *binary* file, called from god knows where - I never found out - was used to create 'Desktop', 'Music', etc. directories in the user's home on each login.

That _hidden_ program is `xdg-user-dirs-update`, which is run automatically by many session managers. The weirdest thing is not that it creates those directories, but that if you ever log in using another language, it would rename them to their localized names... Fortunately I think that is no longer the default. -- Rodrigo.

Of course you could complain directly upstream, but in general there are good reasons why they make use of things Polkit and ConsoleKit. Otherwise each and every program would have to implement the functionalities these packages provide for them self, which would be even worse.

Or much better -- ________________________________________________________ Why not do something good every day and install BOINC. ________________________________________________________

On Mon, Jul 23, 2012 at 10:30:37AM +0200, Nicolas Sebrecht wrote:

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...

If you could point out the benefits it could have for me please do. Until some recent xdm update I didn't have ck, and everything worked exactly as I wanted it. That is still the case, so at best ck is useless for me, it just eats recources.

...and why you think it's only comsuming resources.

So what else is it doing ? Please tell me why you think I need it. Mount usb keys as a normal user ? I can arrange that without ck. Change ownership of some things to a 'local' login ? I don't want that to happen. Anything else ? -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)

...

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.

You should work for Redhat. -- ________________________________________________________ Why not do something good every day and install BOINC. ________________________________________________________

On Jul 24, 2012 12:10 AM, "Gaetan Bisson" <bisson@archlinux.org> wrote:

[2012-07-23 16:35:26 +0100] Kevin Chadwick:

...

You should work for Redhat.

Could you give us a break for a couple minutes and reflect on how many people you just spammed with your dozen content-free emails? Thanks for thinking for more than half a second next time you send something here.

-- Gaetan

Couldn't have said it better. I'm not by any means a technical expert, but even I could see how much "basis" his posts had (or didn't)

[2012-07-24 13:27:50 +0100] Kevin Chadwick:

you may not see my points if you haven't done any research on the foundations of UNIX and/or security.

How more ridiculous can you get? -- Gaetan

[2012-07-24 09:19:27 -0400] Baho Utot:

He is stating his opinion and that should be valued....

Baseless opinions are not valuable, they are spam.

His insight may keep one from doing something stupid simply because he has looked at the problem from a different light and that should be valued.

I am very sorry that you were lead to think that. -- Gaetan

Am Tue, 24 Jul 2012 16:07:50 +0200 schrieb Heiko Baums <lists@baums-on-web.de>:

Btw., in all those discussions about systemd as well as in all those discussions about PulseAudio, I always read more or less technical arguments from people who have objections against them or have tried them and have seen that they don't really work. From the people who like systemd and/or PulseAudio I only read arguments like "it's faster", "it's an evolution", "it's new", "everybody (distribution) uses it", "it has this and that feature", which actually only makes sense and works in a very few cases or can easily be achieved in other ways. But I haven't, yet, read any technical argument for them, why it is technically better, why it doesn't break the UNIX philosophy, why it is reliable enough etc.

Well, now I must correct myself. I just read Tom's explanation about some technical details of systemd. The first one so far, which clarifies it a bit. Heiko

My 1.2 pence: I would prefer that rc.conf is kept as one file, or at least do it well. W dniu wtorek, 24 lipca 2012 użytkownik Gaetan Bisson napisał:

[2012-07-24 16:07:50 +0200] Heiko Baums:

...

Yes, I don't like those Windoze like ini files of systemd, too.

Everything is and should stay a file, and every tool should do only one task but this should be done well.

How about having multiple files, each doing one thing and doing it well? Wait, isn't that exactly what systemd does?

...

This is, btw., also the KISS philosophy.

Any more platitudes coming? My /dev/null is feeling a bit empty.

-- Gaetan

-- --------------------------------------------------- *VOT Productions* *iRobosoft*: Owner irobosoft.weebly.com

Personally, I get exasperated when people don't take the time to educate themselves before making broad and incorrect assertions. There is a huge amount of documentation, discussion and other sources of information about systemd available online. Moreover, there is the source-code, and even the packages in Arch one can try out. There really is no excuse.

Well for me I do not have the time to go about learning the latest and greatest init system, desktop environment, whatever. I still use KDE3, I use old school init systems... why? because I use my system to do work not to tinker. I need it to "just work" and continue working in the same way it has. I don't want to become educated on the latest coolest thing, I just want something that will work and work well. I do not have time to pour through documentation of systemd just to figure out how to work it. When change is just for change I do not like it. Calvin

Op dinsdag 24 juli 2012 10:29:25 schreef Calvin Morrison:

...

Personally, I get exasperated when people don't take the time to educate themselves before making broad and incorrect assertions. There is a huge amount of documentation, discussion and other sources of information about systemd available online. Moreover, there is the source-code, and even the packages in Arch one can try out. There really is no excuse.

Well for me I do not have the time to go about learning the latest and greatest init system, desktop environment, whatever. I still use KDE3, I use old school init systems... why? because I use my system to do work not to tinker. I need it to "just work" and continue working in the same way it has. I don't want to become educated on the latest coolest thing, I just want something that will work and work well. I do not have time to pour through documentation of systemd just to figure out how to work it. When change is just for change I do not like it.

Calvin

my 2cents on your usecase: Arch Linux is always the newest and latest and ... so maybe your use-case does not fit this distributions profile if you really want everything to stay the same forever there are distributions out there which fit your needs exactly, but in my idea Arch is not it. --Ike

Op dinsdag 24 juli 2012 10:51:05 schreef Calvin Morrison:

On 24 July 2012 10:43, Ike Devolder <ike.devolder@gmail.com> wrote:

...

Op dinsdag 24 juli 2012 10:29:25 schreef Calvin Morrison:

...

...

Personally, I get exasperated when people don't take the time to educate themselves before making broad and incorrect assertions. There is a huge amount of documentation, discussion and other sources of information about systemd available online. Moreover, there is the source-code, and even the packages in Arch one can try out. There really is no excuse.

Well for me I do not have the time to go about learning the latest and greatest init system, desktop environment, whatever. I still use KDE3, I use old school init systems... why? because I use my system to do work not to tinker. I need it to "just work" and continue working in the same way it has. I don't want to become educated on the latest coolest thing, I just want something that will work and work well. I do not have time to pour through documentation of systemd just to figure out how to work it. When change is just for change I do not like it.

Calvin

my 2cents on your usecase: Arch Linux is always the newest and latest and ... so maybe your use-case does not fit this distributions profile

if you really want everything to stay the same forever there are distributions out there which fit your needs exactly, but in my idea Arch is not it.

--Ike

"To summarize: Arch Linux is a versatile, and simple distribution designed to fit the needs of the competent Linux® user. It is both powerful and easy to manage, making it an ideal distro for servers and workstations. Take it in any direction you like. If you share this vision of what a GNU/Linux distribution should be, then you are welcomed and encouraged to use it freely, get involved, and contribute to the community. Welcome to Arch!"

I have been using Arch since 2009. I like it a lot. It serves me very well :-)

Calvin

well then i'm very ok with it :) --Ike

On Tue, 24 Jul 2012 13:02:24 -0300 Martin Cigorraga <msx@archlinux.us> wrote:

"What exactly is wrong with ini files and/or registry? Perhaps it is your misunderstanding..."

Oh please, if you ever dealt with windows registry then you know it's a totally disfunctional way to keep record of anything.

Yes, I deal a lot with windows registry. In fact, I usually edit it directly to bypass standard program removal and service management.

Over time it gets oversized, filled with crap, slow and totally impractical, in one word: bloated, and please, while windows may implement one or two good ideas the underlying infraestructure is as much messy as is it's registry.

The problem is not with the registry itself, but bad programming. Most software devs under windows have very little understanding of the registry. -- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D

Am Tue, 24 Jul 2012 11:31:22 -0500 schrieb Leonid Isaev <lisaev@umail.iu.edu>:

The problem is not with the registry itself, but bad programming. Most software devs under windows have very little understanding of the registry.

Bad programming is the most favorite answer, and totally nonsense. The registry just gets bigger and bigger and is totally cryptic. And the registry is one of the most frequent reasons for system crashes and instabilities. And it's the most frequent reason why Windoze regularly (usually every 3 months) needs to be reinstalled. Heiko

Am Wed, 25 Jul 2012 07:22:28 +0200 schrieb Nelson Marambio <nelsonmarambio@gmx.de>:

that is / was right for Win 98 or Win ME. Having an exception error which was caused by damaged registry files always meant a reset to state short after the OS-installation, so all the drivers and programs had to be re-installed.

But my XP-Installation ran more than five years stable though being "stressed" by many test-installations of applications. Does not mean that XP or Win 7 is going to make an admin feel happy - but yes, there was an improvement, at least for the users.

But that was not such an improvement, maybe Windoze XP ran slightly longer than 3 months. But it's still not what I call stable. And it still is a PITA, particularly when it comes to administration. And it still gets unstable because of the (more and more growing) registry. Heiko

Am Wed, 25 Jul 2012 07:51:15 +0200 (CEST) schrieb okraits@arcor.de:

this is simply not true.

Sorry, but this is simply true. I know Windoze XP and I had to use it long enough, far too long.

First of all, starting with Windows XP the stability of Windows (yes, Windows, not Windoze) got much better and there are very few crashes which are mostly related to driver issues, IMO.

Much better? Slightly better! And, yes, Windoze.

Secondly, Windows doesn't need to be reinstalled every 3 months. Come on, most companies use Windows on their desktops and they don't need to reinstall them every 3 months. And their employees actually can work with their computers.

I used Windoze long enough. And I had to reinstall it every 3 months, and I know a lot of people who also had to do it this often. Since Windoze XP it was maybe not every 3 months anymore, but still often enough.

And i don't say this because i like Windows but because i'm realistic and not unfair. I don't live in a world where one system is perfect and the others are all completely crap. If you think that Windows is completely bad then you're not professional.

I am realistic and professional, because I speak from experience, like I said before more than 25 years. Windoze is completely bad. Otherwise I wouldn't get fits of raving madness every time I have to work with this crap, which is fortunately not too often anymore.

BTW: pacman.conf is written in an ini-style as well.

Not really. Heiko

On Wed, Jul 25, 2012 at 11:14:57AM +0200, Heiko Baums wrote:

I used Windoze long enough. And I had to reinstall it every 3 months, and I know a lot of people who also had to do it this often. Since Windoze XP it was maybe not every 3 months anymore, but still often enough.

I am realistic and professional, because I speak from experience, like I said before more than 25 years. Windoze is completely bad. Otherwise I wouldn't get fits of raving madness every time I have to work with this crap, which is fortunately not too often anymore.

I don't want to talk about Windows any longer because it is OT. I just wanted to correct some clearly wrong statements of you. Maybe you should reconsider your Windows administration skills if you need to reinstall every 3 months.

...

BTW: pacman.conf is written in an ini-style as well.

Not really.

Core syntax: [Sectionname] key=value Why is that not ini-style? Greetings, Oliver

...

...

I am realistic and professional, because I speak from experience, like I said before more than 25 years.

If the next employer you'll make an application should read this, you "was" an professional.

Is that a joke because I don't get it? I'd hire him, if I could afford him!

L. Poettering takes photos from himself in front of the mirror (google!) very often and publishes them by the Internet. I'm a pro-audio user. How many pro-audio cards are working with PA? L. Poettering, the boy with the same haircut as Bill Gates, blames the ALSA driver, but with jack and ALSA there are no issues. I don't like consolekit and systemd seems to improve this, anyway, ... Splitting /etc/rc.conf isn't bad per se and claiming that XP needs to be restored/reinstalled every quarter of a year is nonsense.

On Wed, Jul 25, 2012 at 2:07 PM, Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:

And what has all that to do with /etc/rc.conf splitting?

And some people wonder why Arch devs don't read arch-general... -- A: Because it obfuscates the reading. Q: Why is top posting so bad? For more information, please read: http://idallen.com/topposting.html ------------------------------------------- Denis A. Altoe Falqueto Linux user #524555 -------------------------------------------

On Wed, Jul 25, 2012 at 2:19 PM, Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:

On Wed, 2012-07-25 at 14:13 -0300, Denis A. Altoé Falqueto wrote:

...

On Wed, Jul 25, 2012 at 2:07 PM, Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:

...

And what has all that to do with /etc/rc.conf splitting?

And some people wonder why Arch devs don't read arch-general...

I only can apologize for my relatively less spam, not for the tons of spam others already added.

It's not meant to you directly. Your last sentence triggered the reply I've kept for some time just for myself. I could elaborate, but I'm not sure if the problematic people would really understand. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? For more information, please read: http://idallen.com/topposting.html ------------------------------------------- Denis A. Altoe Falqueto Linux user #524555 -------------------------------------------

On Wed, 25 Jul 2012 19:07:29 +0200 Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:

On Wed, 2012-07-25 at 18:54 +0200, Ralf Mardorf wrote:

...

L. Poettering takes photos from himself in front of the mirror (google!) very often and publishes them by the Internet. I'm a pro-audio user. How many pro-audio cards are working with PA? L. Poettering, the boy with the same haircut as Bill Gates, blames the ALSA driver, but with jack and ALSA there are no issues.

Is there any relation between these 4 sentences? Hint: noone cares about your random thoughts...

...

I don't like consolekit and systemd seems to improve this, anyway, ...

Splitting /etc/rc.conf isn't bad per se and claiming that XP needs to be restored/reinstalled every quarter of a year is nonsense.

Resume:

I don't like L. Poettering (I don't know him personally, so I might be completely wrong), I don't like pulseaudio (for good reasons), I don't have knowledge about systemd, but I'm willing to learn.

Are you in the habit of not liking people you don't know?

What has got Windows to do with that? And why needs a Windows admin to reinstall it ever 3 month? An admin should fix issues. Many users are able to install it every 3 month them selfs.

And what has all that to do with /etc/rc.conf splitting?

And what does consolekit have to do with rc.conf? -- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D

Guys, relax, we are all in the same wagon, it's a nonsense to make anything personal nor to demonstrate who has the bigger dick, fuck off all that shit. As some _DEVS_ had actually stated, let's discuss everything from a TECHNICAL point of view, arguing and ranting because personal dislikes of proposed new technology or procedures should not have a place here, there is a special section in our forums for that and even if you prefer ML you can create a new thread for your rants. Folks, we are suppose to be a community of geeks/nerds/hobbyst whatever else who happens to like IT, who happens to like and in many cases work with GNU/Linux and similar technologies AND -most important- who happens to fucking like Arch Linux because of every single other distro out there Arch is the only one that rocks our boat. So try to be constructive and if someone says something that upsets you please choose your words with care and re-read two or three times your emails before pushing Send because there's no way back afterwards. Let's act like adults (we're all grown ups here), not selfish idiots. Cheers, archers! -- -msx

On Wed, Jul 25, 2012 at 11:20:57AM +0200, Ralf Mardorf wrote:

Is there the need to talk about Windows? XP is stable, just most XP users are unexperienced, so they break their XPs, but for such computer users a Linux won't work, since it needs too much tweaking to get a Linux run, hence a borked XP anyway is better than a Linux that completely doesn't work. However, XP will be dropped soon. Or is it already dropped by Microsoft? Btw. 98SE already is stable. Newer Windows might be unstable, I dunno. For me it's important that Microsoft and Apple are unethical companies. Unfortunately XP doesn't run that good on VBox and I'm not willing to install it directly to my computer again. But we should keep in mind, that some software only is available for Microsoft and Apple. And how many users are willing to stand the roughness and all the rules of Linux communities? There are also such forums for Windows, but you also will find many forums where old women are allowed to ask the same stupid questions again and again and even top posting and HTML for emails are allowed. Registry indeed is a PITA, however, on Linux we've got pulseaudio, KDE4 GNOME3. Who cares? Comparing OS is useless. Splitting /etc/rc.conf has less to do with something Windows-like.

Hello Ralf, sorry, i just wanted to correct some statements which are simply not correct and just OS bashing. Greetings, Oliver

Hello Heiko,

this is simply not true.

First of all, starting with Windows XP the stability of Windows (yes, Windows, not Windoze) got much better and there are very few crashes which are mostly related to driver issues, IMO.

Incidentally, I installed a fresh XP a couple of weeks ago. The system had some sort of IDE cable problem that Linux tolerated. I finally got XP updated and ready to backup and after a reboot a message like. One of your registry files got corrupted and has been recovered with a backup. Nothing in task bar, start menu empty, various other problems. Why should one corrupted file damage so much but you also hope for a concise universal interface with the opposite seeming to come along more often. Try getting Gnome3 to not raise a window on click, it's easier but still problematic to get it to not raise a window on focus.

Secondly, Windows doesn't need to be reinstalled every 3 months. Come on, most companies use Windows on their desktops and they don't need to reinstall them every 3 months. And their employees actually can work with their computers.

You can't argue that it won't have slowed down all by itself. Some blame temp files, MFT, hidden malware your AV can't find but the registry can certainly take some blame, isn't a universal interface and has configuration strewn all over the place under hex codes needing deciphered that are as bad as some of the error messages. -- ________________________________________________________ Why not do something good every day and install BOINC. ________________________________________________________

Am Tue, 24 Jul 2012 16:25:52 +0200 schrieb Tom Gundersen <teg@jklm.no>:

Talking about "UNIX philosophy" and "Windoze like ini files" is probably what gets some people going. It is not technical.

In fact it is technical. Of course, at first glance config files for rc scripts and ini files are simple text files. But the structure, the way how they are handled (sourced or parsed), etc. is pretty different. And it's not only the ini thing. It's the whole possible move to making Linux a lot more Windoze like what I'm afraid of. The UNIX philosophy has worked for about 40 years and is totally tested and approved. Systemd is not. Of course, new things don't need to be bad and times are changing and sometimes there have to be made some adjustments, but it's a question how those new things are designed. And that's another point which I'm afraid of. I have tested PulseAudio and I know who has written and designed it. And I know that it totally doesn't work with a very few exceptions. And then I see that the same person starts writing something else at the same time, which intervenes even more into the system, even if the first software doesn't work correctly. So what do you think, how this looks like? Do you really think that this sounds trustworthy? Added to this I read that there are Windoze like ini files again in this second software of this person. Why do you think I have switched from Windoze to Linux? Of course, it was not the ini files in the first place. It was the whole terrible design and concept of Windoze incl. the registry. I still always get fits of raving madness if I have to work with Windoze, because I regularly need several hours for fixing something which I had fixed within minutes in Linux because of those simple and small config files and shell scripts (and because of the UNIX philosophy). And I know Windoze pretty well, too. Btw., I'm working with Computers since more than 25 years now and with Linux exclusively more than 10 years. And I started with an Apple IIc and a 8086 with PC-DOS 3.1, worked with several Windoze versions and I know Linux since 1993. So I guess I know what I'm talking about. 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. 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, 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. You have explained some of the advantages of systemd. And this sounds quite good, I admit. But I fear it's badly designed, at least everything around those advantages. And this all is technical.

Yeah, we might agree that UNIX is great and Windows is bad. But in a technical argument, it is just annoying to point to "tradition" and "philosophy" rather than technical facts, regardless of what side of the argument you are on.

It's not really annoying. Well, yes, if there was no substance behind it and if the tradition wasn't approved this well as it is in Linux and UNIX. See above. The problem in such long discussions is, that it's sometimes not possible or that people just don't have the time or the nerves to explain all the arguments in detail. 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. Either this software or change hasn't been explained good enough to the people (and just saying RTFM is not enough in such cases) or the software is indeed not well enough designed, which should probably be fixed. And, btw., 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). I was definitely not the only one who complained about it. And this must have a reason. And you can't tell me, that all those people have too little knowledge.

If you claim that systemd does not follow the UNIX philosophy (I disagree, but whatever), and if you claim that anything not following the UNIX philosophy is bad (I disagree, but whatever), then you should be able to combine these two claims and point to a technical flaw or shortcomming in systemd without any reference to UNIX, or Windows, or KISS at all.

See above. I think, I don't need to search for links which explain the UNIX philosophy.

Personally, I get exasperated when people don't take the time to educate themselves before making broad and incorrect assertions. There is a huge amount of documentation, discussion and other sources of information about systemd available online. Moreover, there is the source-code, and even the packages in Arch one can try out. There really is no excuse.

Seriously, who reads source codes? Manpages usually only explain the parameters, not the design of the software and how it works. There may be some other documentations, I haven't yet seen any.

I try not to be offensive, but sometimes my exasperation shows through I guess.

Now I know that you can explain things. So why not do it if you find that someone doesn't know enough about what's talked about? Nobody expects that you write a second documentation, but explaining some details can sometimes help. Heiko

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

Am Wed, 25 Jul 2012 10:44:34 +0200 schrieb Nicolas Sebrecht <nsebrecht@piing.fr>:

I can find anything in systemd which could make think of the registry on Windows.

I didn't say that.

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.

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. 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. If people want a second Windoze they should stay with Windoze or help to improve ReactOS.

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.

Writing such a "whole" script is usually very easy and pretty little error-prone. A configuration file can also be pretty inconvenient. I haven't yet tested systemd, but from what I saw so far it doesn't look too intuitive or easy. But maybe I'm wrong in this case. 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.

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).

You really don't need to read in a shell script to find where and how a config file is used. With SysVinit you have a rc script in /etc/rc.d and the corresponding config file in /etc/conf.d, both have the same name and the config files are usually very well documented, either by comments or by a man page. And what's hard in reading a very short init script with only a few lines? Btw., most lines are always the same (function declarations, case structures, etc.). The only important part is usually only one line.

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. 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, 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. If this software would be that well-founded, nobody had a problem with it, nobody would fear anything, and there would only be a very short discussion. Someone asks or mentions his concerns, somebody else clarifies it, and everything is good. This is not the case with Poetterix. And like I said before, I never - never ever - saw such a long discussion and so many concerns about a software like I saw for PulseAudio and systemd. So something must go pretty wrong in this case. This software can't be so well-founded. The people who are discussing about it, who have concerns against it and/or don't like systemd are not all stupid.

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.

Which init systems? I only know SysVinit. And why wasn't there a change for years? Actually there was never a change. Because this init system is so bad? I would rather say because it's so well tested and approved, and because it's simple and just works and does what it is supposed to do. Maybe there are things that can be improved. Maybe there is code which has to be written or executed more than once with SysVinit. Well, this could be changed and improved. If this justifies a complete new init system is questionable I think. Heiko

Why you would want to specify which services had to come before or after which other services is obvious when you consider that systemd boots services in parallel. There is no way in the current system, and no way without specifying, to boot several daemons at the same time and then boot other daemons afterwards

Maybe you could be clearer because scripting is almost boundless. Performance sensitive apps may require perl, C, assembly or hardware driven systems of course. The issue to me begins with whatever requires systemd be so large to start with and not be started by a script or init to begin with. There are plenty of languages with concurrency. personally I will obviously keep tabs on how systemd evolves but currently it's not a glove that fits for us all, thankfully that's not required to run arch easily yet.

that depend on them having completely launched.

In the interests of learning for my scripts and hopefully without leading the witnesses who may badger Tom? I'm interested to know how systemd knows universally that a service is "completely launched" ignoring that daemons themselves don't always know? I'm surprised people are still coming out with it is obviously far superior in every way. Change it to many ways atleast, please. -- ________________________________________________________ Why not do something good every day and install BOINC. ________________________________________________________

...

Maybe you could be clearer because scripting is almost boundless.

There is no way to specify in DAEMONS that syslog-ng and dbus should be started in parallel, and only when they are both up and running should network manager be started.

Personally I don't care about shaving a second or two but the simplest config change could be. DAEMONS="syslog-ng(3), dbus(3), network-manager(4)"

...

...

that depend on them having completely launched.

In the interests of learning for my scripts and hopefully without leading the witnesses who may badger Tom? I'm interested to know how systemd knows universally that a service is "completely launched" ignoring that daemons themselves don't always know?

A well written sysv daemon should only double fork once it is 'ready'. initscripts relies on this behaviour already (that is how we know when to start the 'next' daemon from the DAEMONS array). Systemd can either use this mechanism (Type= forking) or one of several other ones. That said, there its no magic: if the daemon does not know, then systemd does not know.

Thanks -- ________________________________________________________ Why not do something good every day and install BOINC. ________________________________________________________

...

Odd, Arch uses SysV's init, but it certainly doesn't have a SysVinit init system. It's much closer to BSD, and a lot of the tools we use are custom.

I know, and it's not necessarily bad.

I find OpenBSDs to be brilliantly straight forward. Part of that might be because there are no symlinks because there is just single or normal mode which makes more sense to me, (especially on arch) rather than many runlevels on a pre configured desktop system like redhat. Perhaps a conundrum for the goal of a universal initialisation interface.

...

Others include OpenRC (used by Gentoo), Upstart (used by Ubuntu) and of course systemd (used by Fedora)

I must admit that I didn't use OpenRC and Upstart, yet. I switch to Arch right before OpenRC was introduced in Gentoo.

I tried Alpine before arch and I believe that uses OpenRC as it is based on gentoo. I'd currently have less concerns running that than systemd but it was a little more fiddly than Arches interface and to add custom scripts too. -- ________________________________________________________ Why not do something good every day and install BOINC. ________________________________________________________

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

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. On OpenBSD you have in rc.conf.local sshd=YES or sshd="-f /etc/sshdconfishere" or in rc.local sshd && echo "sshd started successfully" This also demonstrates how easy shell can be to users and is a very good encouragement to get users hacking or more importantly in complete control. And now package provided ones in rc.d which I have never actually needed to use on servers or desktops. In fact I love that my systems aren't sending packets I haven't told them to, except my Android and TVs and Cisco router which I sold after fixing that and would have been glad I did if I had ever put it online as exploits were found in the source of those packets.

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).

Because that is so much clearer than a -f flag rightly in control of the daemons developer and in plain logical sight in the daemons man page or config file.

...

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.

I found via Google that I had to to setup my ttys with autologin and logs etc.. I restate 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). -- ________________________________________________________ Why not do something good every day and install BOINC. ________________________________________________________

On 26 July 2012 11:05, Nicolas Sebrecht <nsebrecht@piing.fr> wrote:

Hackers know C. Admins don't hack and write scripts, too often poorly; whatever my statement will hurt readers or not.

I can't speak for other sysadmins but that myth about "excellence" scripting usually doesn't apply in the real life when you have to deal with mixed environments often poorly implemented, you're allways on a rush and sometimes you simply don't have the time to code pretty: most of the times you need something that just works. Ugly hacks are a fact in sysadmins life and it will not prevent me from sleep like a baby :) -- -msx

On Fri, Jul 27, 2012 at 3:08 AM, Jeremiah Dodds <jeremiah.dodds@gmail.com> wrote:

Martin Cigorraga <msx@archlinux.us> writes:

...

Ugly hacks are a fact in sysadmins life and it will not prevent me from sleep like a baby :)

In fact, at some point you realize that while there are a lot of beautiful and clean systems, a lot of our entire computing stack is ugly hacks on top of ugly hacks ;)

And we get used to our particular ugly hack and then complain like hell when someone wants to take that ugly hack away and replace it by an unknown (and possibly/probably ugly as well) hack.

On Tue, Jul 24, 2012 at 5:07 PM, Heiko Baums <lists@baums-on-web.de> wrote:

Yes, I don't like those Windoze like ini files of systemd, too.

I honestly don't know if this is serious. What is the difference between a "key=value" rc.conf and a "key=value" ini file of systemd? -- Mantas Mikulėnas

On Tue, Jul 24, 2012 at 4:59 PM, Christoph Vigano <mail@cvigano.de> wrote:

But, those are not Windows-like INI-Files. Those files are meant to be following some XDG Desktop File Descripton Standard Whose Name I Not Now (tm), making them easy parseable by existing libraries and programs that implement this standard.

It is based on the desktop-entry-spec: <http://standards.freedesktop.org/desktop-entry-spec/latest/>, which in turn is (as far as I know) based on Window's .ini format. -t

On Tue, Jul 24, 2012 at 4:51 PM, Mantas Mikulėnas <grawity@gmail.com> wrote:

On Tue, Jul 24, 2012 at 5:07 PM, Heiko Baums <lists@baums-on-web.de> wrote:

...

Yes, I don't like those Windoze like ini files of systemd, too.

I honestly don't know if this is serious. What is the difference between a "key=value" rc.conf and a "key=value" ini file of systemd?

+1 I'm not a dev, but the ini files seem pretty user friendly - I liked them back on Windows too. I think maybe we should use our user pages in the wiki to put our thoughts into coherent writing, add links to back up our opinions etc. This could bring some order to the discussion, help dispelling myths and get rid oversimplifications.

On 24/07/2012 11:08 AM, Leonid Isaev wrote:

On Tue, 24 Jul 2012 16:07:50 +0200 Heiko Baums <lists@baums-on-web.de> wrote:

...

Am Tue, 24 Jul 2012 23:40:51 +1000 schrieb Gaetan Bisson <bisson@archlinux.org>:

Yes, I don't like those Windoze like ini files of systemd, too. One thing I noticed is that the only people who usually bash Windows are those who don't develop or know very little about programming. What exactly is wrong with ini files and/or registry? Perhaps it is your misunderstanding... I assure you, lots of developers, even (or maybe especially) Windows developers bash windows. The key is not throwing the baby out with the bath water.

Ini style files are both easy to parse and easy to read - there's no reason not to copy the format. Certainly these systemd target files etc. are easier to read and manage than the initscripts were. It may take some getting use to not being able to see everything in DAEMONS, but the benefits to the maintainers and to me if I ever need to tweak something beyond what gets run in what order, more than offset that.

Over time various linux projects took a lot from windows: gconf/dconf (~registry), KDE4 indexing services (~superfetch/desktop indexing), systemd-journald (~windows event viewer). This is real, get used to it.

The registry is more debatable. (Having all your config in one place is nice, but when that one place is an inconsistent mess that can only be managed by a mediocre special purpose tool it loses it's benefits.) I think I would be very upset if they wanted to move rc.conf into a gconf like interface. As is though I find it hard to complain. I generally like Windows events except for some of the pointless make work of registering each message ahead of time in your message.dll (which .NET hacks around). That said I've never had any issue with /var/log/*.

Am Tue, 24 Jul 2012 10:08:26 -0500 schrieb Leonid Isaev <lisaev@umail.iu.edu>:

One thing I noticed is that the only people who usually bash Windows are those who don't develop or know very little about programming.

You really shouldn't do such assumptions. You couldn't have noticed it, you're just assuming.

What exactly is wrong with ini files and/or registry? Perhaps it is your misunderstanding...

And I assume that you never really administrated a Windoze PC. Then you would know that particularly the registry is a PITA.

Over time various linux projects took a lot from windows: gconf/dconf (~registry),

Gconf is also almost a PITA. At least it's a lot more inconvenient than simple text files.

KDE4 indexing services (~superfetch/desktop indexing),

This indexing is one thing which makes KDE4 so slow and unstable. KDE4 was the reason why I switched to Xfce. And, yes, I tried KDE4. But Gnome and KDE4 are just optional, systemd is meant as the new init system. That's a big difference. If this all was only about an optional piece of software I wouldn't say anything. I just wouldn't use it. Heiko

Am Mon, 23 Jul 2012 09:36:05 +0200 schrieb Nicolas Sebrecht <nsebrecht@piing.fr>:

Sounds like you (don't take this a personal critism, you're not alone) have poor administration practices.

First, I do have 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).

You are right when it comes to such long config files like for Apache or PHP. But we are talking about rc.conf. That is not a long configuration file. And I really don't see how there are chances to make mistakes. Btw., chances that those merging tools make mistakes are much bigger with such big config files like e.g. php.ini. And it takes a lot more time to check if they did their job correctly.

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. How many times do you get a .pacnew file? And how big are those files usually? 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. Btw., in several cases a simple "mv something.conf.pacnew something.conf is sufficient. But this all (I mean the whole discussion here) is complaining on a high level, a very high level. And Tom already said several times, that he will support both the single rc.conf and the separate config files. So I really don't understand this discussion. I just hope that those single files are not created by default or will be integrated into systemd, so that they are only installed if systemd is installed.

If merging tools are not good enough, then let's improve them. But please all, don't make a shoot on current changes.

Then improve the merging tools. I haven't complained about them, and I don't use them. You brought them in.

What Tom is doing is exactly what most of ArchLinux users expect.

That's why there is such a long discussion and why most people write that they are worried about it. I would rather say, it's what you expect. I have experience with both and principally don't have a problem with both ways. I just say that I prefer one single /etc/rc.conf, because it's clearer and easier to maintain.

And the philosophy, KISS principle or whatever theory that you think is good in Archlinux is not beeing broken at all.

One single /etc/rc.conf is a bit more KISS. But like I said that's complaining on a very high level. Heiko

No, no. Even without merging tool, 3 or 5 files instead of one is not time consuming.

Ignoring systemctl output which is still less clear and slowed me down. 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.

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.

Have you ever had this problem in rc.conf? -- ________________________________________________________ Why not do something good every day and install BOINC. ________________________________________________________

As far as I can tell from the systemd blog and people's reactions here, the only advantages systemd offers are: - Splitting the configuration files, which increases the robustness of the configuration files - Daemon supervision - Bootup speedup by parallelizing the daemons. However, from the responses of some people, like Jorge Almeida, I see that the benefits of systemd are also given by other programs. - It has been suggested in a different thread to implement support for rc.conf to source other files - which would allow rc.conf to split cleanly - As Jorge Almeida suggested, daemontools [1], perp [2] and s6 [3] can supply daemon supervision *without* changing the init scheme - A patch [4] has been posted, and possibly added, to NetBSD's rcorder, which allows daemons to be started concurrently. As far as init systems go, it seems to me that while Arch touts using a BSD-style init, it's actually hacking around sysvinit to provide a BSD-like interface. This seems wrong to me, as BSD already provides a robust init framework. Why simulate that which you can use? In addition, people have cried out against several problems with systemd, which include: - ini-style configuration vs. shell-style configuration - Large, monolithic binary It seems to me that in addition to adding support for systemd could ease compatibility with other distro's, it would be beneficial to add sourcing to rc.conf (or alternatively to symlink the new systemd configuration files to files in rc.d). However, the only reason to do so is because systemd is widely used - i.e. I do not suggest doing this for every init system around. In addition, it may be considered to move from systemv to NetBSD's init, which stays in-line with the simple interface of rc.conf but adds parallelization and modularity. Lastly, it may be beneficial to suggest to users to install one of the daemon monitors. In sum, systemd offers some benefits that are covered by other programs and patches, while drawing much controversy and exacting a toll which seems a bit too large in the eyes of some users. For this reason, while we should add compatibility for systemd, we shouldn't force it down the users throats. Just my two cents. M [1] - http://cr.yp.to/daemontools.html [2] - http://b0llix.net/perp/ [3] - http://www.skarnet.org/software/s6/ [4] - http://forums.freebsd.org/showthread.php?t=25822 (Concurrent execution of rc-scripts with rcorder(8) )

On Sat, Jul 28, 2012 at 4:20 PM, Menachem Moystoviz <moystovi@g.jct.ac.il>wrote:

As far as I can tell from the systemd blog and people's reactions here, the only advantages systemd offers are: - Splitting the configuration files, which increases the robustness of the configuration files - Daemon supervision - Bootup speedup by parallelizing the daemons. However, from the responses of some people, like Jorge Almeida, I see that the benefits of systemd are also given by other programs. - It has been suggested in a different thread to implement support for rc.conf to source other files - which would allow rc.conf to split cleanly - As Jorge Almeida suggested, daemontools [1], perp [2] and s6 [3] can supply daemon supervision *without* changing the init scheme - A patch [4] has been posted, and possibly added, to NetBSD's rcorder, which allows daemons to be started concurrently.

As far as init systems go, it seems to me that while Arch touts using a BSD-style init, it's actually hacking around sysvinit to provide a BSD-like interface. This seems wrong to me, as BSD already provides a robust init framework. Why simulate that which you can use?

In addition, people have cried out against several problems with systemd, which include: - ini-style configuration vs. shell-style configuration - Large, monolithic binary

It seems to me that in addition to adding support for systemd could ease compatibility with other distro's, it would be beneficial to add sourcing to rc.conf (or alternatively to symlink the new systemd configuration files to files in rc.d). However, the only reason to do so is because systemd is widely used - i.e. I do not suggest doing this for every init system around.

In addition, it may be considered to move from systemv to NetBSD's init, which stays in-line with the simple interface of rc.conf but adds parallelization and modularity.

Lastly, it may be beneficial to suggest to users to install one of the

daemon monitors.

In sum, systemd offers some benefits that are covered by other programs and patches, while drawing much controversy and exacting a toll which seems a bit too large in the eyes of some users. For this reason, while we should add compatibility for systemd, we shouldn't force it down the users throats.

Just my two cents.

M

[1] - http://cr.yp.to/daemontools.html [2] - http://b0llix.net/perp/ [3] - http://www.skarnet.org/software/s6/ [4] - http://forums.freebsd.org/showthread.php?t=25822 (Concurrent execution of rc-scripts with rcorder(8) )

here here

On Sun, Jul 29, 2012 at 12:20:10AM +0300, Menachem Moystoviz wrote:

In addition, it may be considered to move from systemv to NetBSD's init, which stays in-line with the simple interface of rc.conf but adds parallelization and modularity.

That'd win so hard.

Lastly, it may be beneficial to suggest to users to install one of the daemon monitors.

Daemontools has been working sufficiently well for my purposes. It's lean, robust, and I'm a fan of the exec chain.

For this reason, while we should add compatibility for systemd, we shouldn't force it down the users throats.

How do you add support in this way?

...

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.

specifically relevent

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.

Offended for no reason

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).

Irrelevent here. It's poor administration practice not to check your seds, eds, files to install or sudoedits anyway. -- ________________________________________________________ Why not do something good every day and install BOINC. ________________________________________________________

...

Fair enough, but for this sort of thing, who is 'upstream' ?

In this case the super-ingenious Lennart Poettering, I guess.

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.

Hear, hear -- ________________________________________________________ Why not do something good every day and install BOINC. ________________________________________________________

I have used Arch for more than a year, and I can say that it still does more to keep things simple yet powerful for as many users as possible than any other distro I have tried. Ubuntu is still one of the best for n00bs, but I personally can't stand Unity, and package creation and maintenance can be a real pain. Fedora, don't even get me started; I left it years ago and refuse to go back unless I'm dragged kicking and screaming with the choice of either Fedora or Windows. Gentoo, now there's an interesting option, but it still seems to be for geekier geeks than me. *BSD, well, it looks good from what I've read, but there's no version as of yet that will just come up talking so I can get it installed without eyes. The Talking Archinstaller is definitely the most simple and minimalist way of making this happen quickly and painlessly.. Regarding recent changes, it is extremely important to be as simple as possible, but to also work as closely with upstream as possible. In spite of all the recent changes, Arch has done this with less pain and frustration than I expected. The change to multiple config files from a single /etc/rc.conf is not a major stressor for me, me, because geeks like me have been dealing with this in other distros for years, and it seems to be one step closer to upstream, which IMO can only be a good thing. So call me an Arch fanbou if you like, and keep your Fedoras and Ubuntus off my computer, except for the occasional virtual machine so that I can offer tech support. Give me Arch, and I will make it sing louder and burn brighter than all the others combined. To the devs, thanks for all the great work you do to make Arch the best available distro. ~Kyle -- Kyle is a droid. The whole world knows it. This e-mail shows it.

For having used systemd myself, I am inclined to believe that it definitely fits the KISS principle. Systemctl is only a frontend to simplify the addition and removal of services. Simplicity is only a matter of learning new commands (systemctl enable <daemon>.service, e.g.). What systemctl really does when you enable a service is that it creates symbolic links in /etc/systemd/system/<target>.wants.target/ that point to appropriate deamon launch helpers located in /usr/lib/systemd/system/. The proper target folder (graphical, multi-user, single-user) is obtained by reading the actual target file, but this can be overridden if you do the links manually. What I find really powerful of systemd is that it hooks onto the daemon itself and monitors exit codes and log files. Finding what's wrong with your sshd service is only a matter of typing "systemctl status sshd.service". You get current activity, its PID, the actual command it ran to start it, its status code if it ceased working, and the few last lines from the log file. To find out what runs at startup, you may use systemctl. I don't know the particular command, so I don't use it myself. I managed to figure out how to do it in a couple of seconds: you only have to "ls" the right directory. Graphical mode? "ls /etc/systemd/system/graphical.target.wants". Multi-user: "ls multi-user.target.wants". Could not be simpler. I have also found that my system boots much more rapidly with systemd. I can have a fully logged-in system running XFCE4, on older hardware (Intel Pentium 64-bit laptop) in less that 40 seconds. -- Sébastien Leblanc

On 22 July 2012 06:26, <kingfisher@almus.net> wrote:

...

[...] But developpers must know better than users what is the best for the distro. Killing /etc/rc.conf ? Why not. But for me, it is more KISS oriented than /etc/locale.conf, /etc/vconsole.conf, /etc/modprobe.d/*.conf files.

That's exactly my thoughts ...

Same here too. I hope it's false alarm though!

*BSD will be next, if rc.conf been deprecated.

If the rc.conf goes and if there is pacman incorporated to Slackware, I'll likely switch (back) to Slackware. Thanks to Gour, I've just learned about Frugalware which is sort of Slackware with pacman. Anyway, I cross my fingers tight for the great minds to keep rc.conf. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2012/7/22 Uli Armbruster <uli.armbruster@googlemail.com>: [...]

In the first moment when seeing those changes I had the same feeling. But after taking some time thinking about it, I changed my mind. Here's why:

So :)

- The rc.conf used to be the center of all config files. But this has been changing for quite some time. For >example, preventing modules from being loaded could be done in the rc.conf's MODULES line by putting a ! in

I remember this time.

front. Before this, there was an extra line for modules which should not be loaded. This functionality was >removed quite some time ago and nobody really complained. Of course it was much simpler back then, but >it's still doable today.

Using /etc/modprobe.d/ to manage modules is less simple than using a ! in front of a blacklisted module. And blacklisting modules is done once or twice a year.

- Many variables in the rc.conf are only touched once in the livetime of an installation. E.g. HOSTNAME, who >ever changes that? So you only have to deal with it once, so it's not a big loss, if this isn't configured in the >rc.conf anymore.

It won't hurt to let it in /etc/rc.conf either.

- _THE_ killer argument for Archlinux is and stays the AUR combined with pacman's capabilities. And >pacman improved a LOT over the last months, not just because of signed packages, also e.g. that -U can >resolve dependencies etc.

Well, since my first installation of arch back in end of 2008, pacman is far better :)

- Arch's own init system is still supported and right now I don't see any signs that this will change. So just >adjust your rc.conf or keep it (it still works), but nothing really changes for you.

It won't be the same for new users or if you change your hardware. I change my hardware fully every 3 years or so. And to be honest, I reinstall my arch every 18 to 24 months because it is kinda dirty.

Those are my $0.02

If it work, don't try to fix it :D -- Frederic Bezies fredbezies@gmail.com

On Sun, Jul 22, 2012 at 3:55 PM, Karol Babioch <karol@babioch.de> wrote:

Hi,

Am 22.07.2012 22:45, schrieb David C. Rankin:

...

I prefer a well commented rc.conf config file to virtually all of the other sysv and variations I've seen. A single file, well laid out and easily set up with reasonable defaults by Arch and simple to customize for the user. KISS in the best sense.

I don't think a single Arch specific file is as simple as some "standardized" files, where the filename already tells you what it is supposed to do. Both comments and defaults are allowed and appreciated, so this is not an argument at all.

Best regards, Karol Babioch

In regrards to splitting the file i believe it comes down to who do we want arch to be KISS for If we want it kiss for the TU we should split the file, after all thats one less arch specific patch If we want it kiss for the End User we should leave the file as is

I'm not sure if it would be feasible or kiss but i suppose one could try and make it so the file is dynamic based off the individual files... actually on reading that its a horrible idea

I don't think a single Arch specific file is as simple as some "standardized" files, where the filename already tells you what it is supposed to do. Both comments and defaults are allowed and appreciated, so this is not an argument at all.

It is not necessarily this difference but the fact that this bsdism guarantees plain sight whilst almost all other systems I have seen are far less clear and arch was refreshing in this regard in the linux world. OpenBSD has always had an rc.conf with default base provided package settings (almost everything =NO (off)) and an override rc.conf.local showing the name and non-default commandline arguments used, which I love. Fairly recently it has gotten a single rc.d folder for user installed packages which sometimes require longer scripts too. -- ________________________________________________________ Why not do something good every day and install BOINC. ________________________________________________________

On Mon, Jul 23, 2012 at 12:35 PM, 1126 <mailinglists@elfsechsundzwanzig.de>wrote:

For you this change might be a reason to switch to Fedora, you say. I mean, seriously? How is it all handled in Fedora then? Well, I don't now, actually.

Fedora is RedHat, and that's where systemd came to live, so you can guess...

- It's a rolling release distro: You only have to carefully do pacman -Syu to keep your system up-to-date. I started using Linux with Ubuntu and first I really looked forward to a new release, I mean new features, new artwork and all that stuff. But distupgrade nearly always failed and so I re-installed my system every six months. This is not good! With ArchLinux I can spent way more time just using my system instead of playing admin.

Well said. I came from Ubuntu also, and I expected that in Arch some things would break because of it being rolling and more bleeding-edge than Ubuntu. I accepted that, but as it happened, it breaks _less_ than Ubuntu. And, actually, about the rc.conf split, I couldn't care less. One file, three files, doesn't make a difference to me. As long as they are text files, and not binary ones, like some other mainstream systems, all is good. Just my 0.02 € -- Regards.

On 23/07/12 13:10, fredbezies wrote:

2012/7/23 Rodrigo Rivas <rodrigorivascosta@gmail.com>:

...

On Mon, Jul 23, 2012 at 12:35 PM, 1126 <mailinglists@elfsechsundzwanzig.de>wrote:

...

For you this change might be a reason to switch to Fedora, you say. I mean, seriously? How is it all handled in Fedora then? Well, I don't now, actually.

Fedora is RedHat, and that's where systemd came to live, so you can guess...

I wrote the first message before I successfully done a setup with a minimal rc.conf

...

...

- It's a rolling release distro: You only have to carefully do pacman ./> -Syu to keep your system up-to-date. I started using Linux with Ubuntu and first I really looked forward to a new release, I mean new features, new artwork and all that stuff. But distupgrade nearly always failed and so I re-installed my system every six months. This is not good! With ArchLinux I can spent way more time just using my system instead of playing admin.

Well said. I came from Ubuntu also, and I expected that in Arch some things would break because of it being rolling and more bleeding-edge than Ubuntu.

For the record, I'm using arch since end of 2008 / beginning of 2009.

It is the first time I was very upset by a change from developer team.

...

I accepted that, but as it happened, it breaks _less_ than Ubuntu.

And, actually, about the rc.conf split, I couldn't care less. One file, three files, doesn't make a difference to me. As long as they are text files, and not binary ones, like some other mainstream systems, all is good.

Not 3, but 6 more files. I do agree you don't have to modify them everyday, but it is - in a way - harder to set u than a single one. If it's documented it's hard?

Sure one file would be easier, but if the 3,4,5 or 6 files are documented there should be no real problems.

...

Just my 0.02 € -- Regards.

-- Jelle van der Waa