[arch-dev-public] [RFC, after the fact] initscripts config

As next best solution i chose posting my reply on the forum.While there are other threads about this change, i feel this topic should be discussed in the arch discussion board.

Tom Gundersen teg at jklm.no Sun Jul 22 10:59:19 EDT 2012> h) The major one: systemd is here to stay, more and more Arch devs and> users switch to systemd and we will increasingly struggle to get enough> testers and reviewers for initscripts. However, I really want to support> initscripts as long as I can. To make this doable for me, we need to> unify. We need to share code, configuration and behavior to make> initscripts sustainable even with very few testers. You might argue that> what we should do is to block systemd in order to support initscripts.> However, I think that would be a huge error as systemd is simply too> superior in every way, so preventing our users from using it is not> doing anyone any favors.

Tom, that is the kind of statement i've seen way to much and oppose strongly.

I won't comment on whether systemd is too superior, just state i havelooked at it's advantages over systemV init, and for my personal use they are very minor and by far not important enough to switch.

>systemd is here to stay, more and more Arch devs and users switch to>systemd and we will increasingly struggle to get enough testers and>reviewers for initscripts.

Re: [arch-dev-public] [RFC, after the fact] initscripts config

To add to what falconindy wrote. Everyone must have systemd-tools and pambase installed, so these numbers are clearly out-of-date. As to the 98% using initscripts, that is not strange as it is installed by default, and installing systemd does not remove it.

Lastly, what matters the most is not how many users we have, but how many developers we have using initscripts. They are the ones doing the early testing (and report most of the bugs).

Lastly: Arch is not user centric in the way you seem to imply. In this sense, I'd say we are the least user centric of all the distributions out there. We do not put hacks in place to make things "easier for the users".

Edit: Clarified some heat of the moment comment about being user-centric.

Whereas many GNU/Linux distributions attempt to be more user-friendly, Arch Linux has always been, and shall always remain user-centric.

Arch Linux targets and accommodates competent GNU/Linux users by giving them complete control and responsibility over the system.

Arch Linux users fully manage the system on their own. The system itself will offer little assistance, except for a simple set of maintenance tools that are designed to perfectly relay the user's commands to the system. Arch developers do not expend energy re-inventing GUI system tools; Arch is founded upon sensible design and excellent documentation.

This user-centric design necessarily implies a certain "do-it-yourself" approach to using the Arch distribution. Rather than pursuing assistance or requesting a new feature to be implemented by developers, Arch Linux users have a tendency to solve problems themselves and share the results with the community and development team – a "do first, then ask" philosophy. This is especially true for user-contributed packages found in the Arch User Repository – the official Arch Linux repository for community-maintained packages.

This list is for ArchLinux Development and is not open for public
comment. If there is an important issue, please reply directly to the
original author or to the general ArchLinux mailing list
(arch-general@archlinux.org).
Write access to this list may be provided in special circumstances,
and may need to be evaluated by the rest of the developers. Please
send an email to aaron@archlinux.org to request write access if you
feel you fit a "special circumstance".

Re: [arch-dev-public] [RFC, after the fact] initscripts config

Lone_Wolf, I share some of your reservations. I did just "jump ship" on one of my computers and tried out systemd. The transition was pretty smooth, and it works great, but I really don't see it a superior from my perspective. My perspective is, though, a user perspective. Perhaps systemd is/will be easier to maintain and upgrade which could lead to indirect benefits to users as systemd would get more 'fine tuning' and improvement over time. From my perspective systemd/initscripts are really 6 of one, half dozen of the other.

That said, I'm curious where you want this conversation to go. I hope/suspect tomegun's response on user-centrism was a miscommunication or misunderstanding and perhaps he took it as user friendly. However, this is really an irrelevant point. Jumping on that statement and quoting the Arch Way, does not seem to move this conversation in a useful direction.

What might move this discussion in a useful direction is a response to the last part of the mailing list entry

So if you are going to veto this, pleasealso outline an alternative long-term plan.

While the discussants here wouldn't have the 'veto power', if we can come up with an outline for an alternative long-term plan, one might hope it will be considered.

I propose that, if anything (and if this thread continues), we focus on such an alternative proposal. If we don't have an alternative, we cannot complain about the direction development goes.

