A number of new SpaceFM plugins have recently been added to the wiki. The latest addition is JP Fleury’s Corbeille-SpaceFM, a freedesktop-compliant trash plugin optimized for speed and large files, available in French and English. He has some speed comparisons there that look promising!
This means there are now several trash plugins to choose from. Some of the plugins are from Arch users, with some discussion in the SpaceFM Arch forum thread (the later pages deal more with plugins).
Also, a new official SpaceFM IRC channel: #spacefm on irc.freenode.net. This is more intended for general chat than for support, but we’ll see what develops. OmegaPhil is in charge there.
Someone asked in a comment how Aptosid has been running in the long term, so I thought I would provide a quick update on my experiences, and also introduce the new Siduction distro.
For those who haven’t followed the whole story… After discovering early last year that Arch Linux had no package signing, and after speaking with their lead developers and discovering they had very questionable attitudes and practices toward security in general, I moved from Arch to Aptosid as my main distro. Since then, Arch has added package signing. While I’m glad to see they’re making efforts in this area, I still view Arch with a wary eye regarding security, mainly because of the attitudes I encountered. Good overall distro security (not just package signing) is hard work, and if they don’t take it seriously, it won’t be done well. But I have not followed Arch’s more recent work or discussions, so I can’t comment on the current state of affairs there. I find it hard to believe they’ve corrected all the issues in their development process, but I’m glad they’re taking security more seriously. In many ways Arch is a great distro, so I hope they continue to improve in this area.
I’ve been using Aptosid for about one year. Aptosid is a rolling release distro – basically Debian sid with optimizations, fixes and support. As with Arch, one can update the system several times a day to get the very latest upstream versions of software, sometimes including breakage.
Before I comment on the results, it’s important to know what I use in general, since this can impact performance. I like a lightweight, very responsive system, so I run plain Openbox as my WM, with mostly independent GTK apps. I tend to avoid apps which are tied to particular DEs, such as Gnome VFS dependent apps. Some of my favorite apps include Geany (text editor/IDE), Claws-Mail, Firefox, LibReOffice, gFTP, Deluge, Mplayer, VLC, Asunder, Brasero, Geeqie (image viewer), Gimp, Evince (PDF viewer), Roxterm, LXPanel, and of course SpaceFM (file manager). I highly recommend these apps – most are ‘old school’ Linux with good attention to quality and rare breakage.
Unfortunately, on one system I require NVidia’s proprietary driver as my video card features are not fully supported by nouveau. And I have a Brother laser printer that requires Brother’s binary blob. I also run the non-free Flash plugin so I can view the entire web. I boost security a bit by running Firefox/Flash in a Sandfox sandbox.
For the most part, Aptosid has been running great, which says a lot for their development process. You don’t get this kind of reliability in a rolling release by accident. It’s also a pleasure to use because I have access to the Debian unstable repos, which contain just about everything I use. Part of my success with Aptosid is due to the apps I’ve chosen – they are well-developed and maintained. So even using their latest releases there is rarely breakage. In fact I can’t remember ANY.
Where I did run into trouble was with Aptosid’s NVidia support. The Aptosid devs don’t like non-free components, and I wonder if their support in this area is somewhat below par. But it could also be that NVidia decided to start breaking just when I moved to Aptosid, as the bugs involved were their fault as far as I could tell, and Xorg was going through some growing pains at the time. I don’t expect Aptosid to fix NVidia’s bugs, but they could do a better job advising users how to deal with the breakage, and being less hostile toward the use of non-free components. As a result of my NVidia issues, I occassionally couldn’t do a full update for several months at a time. I instead updated a few apps and components. Eventually the problems were resolved upstream, or in one case I needed to update my Xorg config to work around a change.
Despite the fact that I run a rolling release, I do not usually need the latest and greatest, so this wasn’t too inconvenient. By comparison, I had more routine breakage running Arch, but it wasn’t as long-term. And I had FAR more issues back when I used Ubuntu supposedly-stable (but with KDE involved).
I have also installed Aptosid on a number of laptops, such as the Asus A53E-XN1. In general I’ve had very good experiences with Aptosid in this area.
I have not had to reinstall Aptosid at all, though by comparing it with newer installations, I’m not convinced they’re the same. The packages are updated, but some of the system’s configuration may grow out of date. I haven’t had any problems with this, but after a year I’m wondering if a fresh installation would prove valuable.
My method toward rolling releases makes a difference too. Before every update (which in Aptosid is an apt-get dist-upgrade), I make a backup of the entire system partition (using Partimage or FSArchiver, as detailed here, and also automated in SpaceFM’s Device Manager). If any serious breakage occurs, I roll the entire partition back to its pre-update state. I then wait for a fix or sometimes participate on the forum. This makes updating about a 20 minute process and requires a reboot, but it is well worth the time. As a result, I don’t update all that frequently – usually every few weeks – but given the apps I use this isn’t a problem. (Aptosid recommends updating more frequently, and at least every 2-3 months, but I and others have gone longer without problems.)
So rolling release doesn’t have to be an unstable experience, and my system runs great. In some tests Aptosid has been clocked slightly faster than Arch, or vice versa, but they are very close in performance. I find Aptosid’s/Debian’s packages are more carefully put together, especially where security is concerned, but overall system maintainance is comparable in terms of time required fussing with it (minimal), if different in terms of the methods used. I think I slightly prefer Arch’s maintenance methods, but I prefer the work that goes into Aptosid’s (Debian’s) packages and their comprehensive approach to security.
In late 2011, some of the current and former developers of Aptosid broke away and started a fork called ‘Siduction’. Their reasons include creating a more user-friendly experience, and better support of non-free components. As user Kelmo describes:
The technical differences between the two are to the best of my knowledge untold so far – mostly conceptual/behavioural differences separate them at this time. The people behind “siduction” have a strong difference of opinion about the way the people behind “aptosid” conduct themselves in developing and supporting a FOSS distribution, so they decided to copy everything to somewhere else and started moving on with whatever it is that they want to change. link
It’s worth noting that the conduct on Aptosid’s forums leaves a bit to be desired. It is not the friendliest of forums, in part because of the developers and admins. I don’t think they mean to be as rude as they are, but their impatience and attitudes do offend some users. I think they’re working on it – I’ve seen some improvement lately. But I think Siduction is in part a response to this problem. On the positive side, Aptosid’s devs do participate on the forum, so often there is expert advice there.
Siduction is a creation of developer ‘fickleplatz’ and others who were major contributors to Aptosid. Some of Siduction’s web pages are in German, which makes it a bit difficult. Hopefully this fork will grow into another solid choice.
SpaceFM 0.7.2 is available.
New Bash Function
The function spacefm uses to run bash via various su programs and terminals has been redesigned and rewritten. This function had become a bit overgrown due to the inconsistency among su programs and terminals. The new version is much cleaner and should provide for more flexibility for future uses. Although the changes should be transparent to most users, you may want to note the following changes:
- spacefm now uses a single temporary script to run bash commands and scripts, rather than separate exec and source scripts
- a new intermediary permanent script ‘spacefm-auth’ is now installed to /usr/bin (or /usr/local/bin). This script simplifies the commands passed on the command line to su programs, and is used to authenticate temporary scripts run as another user (such as root) using sha256sum.
- spacefm’s temporary directory (/tmp by default) can now be mounted with the ‘noexec’ option if desired
- spacefm now supports the new ktsuss2, with some reservations (see below)
If you do notice a command/su/terminal combination that no longer works, please let me know so I can accommodate it. I have tested the new function but it is impossible to test every possible use due to the number of combinations – that’s where your feedback comes in.
The developer of ktsuss has released version 2 which addresses two security problems present in ktsuss 1.4 and earlier. However, ktsuss2 has also introduced some bugs which limit its ability to be used in all circumstances. I have discussed these with David Cortarello and he said he would look at the issues.
The primary bugs which affects use of ktsuss2 in spacefm 0.7.2 is that ktsuss2 does not return the exit status of the command being run, and it discards the stderr output of the command. This means that commands run in spacefm with ktsuss2 will present no error dialog or output if the command fails – you won’t know it failed. So I cannot recommend use of ktsuss2 at this time.
Below are some of my bug reports on ktsuss2. Except for the error issues above, the rest of these issues should not affect spacefm 0.7.2 and later, but do affect earlier versions.
The icon sizes 20×20 have been replaced with 22×22 to prevent unnecessary scaling which caused blurring of some icons.
Also, the close buttons on tabs now use a smaller icon.
Also, the icons in the Devices and Bookmarks lists, and in the directory tree side pane now obey the small icon size set in preferences. Some custom icons you have specified may look different or not work in version 0.7.2 due to changes in the way they are loaded.
MBR & FSArchiver
spacefm can now create MBR and FSArchiver backups of mounted volumes. For FSArchiver, the volume generally has to be mounted read-only, or you have to specify ––allow-rw-mounted
The SpaceFM User’s Manual has been updated to reflect changes and minor corrections.
For a more complete list of changes please see News.
Although most users across many distros are reporting high stability using spacefm, some users have commented about crashes but have not filed bug reports. In case you think the developer sees these too, I do not – spacefm never crashes for me, and if it does, I fix it. The only way other crashes will be fixed is if they are reported with enough detail on what triggers them. Preferably, also install gdb, build spacefm with the appropriate flags, and provide a backtrace. Otherwise fixing such bugs is like finding a needle in a haystack.
As of version 0.7.2, the only reproducible and sufficiently detailed crash is this one, which is caused by a bug in libgdk-pixbuf which they have done nothing to correct thus far. However, that crash only affects one known particular icon file, although there could be others.
Although 100% stability is simply not possible in the environment spacefm is run in, the way it will achieve its highest stability is for the users experiencing such problems to take the time to make detailed reports. This goes for more minor bugs too. spacefm has many flexible functions which makes it hard to test completely. If you find a minor bug, please report it. Your testing and feedback is appreciated and helps to improve the software.
More distributions have added spacefm to their repositories or have test packages available. These now include:
- Gentoo’s portage tree includes spacefm
- Sabayon includes spacefm in its repositories
- Arch Linux’s AUR includes spacefm
- PCLinuxOS has spacefm test packages available (see forum)
- VectorLinux has spacefm test packages available
spacefm has been getting some good press, which is helpful for letting new users know about it. Linux Format magazine will have an article about spacefm in their April 2012 print issue, in the LXFHotPicks section. I received a complimentary copy and they gave a very positive review. WEB UPD8 also has an online review.
“Abandon all hope” was the title of a recent LWN security advisory on the Flash plugin, which has been my philosophy with regard to Adobe products for quite some time! It’s a good reminder to use something to isolate Flash from the rest of your system, be it a basic filesystem sandbox like Sandfox creates, or more comprehensive solutions.
It is a mistake to think these vulnerabilities are found and corrected in anything like a timely manner, and to assume that additional vulnerabilities aren’t created to replace them. As David Bowman might say, “The thing’s hollow – it goes on forever – and – oh my God – it’s full of holes!”
In case anyone is living under a rock and missed it (like me), sometime in August multiple kernel.org servers were rooted, and linux.com was also compromised in a related breach. Both sites are still offline. Not only does kernel.org host the Linux kernel source code (which has now been temporarily moved), but it also hosts mirrors for many Linux distros. It is claimed that “the attackers did not really understand the significance of the servers they’d breached and were unable to capitalize on the attack”, and that no tampering has been found in the kernel source code or distro mirrors. If true, call this very lucky, yet this is another example showing that Linux developers need to take file authentication protocols more seriously.
Earlier this year, I spent considerable time exposing and discussing Arch Linux’s long-term negligence in their distro’s security practices, which prompted me to discontinue my use of Arch Linux. It turns out that kernel.org hosts a primary Arch mirror, and were those files compromised, anyone using that mirror to update their system has been silently infected. (Note that the breach was not discovered by kernel.org for two weeks.) There are ongoing discussions of this on:
Reddit: Kernel.org (Arch’s main mirror) compromised
Arch Forum: kernel.org – Security Breach.
Additional info on the kernel.org breach:
I recently moved over to Aptosid, and after a few days of using it I think it’s going to be a keeper as a replacement for Arch. While it’s fresh in my mind, I thought I would share my experience of moving – from the perspective of someone who has used Arch Linux for a couple of years. I’ll give a little background, then a brief summary, then some real details on how I got some things to work.
I wanted to move from Arch Linux for these primary reasons:
- Lack of package signing and general concerns with the Arch dev’s lax security practices and attitudes (link1 link2 link3)
- Dislike for how the Arch devs regard their users and contributors
The reasons I was reluctant to give up Arch:
- Rolling release which I prefer over periodic large upgrades
- Package availability and the extended AUR user-contributed repository that makes installing most software very easy
- Ability to have a custom, lightweight, fast system without unnecessary baggage and with mostly vanilla software
My first distro was SUSE, which became a little too corporate, then Kubuntu, which I eventually found too heavily modded. When I moved to Arch, I dropped KDE and set up a minimal Openbox desktop with light, fast apps. My main system has a dual-core CPU and 2G memory, but I find running a light desktop with no swap file gives me a very responsive system that can keep up with my usual multitasking – it waits for me instead of me waiting for it. And my netbook of course runs better too. So I was shopping for a distro where I could set this up without having to remove too much.
I also gave FreeBSD and Gentoo a try, which you can read about here. FreeBSD had trouble supporting my hardware fully, and Gentoo required a lot of tweaking, and also had some security issues. I skipped testing Slackware for now because official packages seemed lacking, and I skipped Gnuffy because it inherits most of the problems of Arch. Then I tried Aptosid.
Aptosid, made by the same developers that created the popular distro Sidux, is a rolling release distro based on Debian’s unstable “sid” branch, with some hot-fixes and scripts added to make it more stable and ready-to-run. Being a Debian system, the user has access to the huge Debian package repos. And I like their attitude, as encapsulated in the Debian Social Contract: “We will be guided by the needs of our users and the free software community.”
Aptosid does not offer a minimal CLI-only install like Arch. There are various ways to install it – generally one of their live ISOs are used (KDE full or lite, XFCE, and coming soon LXDE). I went with their XFCE version: aptosid-2011-01-geras-xfce-amd64 ISO.
After using Arch for so long, the installer caught me by surprise – I felt pampered and spoiled. First, I was expecting a text installer, and instead it booted rapidly and flawlessly into a full and attractive XFCE desktop. There was immediately a feeling of quality – I’ve never seen a live CD boot so fast and flawlessly on my home-made hardware. The GUI installer was very simple with just a few options. The only thing I would change is that it didn’t allow me to select no grub install (I wanted to handle that myself). So I told it to install grub to one of my non-boot drives just to avoid overwriting my boot drive’s MBR. Other than that it was a breeze – not bad for a 435MB ISO!
I then booted into the installed system, which also booted fast and flawlessly, picking up all the hardware without a single miss. The included gdm login manager brought me into an XFCE desktop much like the live version. I was impressed and was definitely enjoying being spoiled like this. The desktop was definitely usable as it was, and I don’t say that about many distros – normally I rip out the carpeting and start remodeling immediately. XFCE was looking the best I’ve seen it, with nice fonts and colors. And the included apps were very sane and useful. Ice Weasel (Firefox) was already in there, and I was online without having to configure a thing. I actually had to stop and consider what I wanted to do next, because I wasn’t expecting to be this far for at least a day! I opened a terminal to see what was running…
Default install processes:
Not bad at all – nice and lightweight. The first bonus I found was that I had a great little XFCE system already running, from which to build my openbox setup. I figured once I had that running I could remove whatever I didn’t want. This meant that I had a working browser to research the install and any problems, configured terminal, editor, etc.
As I began working on the system’s internals, I definitely had the impression that this was something someone took some time to put together well. It had a refined quality to it. I also noticed attention to security details – lots of little and not-so-little settings and refinements that I wasn’t used to seeing in Arch’s default configurations. Debian packages are definitely put together carefully and well configured. At the same time Aptosid’s packages tend to be more vanilla and cutting edge than Debian proper.
Probably the biggest difference from Arch are the runlevels and init system. But I was used to this from Ubuntu, so I dug out my old notes, and I found that my experience with Arch put me in a good position to know what was happening and what to adjust to my liking. Most of it worked as is, and worked well.
Once I installed openbox (apt-get install openbox), I was immediately able to select openbox as my session and I was into the usual plain gray openbox desktop – nothing to it. Here’s what was running in the openbox session – even less:
Default Openbox session processes:
I then did a full upgrade. The devs recommend you always use apt-get directly. GUI apps like Synaptic can be used to search and explore the system, but they don’t handle Aptosid’s rolling release mechanisms. For a full system upgrade, they ask that you exit X and switch to runlevel 3 for the install. First I downloaded required packages while still in X:
apt-get update apt-get dist-upgrade -d # download but don't install yet
Then I exited X and:
init 3 apt-get dist-upgrade apt-get clean # and a reboot (or you can "init 5" to return to X)
Next I installed my printer, which is sometimes a hassle. Only things to resolve were getting the right 32 bit libraries for the driver and a little problem with scanning as a normal user – solutions for Debian on the Brother website worked. Then I installed the Nvidia proprietary driver – needed for the TV-Out on my card instead of nouveau.
With those working, I felt confident that I would be using Aptosid for good. I disabled gdm and set the system up to go straight into Openbox, and got into configuring it, turning off some unneeded daemons, etc. (details below).
Installing additional software is a breeze with apt-get, and the packages are PGP signed. I was happy to find that every single piece of software I wanted was in the repos, including a handful that had been in Arch’s AUR. And I carefully removed a few things, although I found the default XFCE components were small and reasonable, so I left a lot of it be – never hurts to have alternate apps available.
Moving my home folder from Arch left all my software configured – it all worked perfectly – no adjustments to the home folder were required.
When all was done, my system used 3.33GB, compared to 3.88GB on Arch, which surprised me. Same software plus the XFCE stuff I didn’t have on Arch came out smaller! Part of the explanation could be the fact that Aptosid offers split packages for libreOffice, so I only installed writer and calc.
The system has been running well for several days – thus far it is very stable and fast. In general I’m very impressed with how much I was able to accomplish with relatively little effort.
Like Arch, Aptosid is cutting edge, so occasional breakage is the norm. On my most recent dist upgrade the nvidia kernel source build gave an error, so I stuck with the previous kernel. This is a known issue having to do with Nvidia not keeping up, and the Aptosid devs recommended just using the prior kernel for the time being. Someone also posted an easy fix for the source, but I haven’t tried that. That is the only unresolved issue I have at this point. Looking at and using my desktop, I wouldn’t even know I changed distros.
The main difference is with Arch you install software and configure it, whereas with Aptosid the software is more carefully configured, but you may want to trim back some things. With the lighter components I used this was very minimal, and I actually appreciated using a configuration that had some work already put into it. Aptosid seems nicely positioned between the bare minimum of Arch and the overdone complexity of Ubuntu.
So based on a few days worth of experiences, I definitely am liking Aptosid, which I find to be an interesting mix of concepts. It’s rolling release and ‘unstable’, yet polished and refined, and quite stable for use (thus far, and from what I’ve read). It’s a small distro, yet can take advantage of the huge repos and issue support of Debian (many solutions to problems are on Debian forums, and I still use the Arch Wiki as well – much of the content is generic). And the packages seem to be sanely configured with an emphasis on security. Nice job Aptosid!
Below are my detailed and commented install notes, which show how I resolved a few problems and got things working the way I wanted.
In their latest issue, LWN.net, one of the definitive news sites providing comprehensive coverage of development, legal, commercial, and security issues related to Linux, published their article Arch Linux and (the lack of) Package Signing:
The Arch Linux user and developer community has been engulfed in sharply divisive debate recently over the issue of package signing. It started when an Arch user blogged about the distribution’s lack of package signatures, the security risk it created, and his own frustrations with the core developers’ response to the issue. The ensuing argument has since spread to include Arch’s development model and a variety of leadership questions, but the root problem remains unsolved: there is still no mechanism to verify the authenticity of “official” Arch Linux packages.
To blogger IgnorantGuru, this constitutes an unacceptable security risk. In February, he blogged about his concerns, noting that without a method for Arch users to verify that a package is unaltered, packages can be replaced with Trojan-horse-laden code.
The author, Nathan Willis, contacted me earlier this week to ask some questions, and I feel his article provides a very comprehensive review of the core issues, including the problems with Arch’s devs refusing contributions in this area and stalemating Arch’s security improvements for years. I think it’s great that LWN is reporting to their subscribers so candidly and giving this issue much needed visibility. The article concludes in part:
In the final analysis, Arch users are exposed to a security threat both by the distribution’s lack of package signing and by the core developer’s resistance to adopting it. However much the Arch “philosophy” says each user is responsible for his or her own system, IgnorantGuru is correct in his first blog post when he observes that without signatures, the distribution’s infrastructure is vulnerable to every exploit found in every other system on the path between the main project server and the user’s PC…
The ongoing discussion in the comments there is robust and also highlights some ways that Gentoo may still have vulnerabilities related to this (at least according to some), so I believe discussing these issues openly and without censorship is valuable.
Yesterday a reader dropped me a link to Gnuffy, which is an offshoot of Arch Linux started about three years ago. Looking over what has been accomplished with it thus far, I was very impressed with their ideas on expanding Arch (many already implemented), and given a few new ideas of my own.
At this point Gnuffy appears to consist of a package manager called Spaceman and some user repositories. Gnuffy can use any of Arch Linux’s repos in addition to its own, and can use the standard PKGBUILDs in addition to its own improved version of PKGBUILD, which includes some Gentoo-style USE flags and other enhancements. Packages on Gnuffy’s repos are GPG signed with the key of the packager, and Spaceman checks signatures. Nice work! It was a bit like suddenly being transported into the future of Arch.
It’s hard to tell the current status of Gnuffy by looking over the modest Wiki. From what I saw, the Wiki hasn’t been updated since 2010, and some of the links are broken, yet others work. I tried their IRC channel – didn’t find any of the devs there but one person on the channel told me the project was still relatively active – “it has always been a small project”. From how things look, maybe they got it to the point where it did what they wanted, so development on it has slowed. It looks like a handful of people built the wiki over the last three years, and Spaceman seems to be a pretty well-developed bash script at 9,000 lines.
Their main wiki page states:
The Gnuffy project declared its aim [in] creating a free, community based linux distribution where everyone who has time and motivation can have a share. This looks like a matter of course for linux distributions but experience shows that, the more the community grows, the more conflicts arise concerning the direction which will be taken in the future – and now; and only a few people get the right to decide something. With Gnuffy we want to build a distribution without (with as little as possible) hierarchic structures.
Gee, why does that scenario sound familiar? It seems these guys must have run into the ‘Brick Arch’. Reading this, I also had a light bulb which has so far been dim, light up. I could never understand Arch dev Allan McRae’s reluctancy to just signing the Arch package database – he really threw all of himself against any attempt to get this implemented. Now the puzzle piece fits – fear of competition. With other pacman variants floating around, I think he knows that if the database is signed, they’ll fly by pacman in terms of features and security. Just a theory, but I’ll bet it’s right. And it would fit in with the Arch lack of care for users – he would rather risk users security than have people abandon HIS project.
Either way, this also got me thinking how Arch is an unusual distro. It’s not like it has a customized DM or much that glues it together. Mostly it is a package manager (and build system) and a few repos. The packages in Arch are little less than tarballs of files to be copied. Creating a spin-off of Arch is a matter of creating a package manager, which is exactly what Gnuffy has done. So it makes sense that the core Arch team might be a little insecure about this state of affairs, but it’s fair play in Linux. This also might explain why their forums are in a such a panic over any dissent – the forum is one of the only real influences they have on the user community, since the software is mostly vanilla and made by other developers outside Arch.
What is hard to duplicate in Arch is of course the great work the dev team puts into making the PKGBUILDs (which build the binary packages). Being rolling release, they have to wrestle with multiple library versions, etc. to keep it all running together smoothly – no small task. Arch isn’t just somewhat high maintenance from the users perspective, but for the devs as well (is this a drawback in terms of its viability long-term?) So duplicating Arch is hard. But extending on it, if you use their core repos, is very feasible. In a sense Arch’s AUR does this as well. The proof of this is that you don’t even need to install Gnuffy separately – they have a script called Arch2Gnuffy that converts your Arch system to a Gnuffy system!
Gnuffy has other smart ideas. A bash package manager is very open – you can fix and modify it easily for your own purposes. Including GPG signatures in the repos is also ahead of mainstream Arch. The fact that Gnuffy depends on Arch’s repos is still a security weak point, as the Arch packages are not signed.
I noticed that Spaceman includes an up-to-date (as of today) package list which contains ALL Arch package names (from core repos, Gnuffy, AUR, etc), md5sums, and dependencies. It wouldn’t be a huge step for them to include sha256sums, then sign the database. Assuming they calculated the sums from a statistically verified mirror (using paccheck or similar), this would give their users a way to verify the authenicity of even Arch’s packages. They’re already about one step away from having a much more secure Arch distro than Arch mainstream.
Anyway, my introduction to Gnuffy has opened up many ideas for how Arch can be extended, using mainstream Arch in a way similar to the way Ubuntu uses Debian – as a starting point, but with much less to change. I’m definitely going to look more into Gnuffy, and hopefully get in touch with the maintainers. This has also piqued my interest in what the other Arch-derived distros are up to.
You can check out the Gnuffy Wiki and their IRC channel is #gnuffy on Freenode. If anyone tries or has already tried Gnuffy, I’d love to hear your thoughts on it.
In answer to some questions about possible Arch replacements, here is what I’ve been up to.
I’ve been gradually experimenting with both FreeBSD and Gentoo. I have some extra partitions I use to test new setups, so I can take my time and always boot back into my primary partition when I’ve had enough. I highly recommend this approach, especially with distros like these.
FreeBSD is pretty slick package-wise – can install from source (ports) or packages. Reminds me of Arch in many ways, and was one of the inspirations for Arch’s design. But it isn’t Linux, even though it can run most Linux software – there are some differences, particularly the filesystems. But nothing huge and it’s well documented. It’s still a candidate for me. I got X, Openbox, and Firefox running without much trouble. I am next getting ready to try my printer with it, which is non-trivial.
Gentoo is also Arch-like, but seems to require a little more finesse. Because everything is built from source, you have to set ‘USE flags’ which tell it what you do and do not want/have on your system. It’s a little confusing determining what USE flags to use, but you pick it up as you go. The handbook resembles the Arch wiki, although it’s more out of date in some places. Mostly I have been very successful thus far – I got X, Openbox and Firefox running in about a day without any major hassles. Security seems very good and they have regular updates. Everything compiles from source, so it takes more time, but since I run a light Openbox desktop, it wasn’t bad. X and Openbox downloaded and compiled in under 10 minutes each, and Firefox (known as one of the larger builds) took about 20 minutes (including download on my connection, which isn’t blazing fast).
The biggest challenge for me is usually my Brother laser printer/scanner, which uses a binary blob in the driver. It’s also a 32 bit blob, and I run 64 bit. Still working on that when I have the time free. Gentoo won’t run it at present – I think I’ll need to try their forums to get a solution. I think it’s doable.
Other distros that interest me but which I haven’t tried yet include:
Slackware – Not as up to date as Arch, but is supposed to be quite vanilla and stable – Linux the old-fashioned way. Has many devoted fans. KDE by default, but you can do a minimal install and put on what you want. If you don’t need bleeding edge and don’t mind compiling some things from source (their repos aren’t as thorough), I think this has good potential to Arch users, who will know how to handle it under the hood.
Aptosid – Debian’s bleeding-edge, which is supposed to be quite stable. Packages are also supposed to be more vanilla than Debian/Ubuntu (where they mod and usually break things), but there are still some mods. Looks promising though – one Arch user told me I would love it but miss the AUR.
All of these are rolling release (except Slackware), can be minimal, and have good security protocols. Of course every distro has its plusses and minuses. Arch’s package system + AUR is very convenient – the devs put a lot of work into making it rolling release and fairly stable, dealing with the library versions, etc, so we don’t have to. Except for some of the Arch-derived distros (some of which use pacman or a modified version of pacman), I don’t think you’ll find anything just like Arch in that area. But Gentoo has advantages too. You build your own kernel in Gentoo (pretty easy), so that opens up promising opportunities. I like what I see, and if I can get my printer happy, I think it could grow on me. I’ve learned a lot from Gentoo already that I never learned on Arch – the setup procedure is a neat experience. FreeBSD also has advantages – I think the kernel is more secure as is the system overall, lots of software available as both source and binary, and BSD is a new world to explore. It’s growing in the desktop area.
There’s nothing like experimenting and trying a few of these out for yourself, even if you don’t stick with them. More to come…
UPDATE 2: My Move From Arch To Aptosid
(Also, for those interested, I contributed a brief review of Arch Linux to LinuxQuestions.)
I am reprinting my recent post on the Arch Linux forums below so this is accessible and searchable – one value of having your own blog. One of the forum moderators (jasonwryan?) imposed an 8 week ban on me for “Trolling despite repeated warnings” for the post below, so I am not welcome there until May. (I don’t recall any Warnings, but apparently my memory is faulty?) Granted I wasn’t saying what they like to hear, but given the number of users’ threads and questions on this subject that they’re deleting, I think it needed to be addressed. At any rate, I cannot update or respond to the paccheck or other threads there, but you may bring any issues to my attention here or via email. They have also banned my IP from even viewing the forum – I guess that is a danger – so even though that’s easy to work around, don’t assume I’m reading there, as I probably won’t be automatically notified of new posts in threads.
My ’8 week ban’ post follows:
Allan wrote somewhere (you must be logged in):
I will repeat my offer. If anyone provides patches for the remaining issues with pacman as given on this page: https://wiki.archlinux.org/index.php/Us … ge_Signing , then I will get all the patches in a format suitable for actual merging to the pacman code base. I made this offer several weeks ago on pacman-dev and quite a few people said they had patches that were “almost ready”. As usual, none ever eventuated…
Now as to whether this is really important… well, it is… but:
1) the described ARP attacks require the hacker be on your network. That is not a particularly practical attack for most Arch usages (home computer…).
2) exploited mirrors are likely to be detected quickly. Even faster now paccheck has been provided. But they would have been detected by people who segment their downloads across mirrors anyway (or even downloaded packages from a different mirror than their database) and there are a lot of people who did that.
3) if it was that important, people would have the motivation to actually code on it…
The quickest way (in fact, probably the only way) to get this fixed is to provide the patches for pacman. Having the feature implemented there will likely increase the motivation to get signing used in the repos.
I would like to reply to Allan’s third point and his alleged invitation.
I attempted to contribute a very effective interim solution. I submitted two flysprays that could hugely improve Arch’s security in this area with virtually no work needing to be done. It turns out that one of these ideas – to have the server automatically sign the database – was submitted by one of their own developers 3 years ago (a virtual eternity in the world of computers). It was shot down at that time because pacman package signing was ‘almost complete’. He is still an Arch developer and offered to implement it immediately when he saw my request, but there is no one willing to authorize the simple change required. With the use of a simple signature checking script which I offered to write, this change would make 150+ mirrors as secure as the primary Arch server. The other idea – to include SHA256 sums in the database – would make paccheck’s job more thorough without the need for full mirror compare. I even provided a simple patch for their script. Yet they simply refuse to include it for no known reason. You can see and vote on these here and here. They are very effective interim solutions which will improve your security substantially while the pacman devs wrestle with their full-blown package signing (for how many more years no one knows).
As for coding pacman, my discussion with the devs revealed that at least some are disgruntled with Allan’s handling of the code they submit, in that it never sees the light of day. It is discouraging to put work into something only to have that work disregarded. I myself would consider working on this, but I have to believe that Allan (or whomever) would simply find an excuse to dismiss whatever I submit, just like Allan seems to do with every idea and patch submitted in this area, despite his claims and invitations to the contrary. Arch is unapproachable in this area – why?
So Allan’s endlessly repeated claim that there is just insufficient manpower to immediately close this security hole is simply false – signing the database would close much of the problem, and I have offered to adjust paccheck to make use of such a signature. Adding this signature is trivial and there is a developer willing to make that change. It is simply being blocked by a bureaucracy – Arch is not maturing well. It is run more like a closely guarded personal pet project than a community-supported project. His claim that no one is willing to contribute is false.
From what I can tell, Allan is the main stopping point for why this has gone nowhere for YEARS. He claims he doesn’t care about it, but aggressively campaigns against any improvement to Arch’s security in this area, no matter how trivial. I can’t even have a conversation about it with the other devs without him butting in and aggressively derailing it. I can’t explain the reason for this behavior, and believe what you will, but Allan’s claims are largely false. I can easily see why the developers are discouraged and have stopped attempting to contribute to Arch (which is actually a larger issue affecting Arch in general – I can’t imagine why.)
As for being lucky in spotting a compromised mirror among over 150 mirrors before someone is affected, good luck with that.
In case you think this is all theory, here is a real life example of a compromised Linux mirror, which wasn’t discovered for almost one year.
As for the behavior on this forum of hiding this information from users, I think it is very poor practice. If you deem it necessary to close some of these threads, so be it. But why are you moving them off the main boards into the dustbin? Obviously it’s embarrassing to the Arch devs, but users have a right to be made aware of this issue so they can evaluate how it affects them. And you might consider that the reason the issue keeps coming up is that people want to discuss it. At any rate, anyone is welcome to discuss it on my blog – I don’t delete non-spam comments, even when people call me names and later apologize. The discussion there evolved quite well and eventually quieted down, when everyone had had their say. A novel concept to you perhaps, but intelligent discourse has its advantages. As the Arch devs are abandoning the users in this area, it would be helpful for users to discuss the ramifications and makeshift solutions. Compare this forum’s behavior with the ArchBang forum, where a similar thread was made a sticky.
Perhaps it would be best to make the trollbin/dustbin open for posting if you can’t tolerate discussion about Arch in the Arch Discussion forum.
Also, I would encourage Arch users to find another forum for discussing this openly – don’t limit yourself to this forum. LinuxQuestions, Archbang forum, etc. – there are many out there, some already with discussions about it (search for “Arch’s Dirty Little Not-So Secret”, as that article was picked up by Linux Today and resulted in a lot of discussion about Arch elsewhere). Arch Forums is indeed free to run their forums however they please, even to the point where it inhibits Arch’s development and growth, and since they don’t seem to respond functionally to any feedback on their practices, it may be best to abandon it for more helpful and honest forums. Regardless of your take on this issue, it is hard to argue that users shouldn’t evaluate it for themselves.
A few links:
Anandtech Forum: Critical Security Flaw in Arch
Reddit: Arch’s Dirty Little Not-So-Secret
Kubuntu Forums: Arch’s Dirty Little Not-So-Secret (started by me but others’ opinions there as well)
Arch Dustbin: 0wning Arch: Why Package Signing Is Important (no, I am not the author of that thread, despite Misfit’s allegations – perhaps the intelligence of the post fooled you, but you would do well not to make unfounded statements about my posting under false names – I have no need to do so) [reprint]
and more – lots of places to discuss this and anything else about Arch forbidden here.
UPDATE: My Move From Arch To Aptosid