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
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.
]]>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:
KISS
Infinitely customizable and no bloat, you choose how much packages are installed on your system
Rolling Release, always up to date
Vanilla/Upstream packages and great upstream compatibility.
These changes don't effect any of these strengths.
]]>Punctuation and proper paragraphing would help. Too many commas spoil the post, and all that.
Thanks, I'll keep that in mind.
]]>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.
]]>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.
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:
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.
]]>I wonder how many people are drawn to Arch, just because they read The Arch Way without realizing that this is what they want to live, not what they are ready to live.
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...
]]>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.
]]>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 think it is fair to say that Arch Linux development has always focused on the technical and that the developers make the final decision. See http://www.archlinux.org/static/magazin … ontributed
]]>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.
To clarify : Do you see the Arch Way as the philosophy Archlinux, it's developers and users should aim to follow ?
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 something
2) 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.
]]>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
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.
]]>