Re: [arch-dev-public] [RFC, after the fact] initscripts config

If peoples use a distro is for a reasonif these reason disapared or Devs change them users change of distroif all or many users change of distro the proyect run out of usersif run out of user noone use it and dead

in other words for me: or heard users opinion or become a ubuntu-2 (decicions no democratics you know) or dead in silence

Re: [arch-dev-public] [RFC, after the fact] initscripts config

Sure. Even some devs might want to take a break from Arch. Maybe some other people will fill in for them, maybe not.

Users' opinions don't matter that much, as the devs are doing what they think is right. I haven't heard of a case of an Arch dev being forced out by the users, but users are free to come and go as they please.

Re: [arch-dev-public] [RFC, after the fact] initscripts config

I haven't heard of a case of an Arch dev being forced out by the users

It would be entertaining. Let the users 'fire' the devs. Are they then going to 'hire' someone else? I'd love to see the advertisement for that job:

developers wanted to maintain and improve the best linux distro. Must work on our terms, at our time, and follow our instructions. No pay and no benefits. Expect to be verbally abused. Apply by email to WhatTheFoo@archlinux.org

Re: [arch-dev-public] [RFC, after the fact] initscripts config

Just to clarify... anyone can edit the wiki, so that article does not represent the true development process at all.

How Arch development works:1) An active Arch developer decided they want to do something2) They do it...3) If the decision is big enough, it is brought up on the arch-dev-public list first. If there is no major objection then agreement is assumed and it gets implemented.

The "no major objection" comes from other developers, not users... and if it is not backed up by a technical reason, it is ignored.

Re: [arch-dev-public] [RFC, after the fact] initscripts config

What's the problem with this change anyway? Instead of keeping the configuration redundant and depending on sync, the default places to store the config values are recommended. (This is more KISS like, isn't it?) The configuration can be shared with systemd. Other distributions and/or configuration tools are likely to use the same configuration files. Settings will have sane defaults that are safe to use in the most cases. Everything is well documented in the man pages. Sound not to much to a problem to me. For the rare case that you actually need to mess around with settings like locale, keymap, hostname, etc. on a running system it simply doesn't matter if you are going to edit rc.conf or vconsole.conf, locale.conf or whatever.At least this change is not worth starting to question the "usercentricness" of arch.

Re: [arch-dev-public] [RFC, after the fact] initscripts config

For some time now i have been concerned about the way archlinux was going, and the change in rc.conf / tom gundersens post to arch-dev-public i quoted in the OP was an attempt to voice those concerns.

This thread has clarified a few things.

It now is clear to me that arch-dev-public is read-only for non-devs, and there doesn't seem to be a good way for non-devs to express their concerns.Posting to arch-general seems to be the best archlinux has to offer for that, but even if devs notice it , they can ignore it.

rc.conf and it's central role as archlinux main configuration file was one of the things that made me switch to archlinux and kept me here.As soon as the change in rc.conf moves to core, arch no longer has such a central point.

I've always had a talent for pattern recognition and this often allows me to see developments before others do.This week i've spend time reading the 2012 threads on arch-dev-public, and i don't like the way archlinux is going.

I also feel the arch way and the philosophy it describes are a crucial part of archlinux.Alas, i now have the impression way less people then i thought feel that also.

Since i found archlinux, i've felt at home here. However, i feel more and more like i don't matter to the people that decide where archlinux goes.Even worse, allan's post strongly suggests that arch development only focuses on technical matters.

I fiercely disagree with that, but see no way to infuence it.

Archlinux is still the best distro i know, but feels a lot less unique then when i choose to switch to it.I fear that archlinux is leaving behind the things that made it unique and strong, and soon will just be another distro with little difference from other distros.This makes me sad.

Re: [arch-dev-public] [RFC, after the fact] initscripts config

Lone_Wolf wrote:

Since i found archlinux, i've felt at home here. However, i feel more and more like i don't matter to the people that decide where archlinux goes.Even worse, allan's post strongly suggests that arch development only focuses on technical matters.

I fiercely disagree with that, but see no way to infuence it.

