According to Distrowatch, there are eleven “distributions” “based” on Arch Linux. I use “distributions” in quotes, because some are far less of a distribution than others and “based” gets quotes because some are so based that they are really Arch Linux in a poor disguise…
I have seen a bunch of new release announcements for several of these distributions in the last few days, so I thought I would take some for a spin and see what I am missing out on.
All distributions were tested in VirtualBox with a 128GB disk and 2GB RAM.
Contender #1: Chakra – 2012.12 Claire
The Chakra Project is my #1 contender as it is a real Linux distribution. They do use our PKGBUILDs (sometimes too directly…) but they rebuild everything for themselves. Chakra also has quite an interesting take on the rolling release model, opting for a “stable” core of the distribution and rolling release userland. So toolchain updates are rare, but the newest KDE will be packaged within days. I have issues with their “stable” core, because stable means no updates at all. Even minor bug fix updates are not considered and I am sure there is no backporting of any security fixes either as their team is too small to handle that. For example, I would not be running pacman-4.0.2 or even an unpatched pacman-4.0.3 as my distributions package manager. Another thing unique to Chakra is the pure KDE set-up. Any popular software that is not Qt based (e.g. firefox, GIMP) is supplied in a bundle. I find these a very bad idea, as many of the same libraries are on your system multiple times but in separate bundles, and it also appears that these are easy to break and under-maintained.
Onto the installer… Chakra wins points for being the only pure graphical installer out of the distributions I consider here. I did a review of the installer early in 2010 and there seemed a complete lack of improvement. The Live DVD booted fine and welcomed me with a window that pointed out the difference between Chakra and Arch, and noted that pacman is not designed for a GUI frontend (debatable…) so it will be replaced one day. Starting the install gives three screens worth of install notes which no-one has ever read and if anyone did read them, I am confident they did not care that their website is being redesigned. The partitioning took me to an external tool (KDE Partition Manager), which I actually found rather difficult to use. It took me several attempts to get everything set so that the installer would let me continue.
Once I finished the install, I rebooted… to a prompt. Whatever autodetection is done to get the KDE session up a running post-install had failed in VirtualBox. So no further review was done.
Contender #2: CinnArch – 2012.12.21
I had heard good things about the Cinnamon desktop, so CinnArch was my next choice. This distribution is Arch Linux – when I look at the package information for glibc, I see that I packaged it. The only difference is that an additional repo is provided with the packages needed for Cinnamon desktop to run.
The installer boots to a nice live system. There is two installation options – “CLI installer” and “Graphical Installer” but the latter is not selectable so “CLI” it is… In this case, CLI means an ascii-graphical menu driven installation environment that was easy to follow. The only steps that I found amusing was finding the fastest mirror to install from, which (with only slight exaggeration) took longer to complete than downloading the packages from the slowest mirror would have. And then on with installing the packages. Or not… It turns out that the installer detects I am using VirtualBox and tries to install the virtualbox-guest-modules package, which currently has a broken dependency and so can not be installed. There is no way to skip this that I could find.
So lets play around in the live media to see what might have been. It turns out that CinnArch provides two repos: cinnarch-repo and cinnarch-core. I could not find the justification for requiring a second repo. The repo looks fairly good on a quick glance, with all packages signed and a keyring provided. Theoretically, you can just enable that repo and install cinnamon from there, but I could not find where to see a list of keys that the developers use that would enable me to install the keyring package and then verify the rest of the packages. One thing I was concerned about was the filesystem package that was being provided for reasons I could not ascertain. The biggest issue with providing a repo for Arch Linux is that you need to keep up with our rolling base. That means your repo needs to have rebuilds available when we push (e.g.) a library update with an soname change. Providing an unnecessary filesystem package seems to only make things difficult for them. This was also my first time seeing the Pacman-XG GUI for the pacman package manager. That is enough said about that…
Contender #3: Manjaro – 0.8.3 XFCE edition
I was not expecting much from Manjaro given I had read this review of a previous installer. But given the “success” of the last two distros, it has a chance… Some things from that review had not changed – in the live environment there is still the unnecessary password of “manjaro” for both the user and root. And I was not endured by the green colour scheme or the logo which is used for the “start” menu. But to give Manjaro credit, I successfully installed using the old style Arch ascii-graphical install, which was easy for those that are use to that. Reiser3 as the default filesystem still confuses me.
So what do you get from Manjaro? It seems to be Arch delayed plus extras. The idea is that the Arch repos are delayed reaching you for a few days while everything is sorted out to give you an easy upgrade. This happens by adding a package manjaro-system which is always upgraded first and runs a script that automatically handles any manual intervention that would be required on a pure Arch Linux system. As a heads up, this uses a feature of pacman called SyncFirst that is removed for the upcoming pacman-4.1, so they may need to rethink their entire system soon.
The first difference I noted was it ran a 3.4.24 kernel, so that have held that back from being updated to the newest release, but at least it is the newest 3.4 series release. Looking at the glibc package once again, I am the packager, but it is a repo called [platform]. The Arch [extra] and [community] repos appear to be used as-is, so the need for [basis], [platform] and [addon] repos to replace our small [core] repo is strange. Also, this was the first time I had ever heard of a GUI for pacman with the imaginative name pacman-gui. It allows you to run pacman -Sy, which just refreshes the databases – a crazy thing to do without immediately updating in a rolling release distribution that does not provide multiple versions of a library. And it is not much of a GUI either, as it just launches a terminal that runs the pacman command you just clicked. There was also a LibreOffice installer that called pacman in the background.
The Winner?
Sadly, I do not think there was any winners today. Chakra had the most polished live environment, but failed to boot to the desktop. CinnArch failed through no fault of its own, which is sort of a fault of its own for not being a real distribution. Manjaro installed, although I saw nothing to make me want to recommend it.
The may be the most painful statement I have ever made… but ArchBang might be the winner!
Edit: Twelve hours later and the bug on the Arch end preventing the CinnArch install has been fixed. CinnArch installed and booted to the desktop without an issue.
And what about Bridge Linux? 🙂
The url of the Bridge Linux site concerns me for some reason…
I tried it myself. It’s literally just an installer for Arch. It’s nice that it almost gives you a working system (upstream issue with grub2 that they didn’t /wont/can’t fix), but after you get past that issue , it’s just a quick way to install my favorite distribution. Though I didn’t go deep enough to see if they made any underlying modifications. They use your repositories. You simply get your choice of 4 desktops and packer pre installed. If you ask them(I did^^) they think it’s revolutionary and the best thing since sliced bread.
I say keep up the good work, imitation is the best form of flattery.
Hi,
I tried Bridge Linux to, but was alarmed that during the configuration of the system, the host name is given as “archbang”, suely this must mean it is archbang with a KDE desktop installed?. I have been trying out Chakra and Bridge linux, but they didnt tick for me. I tried earlier versions of Manjaro and found it to be promising Arch based distro, then ver 0.8.3 came out and Ive been using ever since, Apper works fine for app instaalation, so does CLI and theres always yaourt which works well to. I am no developer, but I think Manjaro ids a good choice for an Arch based distro, easy to install, polished desktop, great set of pre-installed apps and a great package manager system.
Have you noticed how “sudo” is setup in Bridge? I have had to use visudo so that the password is required for sudo.
I tried Bridge before. I didn’t get any error so I guess it’s nice. It works nicely too, but not much of significant different from just Arch. Except that it provides live GUI, installer and all those stuff like Archbang. But for more polished OpenBox I’d say Archbang has done it very well. Only if I were to say something about Bridge, probably just Arch with pre-guided installations as well as pre-provided needed stuff.
That’s pretty nice observations you got there though.
Awesome.
I installed twice to make sure. Used as default a configuration as possible, save for setting btrfs as the fs type for / and /home. Two sed commands fix it, you just need the uuids of your partitions. But it’s only purpose is to make the installation easy, anyone using arch needs to do it the manual way so they know where things are to fix them… I don’t see bridge Linux doing too well, unless they keep on using the Arch repositories. Which IMHO is a dick move.
I’ll do fast to save your time :
Why not do as Freebsd with Pc-bsd being an official but not recommanded fork, but keep it acceptable, just a basic install with the absolute required apps for all users level in mostly any case *network manager with drivers/firmwares just enough to go online, text editor, web browser, package manager, offline documentation, basic window manager ready to use, …*, even the graphical installer could be acceptable, making it an educative installer to learn to install archlinux normaly for example …
This cut the wasted efforts on forks and will bring more developpers to Archlinux that could bring ideas and talent on the table, anyway distros wars aren’t a solution against forks …
Maybe that will bring back what Archlinux was losing, an identity, Aur for example seem to requires a fix as many maintainers are now out, so this lead to a massive amount of out-of-date/unmaintained packages on one of the bigest strenghts of Archlinux, so the health report isn’t so well about the distro I love so much, this may be a big part of theses forks makers help to Archlinux for example …
I hope that you will understand that it’s nothing to be rude, just actual fact and personnal thinking …
Well Mike, as I see it, rolling release + AUR was what really attracted many users outside the penis measuring uber-geeks. The middle of the road users could care less about the technical underpinnings or otherwise quite frankly.
Instead of nurturing those users to contribute to the AUR further improving the distro, the Arch dev’s have succeeded in alienating all the middle of the road users by borking their systems at every opportunity. The standard answer of how to fix is it is always snide ‘if you don’t know how to fix it then you are not _worthy_…
Now Arch is going back back to being a quiet little backwater of exclusivist uber-geeks.
I’m sure this is what is intended.
There is a lot of things that attract users to Arch. But most of the users don’t realize it is different and it require basic skills (like reading, thinking, stuff like that, nothing fancy). There is a lot of newcomers who just blame whole world and Arch’s devs instead of learning what Arch is and what it’s not. I don’t understand why people have such a hard time to trial run a distro and decide if it fits them. Instead they are offended because “it’s not what they wanted”. Of course it’s not. You don’t go to NASA asking for Cheesburger.
About whole ” ‘if you don’t know how to fix it then you are not _worthy_…” thing. You obviously don’t check forums often. It’s called noise. You don’t welcome every single punk with open arms. And people who fits Arch doesn’t have hard time here, they are welcome and they find the way – it’s not that hard. And no, you don’t have to know anything about Linux. You just need to want to learn some things which are needed to run Arch happily. And people who are like “it’s different so it’s stupid, it’s not GUI so it’s stupid, make it my way or you’re stupid etc etc” are not needed and they won’t be happy with Arch either so no problem here. They can find another distro which will fits their needs.
After spending a considerable amount of time getting Gentoo running like I wanted (even with a relatively “plain” Openbox environment) I was so thankful to find Archbang. Getting my DE configured was the biggest headache of Gentoo for me, so I was happy to have at least that part taken care of for me in Arch (by using Archbang). I didn’t want to try any of those others as they just seemed to introduce too much complexity to the process.
I touched upon the SONAME (et cetera) problem in a post of mine as well:
https://plus.google.com/u/0/111457576238197018431/posts/3mbDfmWTfSX
I’ve never been a fan of “based” distro’s, Ubuntu has so many so called based distro’s as soon as I see one I discount it completely, mainly for the fact how slow dpkg and apt is.
There are some other arch based distro’s that I think are worth mentioning. Parabola GNU/Linux and Arch Linux ARM . Parabola from what I have seen is pretty good, if you are looking for something RMS would put his label on, see http://www.gnu.org/distros/free-distros.html .
Arch Linux ARM though I see more as a technical fork, and I think eventually arch linux will suffer with this one. Unless some changes are made upstream, upstream being arch linux is this case. I could be wrong here, or nobody really cares if Arch officially supports ARM. Time will tell.
Nothing official from me… but I think the ARM situation might become more clear when it becomes more apparent what architecture should be built. From memory, Arch Linux ARM currently builds for three architectures and I would be surprised if a build for AArch64 on does not eventuate. Also, I think Fedora, OpenSUSE and Debian all build for different ARM architectures. Once the situation calms down a bit and a good common architecture is decided on, it would be more attractive for Arch to support that.
I agree, and the issue here is the ARM vendors, however anything past v7 seems to be somewhat sane. the lack of proper floating point below v7 is real issue. stuff like rasberry pi while being popular are actually kinda crappy due to lack of floating point. also when gcc upstream has gnueabihf I think things will get better.
Just some clarifications: There are ARMv6 implementations that have an FPU, which does include the Broadcom chipset in the RPi. There aren’t many others because ARM does not mandate an FPU be included. There isn’t anything “past” ARMv7 aside from ARMv8 (aka AArch64, which isn’t out in the wild yet), but there are many implementations of that instruction set that vendors choose to use for the specific product they are developing. GCC has hard-float support (gnueabihf), has had it for a long time, and Arch Linux ARM builds for that on v6 and v7 instruction sets.
Unfortunately there isn’t any way to determine a common architecture, and there’s not much to wait for to settle unless you just want to push out 10 years and ignore everything old because it’s old. At this point, the only thing to do in that regard is pull a Ubuntu and decide not to build for any instruction set below ARMv7+vfpv3-d16; however, that cuts you out of running on hundreds, if not thousands of other lower power yet very usable devices.
Kevin thanks for the clarification, if I was wrong about rasberry pi forgive me. I thought I read something to the effect it lacked a FPU. And I agree that the current state of ARM warrants Arch ARM as it is now “hence the term technical fork” .
However if we look forward, I think there will come a time where ARM will be in demand enough to justify it being officially supported by Arch linux, I could be wrong about this, but I don’t think so. If say it does become as popular as I think then yes, it might be a trade off to target the lowest possible denominator, like we do with i686 and x86_64 there just not as fragmented. and the trade off are probably a lot higher.
Either way with the current development model for arch, its next to impossible to rebase changes in any sane way. So if the time came to merge ARM back upstream, the job will not be so easy. If Arch was using a more flexible system like git, I think ARM would be a mere branch and not so much a fork. But I could be wrong and maybe I’m being presumptuous that arch wants anything to do with ARM at all 🙂
I personally favor the approach of making x86_64 the Arch primary architecture and dropping i686 to a secondary architecture. The allowing more secondary architectures to join, such as ARM… I’d push a lot harder for this if it was obvious which ARM architecture I would like included, although AArch64 might be that architecture.
I don’t think that moving to git would make a merge of an ARM architecture any easier. Most packages just need the appropriate architecture added to the PKGBUILD and anything else would warrant a review. In all likelihood, a complete rebuild would be required anyway so everything was in sync as possible with the primary architecture packages.
Maybe I should start thinking about this more now that AArch64 support is near completion in release toolchain components.
I was using ARM as example. but this is how I would probably do things. I would say use x86_64 as the main branch then re base everything off that. You could also use git for the abs script, and lose the one day delay for abs updates, they really suck btw.
And you could get ride of the arch trunks, and end up with a more what you see is what you get feel to the abs source tree. along with getting ride of the script that imports to git web. git log core/gcc has the added bonus of a changelog since hardly anyone uses the changlog feature anyways,
And as it relates to this thread yes it allows people to rebase and fork archlinux work, however it also allows alot more people to easily contribute back, and much easier for others to code review and catch issues.
But I could be totally off here, I’d have to agree that I’m sure the current state is great for developers. but its really not great for anyone else.
In considering a merge, there isn’t a whole lot we do different than Arch itself. We have a small pile of packages that need specific modifications for ARM, but other than that everything is built as it is upstream. Our one big deviation is the way in which we build the packages, which is all done through an automated system we wrote to handle building everything in correct dependency order, bringing in the latest packages from upstream as they’re updated. A merge is more of a logistical than technical problem, as Arch ARM has grown into its own separate ecosystem of sorts. We’re always open to discussing it all.
do you have link to your build system? I wouldnt mind checking out. I’ve been working on a build/package system on and off for sometime now, where the PKGBUILD or plans I call them are machine readeable writeable. which makes automation much easier. http://code.google.com/p/via/ still very much work in progress though. most of my LFS systems have been migrated over, and it manages my android’s detach glibc install.
I tried the Chakra Live DVD a while ago as well, without proceeding to any kind of installation.
Here’s why i didn’t like and prevented from even trying to install it:
a) Number one reason was its equivalent core repository and particularly base. It looked like a really old version of Arch’s. I have the feeling that not much attention has been given to it since Chakra branched from Arch.
b) The Chakra team, besides the fact they decided not to support i686, only create a DVD release.
That means the same release is used as a live disc, as well as an installation medium.
The Chakra team decided to include various pieces of software in the live medium i have no particular use for and imo selection is pretty obscure.
In fact, even though it is supposed to be a KDE centic distribution, most of the installed by default software is not part of KDE SC, not even KDE extragear. I figured that i’d have to replace half the applications with my own choices.
Also a note about Cinnarch. I visited the distributions IRC channel and chatted with its developer for a few minutes.
What i got out of it was that he wasn’t even aware of the way Arch works and software that comes out of it. In particular ignoring what netcfg is. Thanks, i’ll pass.
Care to elaborate on “most of the installed by default software is not part of KDE SC”?
DVD contains KDE/Qt only apps, and only non KDE are spideroak (Qt equivalent of dropbox, minus spideroak storing any personal info), calibre and mini-tube (since flash-plugin is gtk2, providing mini-tube gives full access to you-tube). Not clear how that is considered “most”, rekonq, kdenlive, ktp-telapathy, dragonplayer, calligra, amarok, etc are all KDE apps.
“I have the feeling that not much attention has been given to it since Chakra branched from Arch”
Updating the kernel 4-5 times a year, toolchain twice a year, sound packages 4 times, openssl, krb5 stack twice a year does not count as giving attention (just to name a few of the group builds done)? Keeping xorg at 1.12 to stay compatible with catalyst and some older nvidia is not a choice, but giving no attention? Full switch to (latest) systemd and all core packages that it depends on seems to you nothing is done in Chakra?
Of course it is bad Allan had issues with installing to a virtulabox and that needs to be corrected, but hard to correct if not clear what went wrong, and Chakra devs can’t reproduce. Hopefully Allan can elaborate so it can be corrected for the next ISO.
And to Allan, Pacman was designed to use for GUI? That is news to me, and will remove that text. Though I have yet to see a Pacman GUI that actually does handle any and all (more complicated) updates. Shaman handled it for about 6 weeks ok, but after Pacman updates broke Shaman a third time, no further effort was done yet again to make it work. You would recommend Apper for all Arch updates, since Apper is in your repos?
I would not recommend apper at all… Shaman showed what could be done. In fact, if a distribution waited for the Shaman developers to port to the new libalpm that was released, it would have worked fine. But these were the days where Chakra was KDEmod and Arch was not going to hold back a major pacman update for KDEmod. Also Arch was not going to patch libalpm between releases for an unsupported package. Admittedly there are areas where libalpm could be improved for GUI use, but given there are no current GUI users the motivation to fix them is limited.
As far as replicating the virtualbox install issue, I managed to do it twice by just clicking through the default (or top) option every time and installing to a single ext4 partition. If it is still not able to be replicated, I can do it again and provide detailed instructions.
The 2012.12 ISO was tested extensively in vbox and real installs. Of course it would not have been released if any testers would have found this issue. Nor has this vbox install issue been reported since the release, only found the issue in this blog, so any info how to replicate will be welcome. How much RAM assigned –and it goes without saying really, but md5sum was checked, right?
Still not clear on this answer if Pacman is considered designed for a GUI. After years of many coders trying, dozens and dozens of GUI’s been developed, currently there is not one available that can be recommended. Or all these GUI’s were not working, because there was no interest in a GUI by users?
As it said in the post “All distributions were tested in VirtualBox with a 128GB disk and 2GB RAM.”. I can still replicate, so I will email you detailed instructions.
Only one GUI was ever coded for libalpm – that was Shaman and it was very successful while maintained. All the rest of the GUIs try to capture pacman’s output instead of using the library and that is why they fail so much. Well, apper is a packagekit frontend and as we all know, the libalpm packagekit backend could be better… There are extra things that could be added to libalpm to make it more useful to GUIs (allow including a screenshot in the package, categories, …) but no-one has ever approached any of the pacman developers to implement this. Instead they just patched their versions…
Thanks for the info about the tribe issue, we find that BLKID uses a cache which only gets updated after a reboot. With some changes in the backend using /dev/null as alternative cache for BLKID we managed to fix the issue you had for the next release.
Thanks for the detailed test report, issue is now replicated, and caused by using ext3 in advanced option, then switching to ext4 in the partitionpage of Tribe.
http://chakra-linux.org/bugs/index.php?do=details&task_id=502
Obvious not something anyone has tried to do before……
Allan I can’t seem to comment on the lower issue so I’ll comment here sorry :(. The libalpm library is no walk in the park, everyone needs to implement there own config parser for one. alpm double link lists encapsulates void *data which can be just about anything, and very hard for certainly languages to deal with. Still it is alot better then the days when there was no libalpm and pacman was monolithic.
I have never needed more than the default 5 levels deep in comments before – extended it to 10!
The config parser is an interesting one… It is the config for the frontend so another frontend could use whatever it wants, especially given a GUI would want to be able to edit it. But I know the issue GUIs wanting to share the pacman configuration file. I dealt with that in my toy code by just stealing pacman’s source file for reading the config. I know some work has been done on providing a parser, but I am not sure where that went.
I have a mild hatred towards the linked list implementation… 😛
ha 10 comments.. I was not planning to help troll that hard.
“Care to elaborate on “most of the installed by default software is not part of KDE SC”?”
I can remember XBMC, quassel, bangarang offhand.
I don’t know what the philosophy, if there is any, behind Chakra is but i expected to find something closer to KDE.
For example no konqueror & the inclusion of quassel instead of konversation is exceptionally weird to me since all traditional KDE centric distributions include konversation. Only kubuntu has quassel.
Plus, something i forgot writing about in my original post, you can’t deselect packages in the installation DVD. You have to install them all.
That is my view, your opinion might be different.
Regarding core/base i am not talking about updating packages.
You are welcome to compare Arch’s core repo to Chakra’s equivalent and look for differences, most of which i consider to be advancements. Again someone elses opinion may be different. Plus Chakra doesnt have to follow everything Arch does anymore.
There are 12 “distributions” “based” on Arch Linux on DistroWatch.com now…
I did not count Arch Linux as being based on Arch Linux… That is why there are 11.
Chakra Archimedes works in a Lenovo Ideapad Z470 without troubles. The installation is very easy.
Allan I always enjoy your posts, and this one is no exception.
I have for a long time wondered why there are arch-based distributions. It confuses me, because like you say most, if not all, are Arch with some packages pre-installed.
Personally, I would prefer it if all these “distributions” were acctually “installation profiles”. Just like Drupal has installation profiles but there is one and only one drupal, no spin-offs.
I believe that they are rivalling arch, a little, while they shouldn’t.
I would love to see the effort and development being done on all these 11 distros take place under Arch, in order to make it even better. It would mean a far great user-community and more complete repositories (in the case of Cinnamon for example).
I hope that we stop seeing more and more arch based distributions in the near future and instead they join forces under Arch.
If this is true, shouldn´t all Arch developers move to Debian and join forces there ?
Not at all. Arch is very different from Debian. Matter of fact it shares nothing with Debian.
Contrary to all these arch-based distros, most of the time they are arch with some extra packages.
Arch is one of the distributions that is not based on some other linux distro.
I know. BUT if combined power is so much better why not combine power to make e.g. Debian better ? Why maintain Arch ? Why split from the crowd ? Because Arch is better suited for your needs than Debian ? Well, what if Manjaro is better suited for my needs than Arch ?
I just don´t have the time to maintain Arch-systems on all the computers i have to administer. Or maybe i´m not good enough to do, whatever. I learned a lot using Arch but i´m fed up with breaking systems (and i broke mine a lot, which probably was my fault). As you can see, i am unable to really contribute a lot, but i still can help some total noobs and maybe a little more. As i was unhappy with Arch i checked out PCLinuxOS (which i liked but it´s KDE-centric and i just can´t stand KDE) and Mint (those guys are doing a great job to make Linux beginner-friendlyf). As i was drifting away from Arch along came Manjaro- a user-friendly Arch spin-off. And it kept me using the Arch-repos. It will eventually make me use Arch again. Isn´t that better than using *buntu ?
Bill, its quite simple.
Not everyone wants to spend endless hours at the command line learning the most arcane details of Linux (Arch).
Some folks want a quick & straightforward GUI installer into a basically functional system + Rolling Release + AUR.
From there they can learn as they go.
Of course this is not “the Arch way”
So, lots of hate on all the alternatives.
Whilst I agree with the final conclusions of this article it does come across as being the usual uber-geek sniping found in the hard core followers of Arch.
Whatever..
I used to really like Chakra: but since they went 64 bit only I’ve been unable to use it (old hardware only, sadly).
I tried Cinnarch and still have a virtualbox build of it: but it seems a bit buggy. Still: its very early days for this distro so I don’t want to be critical. An arch based distro with cinnamon as a base seems a great idea.
I really like Manjaro: with each release it seems to improve and I have found it to work very well on low end hardware. I’ve found the XFCE version the best: I think its their main focus.
I’ve used arch since “voodoo”.. I miss arch’s installer that was removed some time ago.. I have issues with the script way of installing.. I’ve tried using the forums, just got the age old egotistical attitudes.. so I went the chakra way.. enjoyed it..but then found cinnarch/archbang/bridge/manjaro.. I hated breaking things just doing updates.. so manjaro is the way I went.. I enjoy waiting a few weeks or less for updates for the sake of stability.. I notice lots of forum posts in arch , many devs, etc, dont like the idea of spinoffs.. which is ok.. I’ve been somewhat bashed for even putting the name of certain spinoffs/etc in forum posts.. but again, that’s ok.. Manjaro for me..
After having used Arch KDE for several years, last fall i ran into some glitches (one was not beeing able to shut down the system after a systemd update) that made me feel uncomfortable to use it as my stable system. As a consequence I installed Mageia KDE on a spare partition as my productive system. Still I liked Arch for it’s philosophy and simplicity better and began to think that there should be something a little less bleeding edge like “core-tested”, “extra-tested” and “community-tested” repos.
After reading about Manjaro I switched my Arch installation to Manjaro, basically a “pacman -Scc” and “pacman -Syu” after changing pacman.conf to their configuration. Apart from some extra features I don’t need and the 3.4 kernel they provide (hopefully) better tested snapshots of Arch repos, exactly what I would love to see in Arch. In six weeks my testing experience has been smooth and stable.
So as long as Arch itself does not provide better tested snapshots, from my point of view they have a reason to exist.
In the six weeks you have been using Manjaro, were there any actual issues detected and then updates delayed? Not that I know of… I have yet to see an issue that their four developers stopped that the Arch developers and users using the [testing] repository did not?
I’m not aware of any delayed updates because of detected issues. Nevertheless, they provide their own kernel and systemd packages, both core parts of a linux system and they seem to be a little more conservative in updating them.
Another important point are snapshots: In an ideal Arch world every non-testing user would use the same snapshots. In the real word this would only be true if every user would update his system after _every_ sync of the mirrors, a very unrealistic scenario. So at a given moment there are many different Arch systems out in the wild.
Manjaro updates of stable repos happen, as far as I could see, every one or two weeks. Using an update notifier like apper makes it easy to keep the system in sync without having to -Syu a few times a day an makes it – at least in theory – easier for the devs to hunt down bugs.
I know that it is a delicate task to update a rolling release system. The balance between getting an outdated system with unpatched security holes and rushing in new packages is not easy keep. I felt that Arch was recently more on the latter side, so I will give Manjaro some more time to prove additional stability. Anyway, a switch back to Arch will be probably as easy as the other way.
Allan,
Can you say something about archbang please.
Sure… Arch Bang is “just” Arch Linux with openbox installed. And if you just follow the instructions on their website about how to set-up openbox, that would be fine. However, they have also done things like adding a shortcut to update your system using “pacman -Syuuf”, which broke many systems. It also (used to?) install yaourt by default giving the impression that this software is supported and install the drivers for every graphics card resulting in conflicts.
That results in people coming to the Arch Linux support channels asking for help and not having any idea of what configuration changes have been done to their system. The Arch community also has no idea what is done to their system. So when you install using a custom installer, you are not supported on the Arch Linux forums or IRC channels…
Thanks Allan, got it.
If you return to my previous comment, having a somewhat Pc-bsd like Archlinux also mean that the forums would have a dedicated space for it/them and it could be checked back a bit molded by the feedbacks of the Archlinux developpers if they want to participate …
Just a basic facts sheet on Archlinux derivates I tested that could help :
Archbang – focus on Openbox, don’t include codecs and flash/java, keep Archlinux repositories
Bridge – focus on Xfce but there’s a few others choices, don’t include codecs and flash/java, keep Archlinux repositories, developper active on some support groups on Facebook so accessible to users, updated isos at each major Archlinux update so new installations don’t suffer from the rolling release way troubles, added a repository to update the installer before the installation to evade potential troubles …
Chakra – focus on Kde, mostly great before they diched Arch, however Aur2CCR package allow at least to still use Aur, however it’s not much stable for now, include codecs and flash/java, use only customised repositories, high focus to keep Kde not slowed by GTK librairies by isolating them, use bundles to install multiples packages at once, have it’s own Aur like repository known as CCR, 64 bits only, dvd sized releases only …
CtkArch – focus on Openbox, don’t include codecs and flash/java, keep Archlinux repositories, live cd is removable after launched as it use a to ram option *run in the ram memory*, french based
KahelOS – focus on Gnome3, not my taste so I ditched it without trying it much
Manjaro – focus on Xfce but there’s a few others choices, include codecs and flash/java, have a hardware detection tool with support for Nvidia Optimus, support for multiples kernels in case of troubles, Use delayed of 1-2 weeks Archlinux repositories with the manjaro dedicated repositories for their tools, have had major troubles with the update system before, still compatible with Aur, have maded a manual to know how to use the system …
thanks mike. that’s pretty enough to know other archbased generally. since i just tried arcbang, bridge and manjaro. frontman archbased that i know.
I freeze my Chakra installation after the release of “Claire”. Many broken package, can’t install printer driver, can’t change desktop setting, etc. I stayed with Archimedes and wait for “stable release” (for me).
I would grateful if you could give a review of ArchBang iso in the near future.
So now, when CinnArch and Chakra runs: Test it finally ?