Rate of change in Arch's structure.

Sorry for the vague title but I'm not entirely sure how to phrase this.

I'm a newish Arch user of about 1 year or so. I've seen noticeable changes in the underpinnings of Arch over that time.*rc.conf file being 'gutted'*Grub legacy deprecated*/lib becoming a symlinketc

Now, I have had no problems dealing with any of these changes (that the wiki and news posts couldn't sort out for me anyway) and I'm not complaining about Arch changing - it is a rolling release disto after all.

Now for my question..

Is this rate of change considered par for the course with Arch or have I just walked in on a period of higher than normal flux?I don't have any baseline for comparison is the reason I'm asking.

Re: Rate of change in Arch's structure.

Though if you use the past as a gauge for the future in this matter you may want to consult your friendly neighbourhood actuarial scientist. Who knows what may happen in the next year.

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: Rate of change in Arch's structure.

Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael FaradaySometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing----How to Ask Questions the Smart Way

Re: Rate of change in Arch's structure.

Also just to note:

rc.conf changes aren't a huge deal, rc.conf still respects the deprecated settings, so you can just move the the new config files whenever you feel like it (its really not hard anyway, takes like 2 minutes )

grub legacy being deprecated was a long time coming, and there's nothing stopping people from continuing to use the old grub if it works for them.

The only one that's caused major issues is the usrlib change, which is mostly because people don't follow instructions

Re: Rate of change in Arch's structure.

I too am a recent Arch convert, albiet more recently than the op. But I really don't see the changes as a big deal. Even with the deprecation of rc.conf's many features, Arch is still way simpler and more elegant than any other distro I have tried.

I have never actually used grub legacy. I was familiar with grub2 coming to arch, so opted to go with what I knew upon installation. It was super simple with the wiki's help.

For me, /usr/lib didn't go totally smoothly, as I had installed some modules myself that were necessary for my lappy. Though, again, fixing it was simply reading the great info provided in the news... I am still unsure why people continue to have such problems. It seems like if you follow instructions, using Arch should be fairly simple. (It makes me think of how people tell me that they are simply not good at math, and I think to myself, "So you are telling me you can't follow directions?")

Re: Rate of change in Arch's structure.

As pointed out, most of these are upstream decisions, and maintaining a minimalist, rolling-release distro is difficult once you try and freeze time. (complaints about GRUB are especially galling, since we all should have seen that one coming years ago. I get that we all liked it, but I new it was going out long before coming to Arch.).

Note that /lib as a symlink is just a temporary placeholder; the filesystem is presently in a grace period to allow package maintainers to update their PKGBUILDs. As for comparison with other distributions (if that's what you mean), these are all changes that are occurring elsewhere, but will probably be largely unnoticed by end-users. With many of those distroes (Ubuntu, Mint, Fedora, Mandriva, etc.) it's almost customary to back-up personal data and do a clean install every six months, without bothering with any under-the-hood stuff; the guts of the system are the devs' prerogative, not the users'. This is likely why such changes are more pronounced in the Arch community.

Re: Rate of change in Arch's structure.

I don't know if I would classify the netcfg thing as a significant structural change. I am fairly certain that rc.conf has not been the recommended way of configuring netcfg for a little while now. Also, it isn't something that potentially breaks the system if ignored.

Re: Rate of change in Arch's structure.

I guess one difference with most of these (probably not KMS but the others) is that if I trash KDE, I can still boot. (Frankly, if this weren't the case, I wouldn't use KDE as I'm not sure it requires me to do the trashing.) So if people don't read the instructions, check the wiki, whatever, I guess they are likely to be more distressed by the consequences in the case of glibc, say, than Pulseaudio. Then again, maybe not...

Re: Rate of change in Arch's structure.

bwat47 wrote:

Also just to note:

rc.conf changes aren't a huge deal, rc.conf still respects the deprecated settings, so you can just move the the new config files whenever you feel like it (its really not hard anyway, takes like 2 minutes )

Seeing that the recommendation is to not use rc.conf for most settings I'm wondering if that is the goal? I love the simple way settings are done via rc.conf and would hate to see it "gutted" as OP here put it.

Re: Rate of change in Arch's structure.

stryder wrote:

bwat47 wrote:

Also just to note:

rc.conf changes aren't a huge deal, rc.conf still respects the deprecated settings, so you can just move the the new config files whenever you feel like it (its really not hard anyway, takes like 2 minutes )

Seeing that the recommendation is to not use rc.conf for most settings I'm wondering if that is the goal? I love the simple way settings are done via rc.conf and would hate to see it "gutted" as OP here put it.

Honestly its more KISS to have config settings in their own specifically named config files, then to have a bunch of unrelated settings in one file. I dont understand why people love rc.conf so much. One config file is definitely not what brought me to arch.

Re: Rate of change in Arch's structure.

Because it's what set(s) Arch apart from other distro's. Take away pacman, it's BSD-esque ports twin ABS, and rc.conf, and there is pretty much nothing anymore that distinguishes Arch from whatever mainstream distro there is out there. Pacman is still a strong argument, as is ABS, but a lot of the userfriendliness of Arch is based solely on the fact you could just use one config file and be over and done with pretty much.

Whatever wave later adopters of Arch were/are riding, I'm pretty sure centralised configuration is one of the main reasons for a lot of the original userbase. But maybe they have moved on... Who knows. It surely pains me to see it all go to waste. Guess I'll be frequenting the "If not Arch, then what?" topic more often.

Re: Rate of change in Arch's structure.

If not having a single configuration file is going to drive you away from Arch... I'd be interested in finding out what your alternative distro that does have one is.

Arch still has rolling release vanilla packages and pacman, which I think are its main draw-cards.

Well I think a portion of people were initially drawn to Arch because they liked the way BSD does things and Arch was the closest thing they could get among the Linux distros.

At least, that was my motivation. I still thing BSD does certain things much better than Linux. There's enough that I like about Arch that I'm not going anywhere, though. If there's enough of a demand for a single rc.conf, people will implement a distro that does it. Otherwise they wont. I definitely don't care enough to do it. Sounds like a lot of work!

Re: Rate of change in Arch's structure.

If not having a single configuration file is going to drive you away from Arch... I'd be interested in finding out what your alternative distro that does have one is.

Arch still has rolling release vanilla packages and pacman, which I think are its main draw-cards.

No, it won't drive me away. That would be putting it too strongly. But it has been a major reason keeping me. Arch will go where it will go. I'm just thinking that keeping what has been unique to it about it surely makes sense.

Re: Rate of change in Arch's structure.

If not having a single configuration file is going to drive you away from Arch... I'd be interested in finding out what your alternative distro that does have one is.

Arch still has rolling release vanilla packages and pacman, which I think are its main draw-cards.

The rolling release is indeed a bit of a sting. That one I forgot. I guess it will be debian sid, or maybe aptosid. For the server, it will probably be some BSD (FreeBSD with ZFS looks like a promising candidate). Rolling release is indeed high on my list of priorities, especially on my laptop and desktop (and probably the HTPC too, since hardware acceleration with AMD's GPUs still needs some improving). I have people trying to sell me Slackware but no way I'm going back there, that's like a return to the stone age.

So no, so far I haven't found a Linux that has a similar config setup. But that's what I love about Arch most, besides good package management and rolling release. And those two last qualities can be found in other distros as well, so with the first one going, there is a lot less motivation to stay with Arch.

It is the prerogative of the developers to decide what's best for Arch; I don't know if it's a lack of manpower that's driving (some of) those decisions, or because the newer people onboard haven't been 'groomed' or grown up with Arch, so to speak, but it does feel like they lost touch with what made Arch stand out. I think a lot of those angry topics/rants about rc.conf being phased out (that's what it's increasingly looking like) have to be seen in that light. What usually makes people even angrier is that it is a protracted process (it has been going on for a few months now) and nobody besides some devs seemed to know what was really happening. I was wondering as well for months what was going on, until I read a post on the development ML a few weeks/days ago that shed some light on it. Lack of communication usually makes people think the worst; I think it's important that users get some clarity on what is going on. As long as the silence is kept (or the info is out there but not communicated actively) people will keep wondering what's happening. That should be a signal there's not enough communication around it. Not necessarily debate; but communication.