Be a dev. Start by becoming a TU. Learn on the job (its not really that hard if you've got a brain and some spare time, I lack at least one of that so I'm not there).

Regarding user-centric, it SPECIFICALLY is differentiated from user-friendly. Users are given to power to decide.

That's why when pulseaudio was first introduced it was kept optional for as long as possible (and wonder had to jump through hoops to do that, as I understand it), until upstream (Gnome, in particular), flat out removed the optionality.

That's why now, when the devs are (generally) preferring systemd, INCLUDING the guy maintaining initscripts, he's trying as much as possible to maintain initscripts. Allowing users to keep their old rc.conf.

That's as user-centric as it gets, and in my opinion is further than the devs involved needed to go. The developers ARE more important than the users, because they do the work (I say this as a user, of course). Arch is not a company or product where 'the customer' is put first, its a community, and as a community, there's a certain meritocracy. Basically, if you're not contributing, don't expect your voice to be heard as effectively as if you were.

Finally, you reference not liking the way Arch is going (fair enough), but I have no idea why you feel the Arch Way has become less important to a lot of people.

Allan-Volunteer on the (topic being discussed) mailn lists. You never get the people who matters attention on the forums.jasonwryan-Installing Arch is a measure of your literacy. Maintaining Arch is a measure of your diligence. Contributing to Arch is a measure of your competence.Griemak-Bleeding edge, not bleeding flat. Edge denotes falls will occur from time to time. Bring your own parachute.

Re: [arch-dev-public] [RFC, after the fact] initscripts config

ngoonee wrote:

Regarding user-centric, it SPECIFICALLY is differentiated from user-friendly. Users are given to power to decide.

"User-friendliness" is a strange thing. On the one hand, a mouse-only interface that gives the user no power to do harm to their system, completely with shiny buttons and cutesy noises, is considered user-friendly. Yet, ultimately, that same system gives the user absolutely no power and no real control. To you and I, such a system would seem anemic and very user-unfriendly! Personally, I find Linux distros more user-friendly than Windows (as an example), but I understand what you're getting at.

Lone_Wolf wrote:

I fear that archlinux is leaving behind the things that made it unique and strong, and soon will just be another distro with little difference from other distros.This makes me sad.

A distro is more than just an aggregate of packages. It's equal parts community and culture on top of the software that makes it function. To illustrate, look at all the various forks of popular distros (Linux Mint, Sabayon, even Ubuntu). Superficially, they're all "just another distro" and some have very "little difference from other distros" (particularly their forks). Yet they each have distinctive communities, user cultures, and developer cultures. Although some might argue that this is the thing that fragments Linux into hundreds of disparate communities with sometimes opposing goals, I see it as a strength.

Adopting the same core component as many other distros isn't all doom and gloom, and neither does it hearken the end of Arch! The uniqueness you speak of is fundamentally part of the culture. One example: Look at us. Humans usually share the same fundamental hardware (arms, legs, general body shape), but people in different parts of the world are decidedly very different from each other.

Edit:

jasonwryan wrote:

This. It took me nearly 18 months after first reading the Arch Way to learn enough about Linux (via Slackware) to move to Arch. In retrospect, I was still at least 6 months ahead of myself...

That sounds oddly familiar, except replacing Arch with Gentoo.

I think the reason I could never go back to many other distros is because one you learn how a distro like Arch (or Gentoo) is put together, it's like tasting the ambrosia of the gods. My first year with Gentoo was awkward because I was quite ignorant and still thinking of the *BSD way of doing things. Switching from Gentoo to Arch was far easier (given the experience I accumulated) than switching from FreeBSD to Gentoo.

Re: [arch-dev-public] [RFC, after the fact] initscripts config

