With the recent “controversies” in Arch Linux – such as the move to /lib being a symlink, parts of the rc.conf file moving into separate files and the installation becoming command line based – I started thinking about what really defined Arch Linux in the early days and what make it what it is currently. To assess this, I read through all the news and interviews about Arch up until the 0.8 release. That covers about the first five years of the Arch Linux existence. Here is what I took from those articles, in no particular order:
Pacman
This is probably the most unique thing about Arch Linux and it is the reason I started using Arch in the first place. I may be ever so slightly biased here… but I still find this one of the best package managers around. This is not necessarily for the pacman manager itself, but the package building system is so incredibly simple. Let me be clear in pointing out that there are a lot of areas that I think could be substantially improved, but the major things I want implemented are gradually being crossed off my TODO list.
The Arch Build System (ABS)
Being able to readily customize packages is always touted as on of Arch’s best features in any review I see. I never use it… Well, not entirely true – I have 1 customized package out of the 626 currently on my system. I wonder if it is the packaging system rather than ABS that is being highlighted by not well informed reviewers there, because maintaining a custom package is really not a pleasant task in Arch.
Rolling release
Having packages available in our repos very quickly after the upstream release is a major attraction to Arch Linux. While Arch is far from the only rolling release distribution, the updates tend to be damn fast!
Optimized for i686
Ten years ago, most distributions were compiled for i486. So back then, compiling for i686 was a big feature. Now 64-bit has overtaken the world and and most 32-bit distribution offerings are built for i686, so this is not an advantage anymore. We should probably drop i686 and crank up the optimization of the x86_64 port!
Simple filesystem layout
I found this an interesting feature to be mentioned by Judd… Especially given all sorts of packages in Arch used to be shoved in /opt. But he was referring to the lack of things like /usr/doc. Years ago, Arch used to ship packages without documentation – including info pages. Now we do ship info pages (they are treated identically to man pages by the packaging system) and documentation is also shipped (in /usr/share/doc, not /usr/doc).
Simple configuration
The rc.conf file was highlighted by many reviews as being the one stop for all your configuration. In fact, one review suggested that it should also include “wi-fi profiles, printer, scanners, bluetooth etc” given there were not GUI tools to do this. The lack of distro specific tools for configuration was also highlighted, although that is a bit weird given our rc.conf is ditro specific.
Support
The help on the IRC channel, and to a lesser extent the forums, was often mentioned. Also the excellent documentation in the wiki was beginning to make its appearance.
Rapid adoption of new features
Having the latest an greatest software was often considered a highlight. For the initial five years of Arch Linux, that included things like the Ext3 and Reiser filesystems, udev support and Linux 2.6.
One thing I did not see mentioned anywhere was Arch’s use of vanilla packages. The minimal patching is one of my favorite features of Arch Linux, but I guess that is not something that would be readily seen by a reviewer.
So… lets take a look at the current controversies in Arch Linux land with respect to the foundations of Arch Linux.
Controversy #1 – Symlinking /lib to /usr/lib
People were not particularly happy about this. And they are really going to hate when /bin, /sbin and /usr/sbin all point to /usr/bin… Note there were quite a few other things that have become symlinks recently too (think about what points at the /run directory). The difficulties of the /lib change were exasperated by the rolling release model and limitations in pacman in performing the upgrade. But I think this fits in directly with the “simple filesystem layout” above. As discussed above, we have slowly moved away from this principle to provide packages closer to what their developers intended (by not removing documentation), so this is really a return to original Arch principles!
Controversy #2 – The demise of /etc/rc.conf
While the single rc.conf is highlighted as major feature of Arch Linux, reading the reviews makes you notice that configuration of an Arch install was never down to a single file. Other files mentioned included…
/etc/conf.d/wireless
/etc/fstab
/etc/group
/etc/grub.conf
/etc/hosts
/etc/inittab
/etc/lilo.conf
/etc/locale.gen
/etc/mkinitrd.conf
/etc/modules.conf
/etc/modprobe.conf
/etc/rc.local
/etc/resolv.conf
/etc/pacman.conf
/etc/X11/XF86config
~/.xinitrc
And that is just the configuration files mentioned in what were quite superficial reviews of Arch Linux. So a single configuration file was really just a myth.
But lets take a step back here… How about some quotes from Judd, the founder of Arch Linux:
“In Arch “simple” is different what other distros are considering. The learning is more important than getting something easily done.”
“Relying on GUIs to build/use your system is just going to hurt a user in the end. At some point in time a user will need to know all that some GUIs hide.”
What does a single configuration file get us? Is it “simple” in terms of the definition above? Not really… It requires that we write our own tools to deal with it and convert these into the appropriate commands during boot-up. For example, instead of configuring modules in /etc/rc.conf, we should directly use the configuration files that the module loading software reads. How is putting the settings in rc.conf and having software interpret them any different than using a GUI to do the same thing? It does not give us any actual understanding of the system. Also using the same configuration files as other distributions do (and this is becoming more standardized) means the learning done in Arch Linux will apply to many other distributions.
Controversy #3 – The move towards systemd
I think it is plainly obvious that systemd will become the primary system initialization method for Arch Linux in the not to distant future (not that this has been formally decided, so take that statement as unofficial…). Having not used systemd at all, I really can not comment directly on if it is any good or not. But what do we lose by moving to systemd in Arch? I have seen the following criticisms:
Users are being forced to use systemd. This argument really does not hold water. How many initialization systems are currently in use on Arch systems? Just the one currently “forced” on you…
The module control is more complex. Right… because “rc.d start foo” is much simplier than “systemctl start foo“. I think the real criticism people are trying to express is that the rc.d way of doing things is more traditional Arch. But have you looked at the quality of scripts in /etc/rc.d? It is generally poor. Moving to systemd unit files instead will be an advantage as they are much more simple to write and can be pushed to the upstream packages.
The initialization process will no longer be controlled by a bash script so it will be harder to skip a broken section. This is probably somewhat valid. I do not know enough about systemd to really comment beyond a couple of points. Firstly, systemd is (or will be) used by many distributions so will be less likely to break than our current initscripts. Also, systemd is quite modular, so it appears that stopping particular modules should be achievable.
It is written by Lennart Poettering. I have no idea how this ever became a “genuine” argument against systemd, but almost any discussion involving systemd ends up being about Lennart also writing pulseaudio. Maybe we need an updated version of Godwin’s Law for this situation… Any time an argument reaches this point, I know all things technical are out the door and I stop following.
When I was reading the old reviews, every time I saw mention of Arch Linux using the latest innovations in the Linux world, I started wondering why we are not using systemd already? Here I have only (partially) refuted the downsides of systemd, not pointed out what I can see are some quite substantial benefits. I personally think the historic rapid adoption of new features should continue in Arch Linux.
This has been a much longer post than I initially intended, but I hope this makes people think about what makes Arch Linux what it is. Or at least reconsider whether changes being made are really going against historical Arch principles. It has made me consider why I have not tried systemd yet, so I will do so in the next couple of weeks. Being on the bleeding edge is not much fun without the occasional cut…
Nice article, thanks for the information.
Package signing should be removed as soon as possible.
LMFAO are you serious?
For years, people have bitched about this not being available, and personally I like knowing that my packages haven’t been fucked with.
Is it to difficult for you to comment it out in the /etc/pacman.conf?
I think it’s simple to state that changing the fundamental locations of files of existing machines is an a-front to the concept of a rolling release system by most system administrators. Most administrators that use rolling release will do so because they believe there is little change required for the maintenance and administration of a box. Forcing them to go through the /lib -> /usr/lib thing f*cked up my box for more than a week before I could get to the data center to fix it, and that was me trying to follow the arch instruction to the T. It goes to show that taking a large and established system and trying to re-arrange the pillars that make it strong is generally a BAD IDEA.
On a second note, if your best argument for using systemd is that the scripts are easy please do not make the change. Why change crond? It just works! Not to mention that every service will require the maintainers to rewrite the init scripts for them. That’s a lot of man hours and headache just to change to systemd and for what gain exactly?
TL;DR; Why change a large stable system by rearranging the pillars that support it? It seems like a futile effort imho, if people want to make those choices then let them, but do not force me to on my systems that are running in datacenters for the 3+ years.
Generally Arch isn’t recommended for “stable” systems because rolling release takes more maintenance than periodic releases. I’m not sure where you heard otherwise.
As another data point, I hadn’t updated one of my arch installs for at least 6 months and it went past the /lib changeover in about 5 minutes after reading the news entry. Pebkac?
I’ve been rolling release with gentoo for the better part of a decade with gentoo, i switched to Arch because it’s just simpler to maintain for the long run. Arch I’ve not had any headaches or problems for until this /lib -> /usr/lib thing. I was too was able to make the upgrade on a couple of my machines with some headache required, however one system (which thankfully wasn’t terribly important) required a recovery CD to remedy.
PEBKAC? sure I’ll take that. Guess I should just go back to running old debian and redhat packages, good bye Arch guess you’re just not ready to be in a data center yet.
Arch is simpler to configure than othen distro l used (debian, gentoo, suse, fedora…).
The complexity of Arch is proportional with the complexity of the FOSS ecosystem, Arch never add any headache other than what is done by the application developers.
To stay close to the developers means to stay close to the innovation in the FOSS.
No, Arch is certainly not suitable for use in a data centre. Servers and other high-reliability systems are not really Arch’s strength, things will go at least a bit wrong at some point, and if any downtime is bad, that’s not acceptable.
Having said that, the recent /lib change should not have caused any problems at all if you really did follow (all of) the instructions perfectly.
“the recent /lib change should not have caused any problems at all if you really did follow (all of) the instructions perfectly”
That assumes that EVERYONE running AL is paying close attention to the latest bulletins/channels. Anyone, like me, that was out of the loop and just happened to do an update without paying attention has payed the price. Now am I at fault for not paying up to the minute attention to things Arch and going ahead and doing something I do every other few days for many years without nary a hitch… and then all of a sudden, this one time, on a server 10KM away, it’s dead. If it wasn’t for the fine tech folks on the other end that booted my server up on a live CD and let me have at it I would have lost even more $1000 dollars of downtime. There was a whole bunch of things I could have done to have avoided this situation versus just one thing the AL devs did which is to treat theirs users as their continuous integration system. Ubuntu caught me out when they suddenly changed from bash to dash quite a few years ago. Lesson learnt once again, Debian is the only system I seem to be able to rely on for remote servers.
I don’t know about “Arch being easier to configure and administer” than Gentoo. I’ve used Arch for like 1-1.5 years, and Gentoo I’ve used for about 2-3 months and I find Gentoo much more easy to administer and keep under control than Arch. The stable/unstable trees in Gentoo definitely help, but even if you are running a full ~amd64 system, it’s still completely easy to freeze packages in the tree and start to maintain a mix system which you can easily switch back to full ~amd64. You can also stop updating your ports tree and continue to install packages from your current ports tree until you want to do a full upgrade.
Generally. When you run “pacman -Syu” and some conflict shows up next thing to do is go to archlinux.org it’ll be in the latest announcement guarenteed. Just don’t be lazy and pass –force to the pacman parameters and you’ll save yourself a lot of trouble.
Really liked reading you post. Have been an Arch User for about 2 years now and adopted systemd 6 months ago which made me think about rc.conf, but your point is valid that it wasn’t the only config file anyway. But it was the only config file you had to change when you first installed arch. The default mkintcpio.conf and fstab never required any changes for my system. Only thing I had to do was uncomment my locale and that was about it. /etc/hosts was also set up automatically. pacman.conf was also good to go as it is for almost anyone unless you wanted [multilib] from the start.
I don’t recall Arch promising not to break away from old stuff. Arch follows sensible upstream changes.
Maybe you should pick some ultra-stable distro?
Brian, you were apparently not around during the devfs -> udev switch etc. It was much more fun, and people complained about it with almost the exact words that you use. That the arch devs were fools for changing from a device system that had been around for half a decade to some newfanged “udev”. And there have been quite a few other major updates that have tended to break systems for people who doesn’t think before they act too. (not aimed specificity at you, totally general statement) . Speaking of which, almost all the breakage from the /lib -> /usr/lib switch I have seen have been user errors.
“if your best argument for using systemd is that the scripts are easy please do not make the change”
I never provided arguments for using systemd, only refuted some criticisms I see repeatedly made.
Let me quickly point out that “Never change a running system” and “Rolling release” do not work together. You cannot stay rolling on the bleeding edge without breaking things every now and then.
I remember that one of the catch phrases of Arch was “A distribution for a competent Linux user”. For some reason, the “competent” was completely forgoten. A rolling release system will be more dificult to maintain and there’s no obligation by the developers to support your current system. You are the responsible to follow what is current in Arch and adapt to the changes.
Of course, I’ve already got bitten by my own mistakes, but I totally deserved 🙂 Even though i’m a software developer, I “administer” an Arch local server and update it rarely and I’m completely conscious that if it breaks, it’s my fault (unless it’s a packaging issue, but that is quite rare)
You are absolutely correct. And why was /lib removed anyway?? Yet one more reason to keep at least One Slackware partition on evry machine I own.
I am excited for the changes. I always found rc.conf to be too all-powerful.
I have never seen it as the only configuration file though; in fact, I really don’t get why people see it that way.
This year is the first year I’ll have free-time (I’m a CS student), I’m looking forward to having some of that go to participating in Arch’s development and maintenance.
So… yea! Arch rocks!
good write-up, personally I think the devs are doing an excellent job and I love the recent changes. Upstream compatibility has always been a strong point for arch, and I love to see upstream compatibility further improved.
I’m also a big fan of systemd, I find it much easier to deal with. Its nice that arch is working to increase systemd compatibility while still supporting sysvinit/initscripts.
I hope to be able to remove consolekit and go pure systemd sometime in the future!
Maybe I just haven’t given it a fair try, but the fact that I have to prefix the service with .service is a bit annoying.
systemctl kill crond.service
To me feels more awkward than
rc.d stop crond
Really though, like I said, I haven’t used it enough to give it a fair judgment. My initial impression though, is that there’s a lot of stuff when you run
systemctrl list-units
* I think that was the command.
*Shrugs* I guess I’ll wait and see.
I believe that the .service is no longer necessary in the next systemd release.
Changing over from /lib to usr/lib was not a big deal at all for me. I always read the news on archlinux.org website BEFORE I do an update which sometimes that manual intervention is needed. I just followed the instructions and that was it… no issues.. read the Arch Linux news BEFORE you update.
As for systemd, I am a big fan. I have been using it for 3 weeks now and enjoying faster boot times and shutdown times. Again, no issues.
When I was reading the old reviews, every time I saw mention of Arch Linux using the latest innovations in the Linux world, I started wondering why we are not using systemd already?
Indeed. In fact I was wondering why the switch to grub2 (as the default bootloader) took as long as it did. Well I suppose they were waiting for it to become stable, but still.
And it didn’t raise the same uproar, even though grub2 is, at least in my eyes, more messy than grub. Of course, grub2 has better support for lots of things, is modular, etc. But I still havan’t wrapped my mind around that configuration 🙂
Thanks Allan: a good post.
As someone pointed out on the boards, a little more information about the Arch roadmap would go a long way towards assisting people to adjust to the changes.
These sorts of posts help people not only understand the what but also the why; that way they don’t feel as much helpless trepidation everytime they -Syu, wondering what else they are going to have to deal with.
Good Point Jason!
A stable system need a patient admin, that not hurry to upgrade before to read news and alerts.
Great post! Very useful to read for a new archer together with the Arch Way wiki article to understand Arch Linux.
Every reason listed in this post is why I use arch on all my machines. I, for one, don’t have a problem with the updated configuration system. I think it is a good thing to have all these major changes in such a short time, its best to just get it all out as quick as possible. If arch is going to move to systemd, which is likely, then do it A.S.A.P. One of the goals of arch is to be cutting edge, so moving to systemd makes sense. It has gotten great reviews all around, therefore I agree that it is time for Arch to officially adopt systemd.
Great jobs guys, Archlinux is the best!
P.S. I also like the new install ISO, it feels like arch.
another point against systemd is that it is much, much slower than Arch’s own init scripts.
I just installed it to test it out, and it was upwards to 20 seconds just to boot, compared to arch’s init scripts who do it in less than 5 on the same hardware and with identical setup otherwise (and yes, I did look at the bootcharts, and nothing obvious stood out, except for a lot of systemd-* stuff that took forever to launch).
http://mts.ms/systemd-bootchart.png
Ahem, NetworkManager taking 6 seconds to start clearly stands out.
Something is wrong there. In my experience systemd cut boot time in half!
systemd is much faster here. Added MySQL and apache to my system too. Sometimes I think people don’t like change.
I doubt your system ordinarily boots in less than 5 seconds. That chart shows it spends more than 4 in kernel space.
Having not actually used systemd, I can not help you there. But no bug report means no bug…
This seems implausible. I’d suggest rebooting a couple more times (could it be that you had a fsck during this boot?).
Two comments:
NetworkManager, root-fsck and systemd-modules-load, take the most of the boot time. These are exactly the same on systemd and initscripts, so the difference should not be very big.
On a rotational disk, it might be that doing things in parallel slows boot down a bit. To compensate for this you might want to enable readahead, if you have not already done so (and reboot at least twice for it to take effect).
I like Arch. It simplifies a lot of things, allows me to accept the changes of the latest development from the upstream release. Changes are always there. Accept the changes, then we will evolve.
There are valid reasons to not like systemd that you didn’t touch upon.
1) Politics: The way that systemd is being pushed is rather unfriendly. The “our way or the highway” approach is disconcerting and unhelpful to a community effort. Especially when one of the main developers uses it as a platform to trash other distributions. Not to mention the absorption of a core project like udev with the intention of deprecating it for use with any other init system.
2) Philosophy: Systemd throws away a lot of unix tradition. Not only with getting rid of shell scripts for initialization, but with it’s lack of a modular structure. Sure udev is kind of separate for now, but that’s unlikely to be the case going forward. journald is inextricable from systemd as well.
3) Binary Logging Formats: Journald is not only inextricable from systemd, but it’s binary logging format is highly contentious. Not to mention poorly documented. The reasons for plain text logs are numerous. The reasons for a new binary logging format are currently few and desktop oriented to say the least.
4) Dependencies: Not every system needs dbus and having it as yet another inextricable part of systemd is troublesome.
5) Lennart: I don’t think it’s a fair argument to dislike something just because someone in particular wrote it, but Lennart certainly doesn’t do himself any favors by being smug and dismissive of other people’s concerns and opinions constantly.
I for one don’t like the idea of Arch moving to systemd and I think there really wasn’t enough discussion of the alternatives (e.g. OpenRC). I am undecided if I’ll stay with Arch or not if and when the move takes place, but I hope there is more discussion on the possibility of using something besides systemd which is objectionable for a number of valid reasons.
I hear OpenRC suggested as an alternative fairly often. But has anyone done much to getting OpenRC working in Arch? Systemd was purely maintained in the AUR for quite some time before its popularity picked up enough for it to move into the repos. If someone actually does the work and shows OpenRC is actually better then it will be considered.
Well, I use OpenRC with my Sabayon installation. Personally, I strongly prefer systemd.
Tim
1) I don’t get this at all. Try searching the systemd mailinglist for patches submitted by me to make systemd work better on Arch. Almost always they get the same speedy reply: “Applied. Lennart”. There have been cases where things have not been merged, but in retrospect they have been minor issues that were best solved elsewhere.
3) The journal is pure awesome. That said, you can easily keep using syslog-ng (or whatever) and journald will forward all the logging data so they end up in your text-formatted logs just as before (this is also useful if you want to use other syslog-ng features that systemd does not intend to replace).
4) dbus will soon be merged into the kernel. Even if it had not been: this is a tiny daemon that almost everyone will use (and I guess that even without systemd literally everyone will use it in the future). Creating your own IPC mechanism is not very sane, when one already exists.
2+5) *shrug*
OpenRC: As Allan said, the people who favor this should be the ones promoting it, packaging it, documenting it and explaining why it is better than systemd/initscripts. I had some (quite lengthy) discussions whit the OpenRC maintainer when he suggested we adopt this in Arch, and I was thoroughly unimpressed.
Tom,
If you’re referring to AF_BUS patch for the kernel when you say that DBus will be in the kernel soon I hasten to add that the patch has been rejected by the network subsystems maintainer. DBus is a questionable dependency for any subsystem that does a lot of IPC.
Nope. That was (apparently) rejected for good reasons. There will be a second submission (by someone else) in not too long. Eventually it will go in (based on who wants it done 🙂 ).
Archlinux has completely lost it’s moorings. Hopefully the reduction in contributions will bring the developers to their senses. Systemd ? Fail.
You do realize that it is the people actually contributing to Arch that get to chose the direction it goes… So if we are moving towards systemd, it is because the people contributing to Arch are moving towards systemd.
“Years ago, Arch used to ship packages without documentation”
Citation? Arch was choosy about which docs to include, but there has always been documentation included.
Not always… Documentation started being not stripped in 2008. See this thread: http://mailman.archlinux.org/pipermail/arch-dev-public/2008-April/005574.html
I think we are using ‘docs’ to mean two different things. Aaron is talking about info pages and html docs. I am talking any documentation, including man pages. You are are making it sound like Arch never even included man pages. There were always man pages in Arch, and reviews before 2005 often mention the “man pages instead of info pages” philosophy.
Spinning up the 0.5 base iso (circa 2003), there is indeed documentation on the iso: man-pages-1.57-1.pkg.tar.gz with 1394 man pages in it. When Arch was”stripping docs”, the info pages and html pages (for example,
/usr/share/gtk-doc/html/ in gtk2) were the only docs removed.
Also digging through the history, I forgot we used to do a non-rolling stable Arch release back then too. Times were crazy 🙂
Correct. I was using docs in the “options=(‘!docs’)” sense… I.e. what makepkg would strip out when you tell it to remove docs, which back then was everything but man pages.
> systemd ends up being about Lennart also writing pulseaudio
Are you shitting me?! I didn’t know that! This is the same dipshit who thinks that logs should have a binary format! Fuck that guy. Something is very wrong with the community that grants him any relevance.
8 years ago:
* Install Linux
* Play music
* Wonder why my games have no sound
* Turn off music
* Game sound suddenly works
* Why won’t my music work?
Today:
* Install Linux
* Play music
* Sound works in games too (and anything else I want to listen to)
Seriously, why do people complain about PulseAudio? Oh wait, it had some bugs in the first couple years. That shouldn’t have happened, because we all know that low-level systems that have to deal with buggy drivers *always* work perfectly the first time.
4 years ago:
* Install Linux
* Play music on my old computer without lag and all was perfect (after a little tweaking)
Today:
* Install Linux
* Play music on my f*cking overkill computer and… have lag and sound freeze. WTF?!
PulseAudio is unusable. Install PulseAudio, all audio stuff stopped working. Then I have to muscle around with configuration. It is okay for me to do the messing BUT i already have a working sound setup and everytime i install PulseAudio, things go haywire.
Please don’t drop i686 🙁
Its the only reason I use Arch, because its i686 optimization is perfect for my Thinkpad without having to go full Gentoo.
I used Chakra Linux as a secondary distro and they just dropped i686 support forcing me to remove it from my pentium 4 (i686) PC.
Please, don’t do the same with Arch!
Also because, thanks to the fact that it comes with no WM/DE and can be really lightweight it’s used on many old machines (at least, that’s my case).
sytemd is not that stable and polished yet.
lvm is unsupported (sic) from what I heard on irc. You have to rely on the service in lvm2 package which is sub-quality (and not even in the package right now)
As of today, I do not how to have an encrypted swap with my /var being on a LVM inside a LUKS/dm-crypt partition.
My work system runs Fedora 17 with systemd and root on LVM on LUKS just fine. In fact, it’s quite a common setup (two clicks on the install wizard).
Seeing as most of the important LUKS+LVM setup can be done in early userspace (ie, before systemd), this should be no problem for Arch.
Thanks for the well-written article. This should hopefully clear up some misconceptions about systemd and the surrounding changes not being KISS, which I think many Arch Linux users mistake for “supports my system configuration forever”.
Great post Allan.
About controversy of /lib symlink and so on: Arch was always rolling release and it was always simple from developer point of view – and those things never changed! For me those changes lately are just showing that Arch have strong leaders who got clear plan for the future – which is absolutely good thing! It make me feel secure about Arch future. I’m just afraid that many Arch users don’t get the “Arch way” and I think most of the complaints are from people who have no clue at all and just bashing because they installed Arch to feel “pro” and now they are afraid of changes.
About dropping i686 I think is to soon to do that (especially if you consider that Linux is often last chance to older hardware)
Good post Allan – I agree with what you say. I’ve used Arch for about 5 years now and recently have changed 2 of my 3 computers to systemd. The change was easy, no problems so far. I had several init scripts of my own that required porting to systemd – this was no problem either, and the systemd files are actually much simpler! One of the machines is a laptop, and systemd worked fine with my custom power saving scripts, and netcfg worked with systemd out of the box. I’d definitely give systemd a try, I was sceptical at first, but having tried it I’m converted!
But I thought rolling release meant we never have upgrades!
On a more serious note, I’m pretty excited about systemd. The last time I tried it, it was just an AUR package, which I didn’t want to deal with, but if it’s in the main repos I’ll need to check it out.
How about some more change? As an upstream developer I would love to see Arch finally get built with debug symbols and offer symbol packages like the rest of the Linux world. It’s such a pain in the a** to have to explain to every Arch user with a crasher that they have to recompile half of their system to get the symbols or we won’t have any use for their bugreports because the stacktraces are worthless.
I really don’t get why this hasn’t been fixed ages ago. There is _ZERO_ performance penalty for having these symbols (they aren’t loaded on exec) so it can’t be for performance. And wasting everyones time for a few KiB per executable is really stupid.
I think the reason it hasn’t been accepted so far is that no one has written a good clean portable way of doing it. Seems someone was close but then dropped it.
https://bugs.archlinux.org/task/10975
Seems like a very similar situation to package signing.
(Allan, is your TODO list public by any chance?)
Correct… the implementation basically just needs a bit polishing up to be applied. It just continuously gets pushed down the list of things I want to fix by more important/interesting issues…
The majority of my TODO list is in the bug tracker or the pacman roadmap in the Arch wiki.
Very good news! Looking forward to it. I’m very glad for all your efforts and I hope the trolls don’t get to you 😉
~A very happy Arch user.
I think “Arch Linux using the latest innovations” is very true, it seems to me however they lack a transparent decision making process on those things, so some day you might read the news and find out they adopt the unstable python 3 as the main version and breaking every existing peace of software that’s depending on python ever, or I suppose we read in the near future, they drop x86 support, because well, you know, who needs that anyways?
There countless examples for this kind of stupid decisions and that’s what drove me away from Arch long ago.
You can always subscribe to the arch-dev mailing-list. simple as that.
Thanks Allen for all your great work!
Great post Allan, thanks.
I tested systemd a few day ago and must say it isn’t _that_ hard to get going and improves boottime on my hdd mashine by quite a bit. On my laptop with ssd (hardly any daemons loaded and only syslog-ng and dbus w/o @) the current system is faster (systemd “starts” all daemons it can find so I had netcfg and wicd running at the same time).
I have read half of lennards first blog post (it is _realy_ long) about systemd and like the idea quite a bit for a desktop. On the other hand it is not so ideal for a laptop. I don’t like the idea that my laptop starts sshd when someone wants to connect (this is the desired behavior as said on lennards blog post – but I’m shure this can be fixed by some rule).
Change is a good thing, so please continue with it – but please don’t drop i686 in the near future. There are a ton of little netbooks out there running arch(I’m shure), they could run x86_64 but have <=2GB of ram so the penalty for running 64bit is greater than little speed improvements. Focus on x86_64 is the right thing to do, but keep i686 around for a while
“I don’t like the idea that my laptop starts sshd when someone wants to connect”
This can be easily disabled.
I thought so, I just didn’t had looked further into it. And on some daemons (like sshd) it shouldn’t be the default, or at least stated so on the wiki with a red warning message.
This is not more a default in systemd as it is to start the sshd daemon in SysV. IIRC In Arch daemons aren’t usually enabled automatically after installation. Other distros automatically start the sshd daemon just after installing it (Ubuntu, any?). Both behaviours are available in systemd.
The following is why I finally abandoned Arch Linux. No notice about the symlink of /lib to /usr/lib change which broke my system, and contempt when I reported it. Happy Fedora user now.
https://bugs.archlinux.org/task/28163
By no notice, you mean posted to the news page, the rss reader and arch-announce list? Arch has implicant trust that the user is responsible for their system.
You’re not one of the Arch Linux maintainers are you, your comment about implicit responsibility is the type of arrogance they’ve exhibited.
Glad you now got your separate /usr then. Happy Fedorings. I personally despise the whole thing (just like any other ‘noob distribution’ that is).
But what you initially got there wasn’t so much arrogance as just getting fed up with the style of your report and the fact that this was already mentioned elsewhere numerous times.
But yeah, I do agree it should’ve been mentioned in the News. That should be the only place you need to look at before/after updating your system.
When you’re going to write a rebutal…
1/Make sure your facts are correct. If you don’t know systemd, don’t talk about it. Half of what you wrote there is very misleading. Regardless, systemd is probably a pretty big error in the Linux world. Don’t forget to quote that in 5 years.
2/You don’t need to refute for the sake of refuting. See 1/. Some points are valid, many aren’t. That’s pretty crappy when people do that.
1- about the usr/bin <- (bin,sbin, usr/sbin) seriouly,,why not /usr/bin <- bin AND /usr/sbin <- /sbin?? look more FHS for me and pobably for practicaly majority of projects
2- in place of deprecated i686 why not upgrade to a pentium 3 or 4 minimal?, actually i686 is from prentium pro and I sure that noone can run arch in these machines due obvious limitants (pentium pro) but is far factible run in a pentium 3 and arch become the first distro in give support to i786 (pentium 3 or wathever the name yo choose)
3- and tru arch need debug simbols but not now, or why not build With debug simbols enabled??
Discussion on the suckless dev list sums it up: systemd is a flawed concept.
After 5 years using arch, i will be moving my work and support dollars to openbsd.
Thank you and good luck.
That’s funny.
No argument just statement. Good luck with OpenBSD – see you in month.
1. I would like to add more of Arch strong points:
Advantages of rolling release distribution model which are often forgotten:
– no need to install new version when major version changes
– no need to maintain multiple versions of same source just to fit your distribution
– A news comes when something big is going to happen. I think one of the core advantages which is really important for the users – makes a huge difference!
– I’m really thankfull for Arch’s documentation (e.g. wiki, forums, etc.) there is always enough information to solve your problems or at least give you direction of the right path, for which I have to thank all the hard working gals/guys.
2. The people generally do not like to change. I can somewhat understand the logic “do not breake what works”. However, without constant strive for improvement and trying Arch would loose its bleeding edge (which is Archs trademark). In the end, I think, the changes are needed and should be implemented. There should be a process of deciding if the new feature is beneficial for Arch – which, in my opinion, works at Arch.
3.The case of people using optimalization i686 or x64. I think distro optimalization should be done for the majority and not the minority. If most of the people use x64 Arch, then it should be x64 optimized. If people want to keep their old hardware then they can still use specialized distributions for that or even create a Arch based distribution for older hardware (The Arch should be bleeding edge as said above).
4. I don’t get people who judge software by whom it was written. Judge the code not a person (people)! If you don’t like it then fork it and make it better.
5. Controversies? Which ones? 🙂 I think it is important to learn new things and try to make the system even better. If this condition is satisfied then go for it!
6. Allan I really like your icon of Mugen 😀
Take care
We have a saying where I love. A giant can do too many mistakes and not fall.
I can compare ArchLinux to this. You broke your principles the minute you started splitting packages and moving dependencies to optional dependencies. This is ArchLinux centric and it breaks the whole foundation of a KISS distribution. I have been using ArchLinux for 6 years now and I know the trend.
Regarding systemd, I see absolutely no issue with moving from Arch’s initscripts to systemd. This is simply replacing one piece of software with another. It’s like moving from Gnome to KDE,,nothing more and nothing less. Arch’s rc.conf was nothing more than an attraction.