Ok, I think this is just unfair, this is a decision well made, if systemd is an upstream most-do (at least for the greater linux distributions) it means Linux in general is going that way, if you unify and standardize with the others then you can port from others and don't have to make changes in every package so it is more comfortable to the end user to keep track of one file than 5 files. I think this is a smart move, difficult for some, but not at all as hard as you see it. I at first was afraid to do it with the classic "what if I reboot and everything breaks" but no, there is nothing to be afraid, I think is better to keep network configuration files apart from daemons and locales, this is how things should be done, besides, if for some strange reason you delete or move rc.conf your system will not boot, if you make a mistake in other files just your network will go down or something else (depends which file you edited), so my main point is: it is a good idea, it is different, and there shouldn't be complains about it, it's just like the glibc thing, is a decision made by those who know, those who made Archlinux the amazing OS that is now, I have used on my life all sorts of distros, from Red Hat, Fedora, Suse, Ubuntu, Corelinux, Hispafuentes, Debian and Mandrake (Mandriva too) and I couldn't be more happy if it wasn't for Arch. Besides, there are other rolling release distros and other bleeding edge distros but non like Arch and I hope this gets you thinking if you really are affected by this change or is just that you don't want to learn more and want things to work always with the same software until is considered legacy. Just my 2 cents.

Re: [arch-dev-public] [RFC, after the fact] initscripts config

xangelux wrote:

Ok, I think this is just unfair, this is a decision well made, if systemd is an upstream most-do (at least for the greater linux distributions) it means Linux in general is going that way, if you unify and standardize with the others then you can port from others and don't have to make changes in every package so it is more comfortable to the end user to keep track of one file than 5 files. I think this is a smart move, difficult for some, but not at all as hard as you see it. I at first was afraid to do it with the classic "what if I reboot and everything breaks" but no, there is nothing to be afraid, I think is better to keep network configuration files apart from daemons and locales, this is how things should be done, besides, if for some strange reason you delete or move rc.conf your system will not boot, if you make a mistake in other files just your network will go down or something else (depends which file you edited), so my main point is: it is a good idea, it is different, and there shouldn't be complains about it, it's just like the glibc thing, is a decision made by those who know, those who made Archlinux the amazing OS that is now, I have used on my life all sorts of distros, from Red Hat, Fedora, Suse, Ubuntu, Corelinux, Hispafuentes, Debian and Mandrake (Mandriva too) and I couldn't be more happy if it wasn't for Arch. Besides, there are other rolling release distros and other bleeding edge distros but non like Arch and I hope this gets you thinking if you really are affected by this change or is just that you don't want to learn more and want things to work always with the same software until is considered legacy. Just my 2 cents.

Punctuation and proper paragraphing would help. Too many commas spoil the post, and all that.

Allan-Volunteer on the (topic being discussed) mailn lists. You never get the people who matters attention on the forums.jasonwryan-Installing Arch is a measure of your literacy. Maintaining Arch is a measure of your diligence. Contributing to Arch is a measure of your competence.Griemak-Bleeding edge, not bleeding flat. Edge denotes falls will occur from time to time. Bring your own parachute.

Re: [arch-dev-public] [RFC, after the fact] initscripts config

For some time now i have been concerned about the way archlinux was going, and the change in rc.conf / tom gundersens post to arch-dev-public i quoted in the OP was an attempt to voice those concerns.

This thread has clarified a few things.

It now is clear to me that arch-dev-public is read-only for non-devs, and there doesn't seem to be a good way for non-devs to express their concerns.Posting to arch-general seems to be the best archlinux has to offer for that, but even if devs notice it , they can ignore it.

rc.conf and it's central role as archlinux main configuration file was one of the things that made me switch to archlinux and kept me here.As soon as the change in rc.conf moves to core, arch no longer has such a central point.

I've always had a talent for pattern recognition and this often allows me to see developments before others do.This week i've spend time reading the 2012 threads on arch-dev-public, and i don't like the way archlinux is going.

I also feel the arch way and the philosophy it describes are a crucial part of archlinux.Alas, i now have the impression way less people then i thought feel that also.

Since i found archlinux, i've felt at home here. However, i feel more and more like i don't matter to the people that decide where archlinux goes.Even worse, allan's post strongly suggests that arch development only focuses on technical matters.

I fiercely disagree with that, but see no way to infuence it.

Archlinux is still the best distro i know, but feels a lot less unique then when i choose to switch to it.I fear that archlinux is leaving behind the things that made it unique and strong, and soon will just be another distro with little difference from other distros.This makes me sad.

I don't get why people love the system settings thrown haphazardly into a single config file so much, IMO it makes more sense with the new config files, cleaner and more organized.

Systemd is objectively superior to sysvinit/initscripts in various ways, and distros are beginning to adopt it. This really helps with upstream compatibility and is a good thing. I hope arch adopts systemd some day, but I don't see that happening anytime soon, as many users still like initscripts. The current situation where they both share common config files is a pretty good middleground and makes things easier for sure. Arch is a very upstream friendly distro and its one of the reasons I love it

You fail to realize all the other things that make arch great, if the reason you use arch is because purely because of the format of one config file.

People are really making a mountain out of a molehill regarding the config files changes, if anything having multiple smaller config files that are descriptively named is much more KISS than one monolithic config file with a bunch of unrelated settings.

Arch's biggest stregths have always been, IMO:

KISSInfinitely customizable and no bloat, you choose how much packages are installed on your systemRolling Release, always up to dateVanilla/Upstream packages and great upstream compatibility.

Re: [arch-dev-public] [RFC, after the fact] initscripts config

I don't get why people love the system settings thrown haphazardly into a single config file so much, IMO it makes more sense with the new config files, cleaner and more organized.

I'd imagine these same people would throw a fit with the *BSD tradition of /usr/local/etc/* for non-system configuration

bwat47 wrote:

Systemd is objectively superior to sysvinit/initscripts in various ways, and distros are beginning to adopt it. This really helps with upstream compatibility and is a good thing. I hope arch adopts systemd some day, but I don't see that happening anytime soon, as many users still like initscripts. The current situation where they both share common config files is a pretty good middleground and makes things easier for sure. Arch is a very upstream friendly distro and its one of the reasons I love it

[...snip...]

People are really making a mountain out of a molehill regarding the config files changes, if anything having multiple smaller config files that are descriptively named is much more KISS than one monolithic config file with a bunch of unrelated settings.

I have to agree. systemd has two additional advantages, IMO, based upon my own use of it now exceeding about one week and spread across two different systems (three soon once I update my file server):

1) *.service files are FAR simpler and easier to manage than an assortment of shell scripts tossed into /etc/rc.d. While the latter has a significant amount of power, oftentimes that power is overkill for starting/stopping a service. Most services can be condensed to about two functional lines in a *.service file, a description, and a runtime dependency.

2) tmpfiles have a lot of hidden power that I don't think many systemd newbies have come to appreciate (yet). First, yes, you can control directories, files, and ownership or permissions. But the most important and significant change to me is that you no longer need to stick a variety of extra commands into /etc/rc.local. Take for instance lircd and older remotes and IR devices: Simply write a tmpfile config, toss it into /etc/tmpfiles.d, and you don't need to worry about how rc.local executes. Instead, all temporal events can be stuffed into a single location. Got something you need to echo into procfs? tmpfile it is! (Yes, it's slightly more work to do than `echo value > path`, but I find that logically, the organization and structure of using tmpfiles makes more sense and is easier for long term maintenance.)

Finally, virtually any runnable script or binary can be converted into a systemd service with fairly trivial modifications. My understanding is that as long as the application correctly reports status/errors via STDOUT/STDERR, returns the correct codes, and responds appropriately to signals, there's really no need to worry about futzing around with daemonizing the application through forking. I found that converting Redis and Memcached both to *.service files was incredibly easy. In some ways, it's much like daemontools with the exception that it doesn't suffer the bizarre annoyances of maintaining several directories. The other interesting trait of systemd is its ability to start services on demand via dbus or sockets. I've yet to invest time into learning more about this, but looking at the services on my system that do start via this mechanism is a fine example of how much better systemd is than the DAEMONS array. Not having to worry too much about dependencies from an administrative point of view is a relief (the people writing *.service scripts are the ones who have to worry about that), but that didn't really motivate me to try systemd--it's definitely a "nice to have" akin to the faster boot times.

Thus, I believe the biggest advantage to systemd is that it retains the essence of a single-file-as-a-service borrowed from the rc scripts/sysinitv and integrates it with the concept of a supervisor service. It's the best of both worlds and as close to a compromise between two good ideas as one can get. Sure, there's other alternatives (runit, for instance, currently being discussed elsewhere in the forums), but in many respects I feel that systemd is superior.