I recently tried out OpenBSD as a possible answer to recent Linux engineering. I thought I’d share my notes here on my results, from a beginner’s and Linux user’s perspective. (I tried FreeBSD briefly before as well.) If you’ve used OpenBSD more extensively on the desktop, your feedback on any of this is welcome too – I’d like to know what you think of my opinions, you being a longer-term user.
OpenBSD is a bit of a leap from Linux – not everything will be familiar, but it is UNIX-style, so some things feel the same. It was my thought that if OpenBSD desktop is ready, it might be worth the investment to go there directly, rather than fighting systemd and such in Linux distros. I’ve liked what I read about some of OpenBSD’s approaches to security. They ship a very simple, locked down, code-reviewed system, to which you add components. They don’t use SELinux or other similar technologies (which I think is wise), so they take a simpler approach. Compared to FreeBSD, which seems to be more open to systemd (you can see FreeBSD lead developers acclimating their users to systemd already, and trying to turn it too into a mobile thing), OpenBSD seems to be rejecting it thus far.
If you’re fairly familiar with setting up Linux systems, you can try out OpenBSD in a day, including reading some docs. The FAQ is a good place to start – seems to be their install manual. While OpenBSD is well-known for being meticulously documented, I find introductory documentation and explanation lacking. Simply put, it’s a bit difficult to figure out what the hell they’re talking about at times, because they make so many assumptions. There’s also a horrible lack of hits on Google for questions/problems compared to Linux. With the forums rumored to be intolerant of entry-level quesions, I suspect you’ll be largely on your own. Getting a decent book on OpenBSD is probably a good idea if you plan to use it seriously.
Yet the install is fairly simple. The boot CD just asks a few questions, and to most you can press Enter for the default. The tricky part is partitioning. The OpenBSD partition is split into slices with something called disklabel. So they basically use partitions within partitions. On my first install, when I told it not to use the whole disk, but to let me edit the MBR (partition table), it ran fdisk. I set a 10G partition to type A6 (OpenBSD), set the boot flag, and updated the MBR. So far so good.
Next it layed out the disklabel setup for that partition, breaking the partition into 5 or 6 slices with mount points (/, /tmp, /usr, etc). But later when I tried to install a few X apps, I ran out of space in /usr. Clearly their default partitioning for a smaller space is not well done. So I did the installation over, and chose a custom layout. It put me into disklabel, where I deleted all the slices except the root filesystem (/). (Also be careful not to delete ALL the slices, because some seem to refer to other partitions on the drive – just delete the ones with mount points.) Saving changes, it continued with the installation okay. This way the whole root filesystem is in one slice. It’s okay to do this (slightly less secure as they explain in the FAQ), and later you can repartition if you know how you want the space shared.
So basically the partitioning requires a little adjustment and reading, and use of fdisk and disklabel. They could improve this with a few simple typical setups – how many variations are there really for most users? Either you do a whole disk install, or just want it on a smaller partition. Also, I updated the MBR boot code in fdisk, making the system boot directly into OpenBSD, but you can also tell grub to boot a BSD partition.
Next it boots into an xdm login (if you told it to boot into X in the install). I pressed Ctrl-Alt-F1 to get a root prompt, create a user, and add some software.
The package manager is easy and simple, and they recommend using packages (versus ports, which create packages from source, similar to gentoo or Arch). However, they have an odd release method, which I’m not sure works well, and which their FAQ explains poorly.
The ‘release’ branch is what they release every six months, and is never updated otherwise. It quickly accumulates security advisories. These are corrected in a ‘stable’ repo. But the ‘stable’ repo is only available as source (ports), not binary packages. People generally recommend that you start with ‘release’ and manually patch bugs as needed. They claim you learn the system better doing this.
So there’s no packages branch comparable to Debian’s stable, where security fixes are added. That is clearly something missing, as evidenced by the fact that a third party now offers pre-built packages for the ‘stable’ branch. The ‘release’ branch is already open to a serious Xorg bug that lets a normal user run arbitrary code as root (Red Hat is doing a great job – and notice how OpenBSD too is susceptible to their ‘bugs’ through Xorg). So you pretty much need to run a manually patched ‘release’ branch, staying attuned to security notices, or run the full ‘stable’, building everything from source (or third party packages).
There’s also a ‘current’ branch, and this is rolling release. It’s packaged in binary ‘snapshots’, similar to Debian unstable. But I didn’t immediately see any instructions on how to switch to using ‘current’ – there seem to be a few manual changes required. Some people do say they use ‘current’, but it’s also considered a more advanced use. You also have to update the whole system, you can’t just update pieces and expect it to work. So using ‘current’ looks more maintenance intensive as well, and may require more experience.
The update/upgrade path seems primitive too – more manual steps required. Generally it all seems geared to servers that want stability while being able to patch minimally.
All of that said, the package/ports system does seem clean and simple, as does OpenBSD overall. Longer-term users seem to like their ability to maintain their system, so I suspect once you get used to it, it works well. It may require more knowledge, but it also doesn’t change much. Overall I’d say it looks usable.
So I installed some packages:
pkg_add openbox dillo geany nano roxterm geeqie gnash gimp \ libreoffice vlc mpv imagemagick htop jhead smplayer file-roller \ gnash claws-mail filezilla pdnsd bash pcmanfm firefox xchat
A few things I couldn’t find in their packages: deluge, gftp, flashplugin-nonfree, and spacefm
Adobe Flash is pretty much unavailable, unless maybe you get into some i386 linux emulation for it. Hard to find answers on how *BSD users handle this, but the preferred methods seem to be to use programs that download videos so you can play them in mplayer, or to use HTML5 on Youtube (see Firefox’s ‘All HTML5’ plugin). Yet while HTML5 works for me in Linux, it just showed a black box in Firefox on OpenBSD. Nor would Gnash work – it locked up Firefox with network errors in stderr. So in my brief attempts I didn’t find any in-browser support for Flash sites.
I also found that Firefox ran more slowly, and programs seemed to start slowly. Overall the system didn’t seem fast. This seems to be a known issue of OpenBSD on the desktop (some attribute it to scheduling).
Another issue I encountered was my laptop hard drive powering down every 1 or 2 seconds. Linux had this problem too, but there is no hdparm or sdparm for *BSD. The closest I found was atactl, and I eventually solved the problem like this:
atactl sd0 apmset 253 # use 127 to 253 for no standby
I didn’t actually try openbox, I just logged into a plain X session and started some programs from xterm. PCManFM did run, but did not show any devices. After inserting a USB stick to try playing a movie in mpv, I realized I didn’t know how to mount the USB stick, or even what its device name would be. So I never got to try that.
As far as a possible port of SpaceFM to *BSD someday, it looks promising. SpaceFM depends on only glib, gtk, and udev (and inotify in the kernel, but I did see gamin on OpenBSD, and SpaceFM can use gamin instead of inotify already). udev code would have to be removed from the build, and there is no HAL either. To show and detect device changes, it might need to do some polling for something like sysfs, not sure. But with SpaceFM’s Device Handlers and overall design, I think it would make an excellent conversion to a BSD file manager. Also, people were saying there is no Brasero, so what will they use to burn, but SpaceFM can be used as a burning app. That and other automation, as well as its few dependencies, makes it a good candidate for a *BSD port.
Hardware seemed to be detected well in OpenBSD – and it has a good reputation for this, in some cases better than FreeBSD. My ATI video seemed okay and required no initial tweaking, though I didn’t see it play any video. (Nvidia is less supported on BSD, from what I read. That’s seems true on Linux too.)
Overall, OpenBSD looks like it’s usable for my purposes, minimally. It doesn’t seem quite ready for full-featured desktop use unless you’re willing to keep things very simple, have more limited web, and limited software choices (but still quite a few – you’ll have a lot of Linux there with you). I also have some speed concerns, but the laptop I tried it on isn’t very fast.
OpenBSD reminds of some of the earlier versions of Linux I tried a few decades ago, before it really became Ubuntu-easy to install and maintain. It’s also similar to Arch Linux, yet with less software and less information available.
I read that many of the OpenBSD developers actually use other OSes for their desktop – even among them it’s not the most popular desktop OS. If true, that also means they don’t optimize it for that (because they simply won’t encounter the issues). Plus it is designed for servers.
I also tried FreeBSD some time ago, and that is similar. My impressions are that somewhat more software is available for FreeBSD, there are more Linux-like forums for discussion, there is more on Google when you have a problem. I think more people are using FreeBSD on the desktop. However, FreeBSD developers also seem to be more accepting of Red Hat’s engineering, Adobe Flash (a security nightmare we’re all better off without, except that they have made it hard to avoid), complex and poorly reviewed things like SELinux, and other questionable choices. OpenBSD on the other hand seems to avoid the Red Hat camp actively and wisely.
Having given OpenBSD that initial try, I have decided that it’s still a candidate, but that it seems a little too primitive on the desktop yet, and that I would be giving up quite a bit without getting much in return, in terms of my needs. It also means learning new BSD filesystem tools, backup tools, porting my file manager, and other differences between BSD and Linux.
So now I’m thinking that a good systemd-free Linux distro may be the more usable and convenient route for now, maybe keeping an eye on OpenBSD development for longer-term. I think my next stop is going to be Gentoo. I tried Gentoo a few years ago, and I liked it overall. The USE flags setup can be a bit much for the newcomer (I wish they would choose some reasonable defaults). I also had a problem with momentary hangs of the whole system, which is really annoying. This appeared to be a possible scheduling issue. Hopefully that won’t recur. I also had problems with my Brother laser printer driver, but I see they have some new ‘overlays’ for similar printers, so maybe that will be improved. (I’ve decided not to make the printer a critical issue.)
I liked what I saw of the Gentoo community in response to systemd, with eudev, etc. They seem to have many genuine contributors, flexibility, and a policy that allows it, so I think that will be a boon in countering some of the upcoming power plays in Linux.
While BSD looks promising, there is a lot of software and work that has gone into Linux, and it seems unfair to have to dump it all just because of things like systemd. Maybe with something like Gentoo’s flexibility it will be possible to move it forward on another track. Gentoo also has good security protocols, so I look forward to trying it out again.
If you’re looking for systemd-free Linux distros, there’s a large list at Without systemd.
UPDATE: Speaking with a few OpenBSD people in email, I can clarify a few things which I didn’t find to be clear in the FAQ. In OpenBSD, the OS is not part of the ports or packages systems, unlike in Gentoo or Arch, for example. The OS is built separately from a CVS tree, manually. Or patched manually. Or, you install or reinstall the system using the install ISO (or manually extract the files). That is also how you switch from release to current – you must reinstall. Software is updated via ports (like Gentoo) or packages (like Arch).
Also, OpenBSD was not as vulnerable to the Xorg bug I mentioned because it doesn’t run Xorg as root! In fact it runs it with even less privs than a normal user. Great work there!
And, according to one person who seemed to know, OpenBSD developers are commited to using OpenBSD on their own desktops, because they want to improve it. FreeBSD is where they tend to not use it as much on their own computers. That’s encouraging to hear.
Overall, I probably gave a more negative impression of OpenBSD than I intended. In general it looks good in many ways, even on the desktop. Probably comparable to Arch or Gentoo in terms of setup and maintenance challenges. I’m still weighing it, and I think it’s worth getting to know.
As a rat who will be among the first to flee any sinking ship, my whiskers are twitching at the prospect of staying aboard Linux. Despite all the fine efforts some people are making to stay in a systemd-free parallel universe, there seem to be changes coming to the kernel from the same folks that brought us systemd, and these changes are symbiotic.
With the same political-like moves used to push systemd into most major distros in record time, kdbus (a kernel-based implementation of dbus) was recently dug out of its grave, propped up to make it look half-alive, and is being pushed into the kernel whether it fits or not. When Linus said a week or two ago, “Now this looks like a big oversight, and serious” in politely talking about one of kdbus’s ridiculous approaches to security, one wonders whether he was prophesying about the fate of Linux and kdbus in general. This Gentoo forum thread is a good read for catching up on the sensationalized push to put kdbus into the kernel the last few weeks, it’s relationship to systemd (Red Hat of course), and some of the history on this.
I think with kdbus and systemd installed, you will have a completely bugged system, from the inside out, kill switch included. That’s just a hunch, mind you, but what else are smartphones good for? Coming soon, if Red Hat doesn’t like your program, it won’t run on Linux – only approved apps are ‘safe’. I think they simply told Linus, “kdbus goes in now, like it or not”. One person can’t stop all of the pressures involved, so don’t expect him to. Instead, we have to know when to jump ship. Especially if Linus retires soon and hands the kernel over to a Red Hat developer, run-don’t-walk for the door.
As for BSDs, you can see FreeBSD lead developers already acclimating their users to systemd, and trying to turn BSD too into a mobile phone kinda thing. Even master Linux-slayer Lennart Poettering gave it his official ‘okie dokie’.
Of course, the heretofore-known-for-stability Debian recently released Jessie featuring systemd. I’m definitely in the crowd taking the road less traveled on this one. I think this is a time for conservative changes, hanging back, sniffing the air, even if you just prefer huge amounts of new code running as PID 1 to be better tested, or if you don’t care for Red Hat overwriting your boot firmware and blacklisting manufacturers who don’t play ball. Linux is being redesigned, eaten alive really, so at some point it’s no longer what it was. Its course of development is not based on the same principles, even if the GUI looks the same for now. Knowing how entrenched things get, I think this is the time to take a new direction, even if that direction is regression.
Even if you don’t mind that NSA toy Red Hat single-handedly controls xorg, udev, etc. (the list is long), the new systemd that rocketed to fame and widespread adoption overnight, and now the large, complex, new and wildly non-secure-on-principle kdbus kernel patch being slipped in to complement it, you may see some other potential problems with this picture.
I don’t think long-term planning is possible for Linux anymore, because one thing about the crowd that develops systemd and kdbus is for sure: they break things and make unpredictable changes without consulting anyone. It’s not Grandpa’s style of cooperative Linux development anymore. It’s their OS and you’re just a user. Overall I think the only reasonable long-term plan for Linux is to plan for, wait for, or create something else.
Yet for the short-term, in addition to Devuan‘s plans to fork Debian soon (some pre-alpha ISOs already), there are some distros that are staying systemd-free already, and I think this is about the best you can do in Linux for now. Here’s a list (thanks to everyone who brought these to my attention):
Several systemd-free Distros
- Alpine Linux
- antiX (based on Debian)
- Calculate Linux
- Entropy GNU/Linux (formerly Less Systemd GNU/Linux)
- Gentoo (ready options exist)
- Manjaro (see OpenRC options)
- Puppy Linux
- Void Linux
For more see without-systemd.org.
runwiththedolphin has produced a new screencast showcasing SpaceFM 0.9 on antiX 13.1 Stable. A very positive review of SpaceFM, it’s a nice walkthrough that shows some of the oft-overlooked features, new destkop and file browser features, and shows some tips on using plugins and networks.
Speaking of networks, OmegaPhil and I are wrapping up work on new very flexible handlers in SpaceFM for archives, devices, and protocols. The functionality came together nicely and will give SpaceFM some extraordinary flexbility and ootb intelligence for using fuse and other filesystems. This isn’t quite available, probably a few more weeks, but look for anouncements to help test and contribute default handlers.
From The Sporkbox Blog, a review of the dangers of software evangelism and how it applies to the current situation with systemd adoption, with some devel mailing list quotes.
In May 2011 Lennart Poettering proposed systemd as a dependency for further releases of GNOME. As systemd is available only on Linux, the proposal led to the discussion of possibly dropping support for other platforms in future GNOME releases. While some people responded to the proposal with criticism others suggested the idea of a GNOME Operating System on top of the Linux kernel.
Basically this comes down to: Are Linux users going to allow corporations to take over their OS and change it in unfriendly ways? Because that’s what’s happening.
One of my concerns on this is how poorly these developers maintain these projects. I just came across an easily reproduced GTK3 bug affecting SpaceFM which was reported almost a year ago – with no response yet. That’s one thing you can look forward to when these corporate developers control everything: Microsoft-quality responsiveness and attention to detail.
Since SpaceFM is entering the GTK3 realm (SpaceFM can now be built on anything from GTK 2.18 “I won’t give up my lenny!” thru GTK 3.6.x), I’m starting to hear more feedback about GTK3 and experiencing a few things for myself. While SpaceFM’s GTK3 port has been running very well with the few non-broken themes I could find, there are some intrinsic problems with any GTK3 app due to GTK’s poor maintenance, as well as a growing culture of enforced conformity from GNOME devs. Some of the things you’re about to read should make your hair curl and your blood boil.
On the surface of it, it seems that with every minor update to GTK3, themes get broken. I experienced this myself trying find a GTK3 theme that worked well with SpaceFM – most of the themes are broken in GTK 3.4 thru 3.6 (you can see the warnings when running SpaceFM in a terminal, and functions will be broken in the app). Thus the better-maintained themes (such as Clearlooks-Phenix and DarkMint) will have different versions for every minor version of GTK. The less well-maintained ones will simply remain broken.
Theme development is a tedious and difficult task, and for the GTK devs to be so careless in breaking their API at every turn disrespects the many hours people put into making themes for it. Yet as I read some of the GNOME developer comments below, I was given to believe that this breakage stems from a Microsoft-like climate of preventing users from customizing their systems, and deliberately breaking the work of others so that your ‘brand’ is the best. Anytime I hear the word ‘brand’ being used in Linux, I know something valuable is being poisoned. Just as a sample of what is to come, GNOME dev Allan Day writes:
I’m particularly surprised by the inclusion of themes. It seems bizarre…
Oh it’s bizarre alright!
I have never gotten into the KDE vs GNOME debates, so this is not GNOME bashing, nor, as you’ll soon see, are these systemic development problems limited to GNOME. Yet what I’m hearing is that with GNOME v3 the goal is to promote their “brand” and make it dominant, in part by greatly limiting what users can change on their own systems, and partly by breaking or simply removing whatever support they’re no longer promoting as ‘The Way’. The reach of this selfish and narrow-sighted development goes beyond GNOME and affects GTK apps in general.
In the rush for Linux to become ‘popular’ and ‘make it into the desktop market’, maybe there is an unintended consequence. Not only are Windows users moving to Linux, but Windows devs seem to be arriving as well, bringing their diseases with them – corporate ‘kill off the competition’ mentalities that don’t serve Linux, merely exploit it.
What follows is a sampling of quotes from various places and assorted devs which paint a picture of a growing culture of anti-user, conformist philosophies. There’s a bit of text to review here, but I think it’s worth it to hear what GNOME devs have to say about their intentions and goals, in their own words, and what others are saying about that!
Editor’s Note: All emphases below are added.
To start us off, Clem, a member of the Linux Mint dev team, writes:
I’ll apologize in advance for the sarcasm here.. I need to take another cheap shot at the
GTKGnome developers here. GTK3 isn’t a reliable API. Maybe it should be called libgnome instead. GTK3.4 came with Gnome3.4, and wasn’t compatible with previous GTK3 themes. This means all GTK3 applications looked really ugly not only with all the GTK2 themes which don’t support GTK3 (almost all of them), but also the few which did. With this in mind we had three options:
- Give you a desktop with poor integration and applications which look different based on the API they use (which is completely unacceptable)
- Ditch all GTK3 applications from Mint and replace them with earlier GTK2 versions, or GTK2 or QT applications (this includes Gnome apps, but also Gdebi, Transmission and a few others)
- Rant like mad, remove all themes, and waste countless hours in giving Mint-X and Mint-Z proper GTK “3.4″ support even though it’s likely to break again in 3.6…
We went for option 3 “this time”. I hope this little example was enough to convince 3rd party developers not to use GTK3. I couldn’t find any release notes or documentation explaining the regression or how to solve the issue.. I genuinely get the feeling that GTK 3.4 is developed for Gnome 3.4, that it doesn’t really matter if it breaks things and that we’re not supposed to use it outside of Gnome.
Received via my email, a long-time SpaceFM user and contributor writes:
SpaceFM Dialog features will allow me to get rid of zenity. I’m no longer interested in zenity because with Gnome 3 updates, it lost some features, and I had scripts not working as they should. I didn’t understand why. Even the zenity docs were not updated about removed features. I had to search in bug reports to find that developers removed some features that were no longer considered useful with the new Gnome Shell paradigms. Wow. So devs think that zenity is Gnome Shell only? It can’t be used in other environments? I was very frustrated.
This situation was very common during Gnome 3 updates. Lots of removed features, no dev communication, no consideration for users, etc. I was using Gnome for years, but with Gnome 3, devs have gone too far and I didn’t want to be treated this way as a user and an active bug reporter. It was clear to me that I would never use Gnome again.
I really don’t like the turn that takes the development of free software. When I discovered free software about 2004, GNU/Linux was a way to use our computers ethically, the way we wanted and on the hardware we wanted. Now, there’s clearly an adoption of a very closed-source way of functioning, more and more disconnected from users and obsessed with brand control.
Received via my email, the developer of a popular GTK3 theme writes:
I have a lot of messages from users saying that my [REDACTED] theme makes Gnome more usable again. But it’s such a pain to develop a GTK 3 theme. It’s always broken. I have a version of my theme for GTK 3.2, one for GTK 3.4, one for GTK 3.6. I’m so tired of that. For GTK 3.4, it was so broken that I had to code it again from the beginning. Days and days of wasted time and frustration. And almost no documentation. A lot of trial and error. Developing a GTK 3 theme is not fun at all, it’s just very frustrating. This morning, I received a message from a user that tested my theme with GTK 3.6.1 (I developed the GTK 3.6 branch of my theme on GTK 3.6.0) and I can see a lot of bug rendering in his screenshot. Is it really just because of a minor version difference (3.6.0/3.6.1)? Sometimes I wonder why I’m still using GTK.
There are many such comments. For example, GTK3 theme developer half-left writes:
I’m sorry to say this but I am abandoning any GTK3 theme making from now on. Upstream is impossible to work with and GNOME 3 has become a complete mess in regard to third party theme making. As if GNOME Shell isn’t bad enough sometimes with every version being broken, GTK3 is even worse. For those of you who wish to make GTK3 in the future, good luck, you’ll need it.
Honestly, Windows and OS X actually look more attractive to me right now.
I’m not leaving dA, just pondering what customisation to do next.
The developer of the popular Swar themes writes:
The problem therein is why should we as supporters of Gnome who gave our time for free get slapped in the face with new theme requirements and our work broken and failing to do more work at out own time to support something where the requirements could change again in another 6 months or less and again break our new work? It’s a real pickle no doubts there!
This would be a continuing ‘rat-race’ to keep up and for myself I am running my own business and am also a step-in manager of a business for the full-time managers so I can not devote months on months to develop themes.
How can anyone remain interested in a system developed by devs who don’t care about their users? Do you know what GNOME devs think about themes and extensions?
In the following discussion, someone suggested creating a website for Gnome Shell extensions and themes. Someone else said that he was already working on such a project. Below are some tasty answers from Gnome Shell devs, considering users only as walking billboards. From Gnome 3 Extensions/Themes Website?:
Allan Day wrote:
I knew this was on the cards but I have to say that I am surprised that it is actually being pursued in this form.
Facilitating the unrestricted use of extensions and themes by end users seems contrary to the central tenets of the GNOME 3 design. We’ve fought long and hard to give GNOME 3 a consistent visual appearance, to make it synonymous with a single user experience and to ensure that that experience is of a consistently high quality. A general purpose extensions and themes distribution system seems to threaten much of that.
I’m particularly surprised by the inclusion of themes. It seems bizarre that we specifically designed the GNOME 3 control center not to include theme installation/selection and then to reintroduce that very same functionality via extensions.
So, I would very much like to hear about how this web site will relate to our core design goals.
Allan Day wrote:
One particular issue is the ability for users to modify the top bar via extensions. This part of the UI is vital for giving GNOME 3 a distinctive visual appearance. If we do have extensions, I would very much like to see the top bar made out of bounds for extension writers, therefore. We have to have at least *something* that remains consistent.
Allan Day wrote:
> Milan Bouchet-Valat wrote:
> I think the main reference here is the way Firefox manages
> extensions. Many people use stock Firefox, and it works very well,
> but many others like to play with appearance (personas, equivalent to
> our themes), or need a specific feature (extensions, in both
> terminologies). This example is quite positive. The fact that people
> can easily extend their desktop encourages them to support it and
> hack on it. IMHO, the available stock of extensions is one of the
> reasons why many GNOME fans use Firefox rather than Epiphany.
Firefox has indeed profited from extensions and there are lessons that we can learn from that. GNOME Shell isn’t a browser, though. We need to be mindful not to adopt the Firefox model without considering the ways in which our needs might differ. The visual appearance of a desktop/OS might be far more important to its marketing than a browser might be, for example.
> At the end of the day, people who use them know that they aren’t
> stock GNOME, and how to disable them if they want to get the default
The point is that it decreases our brand presence. That particular user might understand what it is that they are running, but the person who sees them using their machine or even sees their screenshots on the web will not. The question we have to ask ourselves is: how do we make sure that people recognise a GNOME install when they see one?
> Finally, extensions makes it easier to enforce a common design that
> works for 95% of users, while allowing the remaining 5% to do what
> they like. This is a good way for designers to turn down complaints
> and keep hackers happy.
We’ve always argued that if it is anything, GNOME is a UX. There might be a case for letting people tweak things here and there, but I really think that every GNOME install should have the same core look and feel. Otherwise, what is it that we are doing in the first place?
William Jon McCann wrote:
I agree with Allan. I am really concerned about this effort to encourage and sanction themes and extensions.
In addition to the things Allan mentioned in the preceding mails, I think there are a few other issues to consider.
1. We rely on enthusiasts for testing
2. We rely on enthusiasts for building our brand
I think it is clearly detrimental to both to have more fragmentation and reshaping, recoloring, and replacing the user experience – especially in this critically important group of early adopters.
The issue is not whether extensions may be useful. The issue is whether they will be harmful to our larger goals.
If we aren’t careful they will be. I agree with Allan that, if we insist on going through with this idea, we at least have a few places in the design that remain unchanged. I think that themes should notbe included, that the top bar should not be changed, and that the overview should not be fundamentally altered.
Nothing Like Competing With Yourself
Even some of GNOME’s own software is seen as a competitor, like Gnome fallback mode vs Gnome Shell:
“the presence of fallback mode is having a negative impact on the quality of the primary GNOME 3 user experience” – link
See also this report: (fallback) [meta] Remove fallback support code
We could also suppose that non-default options are seen as competitors (of default options), as suggested by the following report:
tekstr1der wrote on 2012-03-22 15:04:34 UTC:
Still experiencing this bug (7 years old now) of desktop icons stacking/overlapping on the latest daily build of Ubuntu Precise 12.04.
Is the nautilus desktop abandoned?
André Klapper [developer] wrote on 2012-03-22 15:29:14 UTC (In reply to
> Is the nautilus desktop abandoned?
Sure [it is], as gnome-shell has been the default GNOME desktop interface for a year now and having Nautilus render the desktop is disabled by default.
Getting in deeper, not only are GNOME devs content to break their own desktop, but they want features removed from apps simply because GNOME no longer supports them!
For example, Gnome Shell doesn’t support status icons, so GNOME dev ‘mccann’ filed a bug report to a Transmission (BitTorrent client) dev to say that this option should be removed. Why should it be removed? Because Gnome Shell doesn’t support it anymore! Apparently in GNOMEland there are no other desktop environments (remind anyone of Microsoft?) From Don’t use a notification area icon in GNOME 3:
In the upcoming GNOME 3 we won’t be supporting notification area icons (status icons)…
Transmission has an option in the Desktop tab of the preferences to “Show Transmission icon in the notification area”. This should probably be removed.
charles (developer of Transmission) writes:
So now we can have three builds of Transmission that decide at compile time whether to use AppIndicator, GtkStatusIcon, or nothing at all, over such a stupid feature?
Removing it altogether, as you suggest, will hurt XFCE users.
I wish GNOME, Canonical, and everyone else involved would settle on one consistent API for this and stop fucking the app developers over.
In order for this ticket to move forward, I’d like you to tell me what change should be made to Transmission that will make it work properly, out of the box, on GNOME Shell, Unity, and XFCE.
I guess you have to decide if you are a GNOME app, an Ubuntu app, or an XFCE app unfortunately. I’m sorry that this is the case but it wasn’t GNOME’s fault that Ubuntu has started this fork. And I have no idea what XFCE is or does sorry.
It is my hope that you are a GNOME app…
We must choose our side. Is this a war? And can we really and seriously believe that one of the main GNOME devs doesn’t know what XFCE is?
Also, we see an indication of how decisions are made on GNOME:
FWIW, I don’t think Transmission is at all impaired by removing all of above – app indicator and status icon. I have never used it with the status icon myself.
Mr. GNOME Developer doesn’t use this feature, so it must be the case for all the world. So why keep it? It’s unneeded by GNOME!
As for those creative little panel applets…
William Jon McCann wrote:
I think one of the most important cases against applets (as they are currently defined in GNOME) is that they are extremely detrimental to the Identity of the product or platform. Today, our entire desktop identity is defined by a configurable number of horizontal or vertical bars filled with any number (even duplicates) of random Things that may launch stuff, open menus, open dialogs, operate on windows, switch workspaces, and more! Boxes-o-crap as I lovingly (in the eulogistic sense) refer to them. Each time I see “Remove from panel” when I right click on the notification area or the menu system I weep and my mascara runs and god is it awful.
Let’s say that we are trying to define either a product or a product platform. I don’t think it is possible to do this without some “brand” coherence. And it is arguably impossible to do this effectively with such an ad-hoc/individually-customized design identity.
Even those of us in the developer community would have a difficult time identifying a GNOME desktop in 3-5 steps. Let’s try this with Windows: “Start” or Windows symbol menu, (usually) bar at the bottom. This works from Windows Server products all the way to embedded Windows on smartphones.
With OS X: Apple logo menu, menu bar at the top, (usually) a dock. Even though the iPhone doesn’t have the same software identification experience it retains the platform design branding on the hardware and uses familiar themes in the software visual design. There is usually no doubt that it is an Apple platform.
With Android: who knows…
So, one of the many very exciting things about GNOME Shell is that for the first time we may have ability to really shape the user experience and form an identity for the GNOME platform.
That’s what excites him, but likely not what excites users.
Apparently in the view of these devs, users are merely walking billboards for their ‘brand presence’, to hell with what the users actually want. You’re expected to change your way of working every 6 months just because these devs want to impose their way of working on all their users. Developers decide what is Good (with a big G), without any possible customization by the user.
The screensaver was removed from Gnome 3 “by design”: What is the status of the screensaver in GNOME3?
The request for the ability to customize the Nautilus menu bar was closed as WONTFIX, with this beautiful explanation:
Cosimo Cecchi wrote:
We decided to streamline the nautilus design for 3.0, and we finally decided there’s no use for an editable toolbar in Nautilus.
Meanwhile, a user request: please add a way to customize the toolbar
The report asking to reintroduce the location/path toggle button was closed as WONTFIX. The sacrosanct Nautilus interface is more important than users’ needs:
André Klapper wrote:
There are currently no plans to reintroduce the location bar by default or to provide a toggle button as the cluttered interface has been simplified for 3.0.
Meanwhile, a user request: Reintroduce location/path bar toggle button
Same for gnome-power-manager…
Richard Hughes wrote:
Sorry, but the whole point of gnome-power-manager is to save power without getting in the way of what the user wants to do. It’s not going to let you set the “performance” governor any more than it lets you increase the brightness on battery.
The Power Off option was removed from the Gnome Shell menu. Devs know what users want to do, more than users themselves:
Owen Taylor wrote:
The Power Off option is hidden because we don’t believe it’s necessary in that menu […]. The primary way that a user would shut down (if they, say, need to disconnect power) would be to log out and shut down through GDM.
Features you ask? Let’s remove some:
A really nice quote, Bastien Nocera writes:
we’re not designing a desktop for people who like to choose their own terminal emulators
And in the last version of Nautilus (3.6), features are really a has-been concept. From TechRepublic:
The latest bit of crazy to come from the GNOME camp is the list of features being removed from the Nautilus file manager (as of 3.6). This short list looks like:
– Compact View gone
– ‘Type Ahead Find’ gone
– ‘New file’ templates gone
– Application Menu gone
– ‘Go’ menu gone
– F3 split screen gone
– ‘Tree’ view gone
– Bookmark menu items gone
– Backspace shortcut to return to parent folder gone
Nor is this pattern limited to GNOME. With Ubuntu, it’s all the same. There is a request for the ability to move the Unity dashboard, which is to the left of the screen. Mark Shuttleworth himself came to close (WONTFIX) this report the next day with this beautiful explanation:
I’m afraid that won’t work with our broader design goals, so we won’t implement that. We want the launcher always close to the Ubuntu button.
And notify configuration? Mark doesn’t want settings (and neither do you):
The design of Notify-OSD is specifically not clickable, and we would NOT accept patches to change that.
Another prime example of this behavior in Ubuntu devs is the Launchpad example. After years of criticism because it was closed source, Ubuntu eventually released the code, but just for its own benefit. It’s so complicated that no other webforge uses it. It is coded only with the website Launchpad.net in mind. They really don’t want ‘competition’.
Even Launchpad icons are not free:
The images/icons are still copyrighted traditionally, to protect Launchpad’s visual identity. […] From our point of view, we have open-sourced Launchpad to improve our hosted service.
And were you thinking of actually USING it?!
Building and running Launchpad requires a computer running Ubuntu.… Running a stable production instance would be much harder than running a single-developer test instance, and we don’t recommend it. Unlike many open source projects, we’re not seeking to maximize the number of installations; our goal is to improve the instance we’re already running at Launchpad.net. Note: the changes introduced by the install script may break your current web development setup, so it is advisable to try Launchpad in a virtual machine or an LXC container, as described above.
The following bug report is instructive: Launchpad wiki contains zero information regarding running launchpad on your own domain
The reply? WONTFIX, with this explanation:
Launchpad’s code was opened to permit the Launchpad community to contributor [sic] to the project. The information provided is the same information used by Launchpad developers. Artwork in the project may only be used for development, so instructions to run a public instance of would put the contributor in violation of the license. The launchpad team dos [sic] not maintain the production configurations of Launchpad, they do not know exactly how to setup an other instance.
Does this sound like Linux to you? It’s surreal, like this FAQ entry, Can I run Launchpad on my own server:
Yes, you can, but keep the following things in mind:
As per https://dev.launchpad.net/LaunchpadLicense, please replace the images and icons with your own.
Also, Launchpad’s production configuration information and some configuration-specific admin scripts are not part of the Launchpad code base; you’d have to reinvent those in a way appropriate for your setup.
Finally, keep in mind that Launchpad’s code is under very active development, with hundreds of changes released each month. Syncing your private instance with the upstream code base may be risky because your private instance won’t necessarily get the same data migration treatment that the main instance gets. Essentially, there’s a risk of a private instance becoming an unintentional fork, where its code cannot be safely updated due to the data in the local instance being incompatible with the latest database schema or code assumptions.
So the answer is “Yes, you can run your own instance”… but please be aware of the risks and the lack of support before doing so. We don’t recommend it; we’d much rather have you using this Launchpad instance and contributing to its improvement.
Some comments from people trying to actually use Launchpad:
I wanted to have my own instance a while ago, mostly for the bugs and maybe the answers and blueprints parts, but in its current form, installing and maintaining up-to-date such a beast is a nightmare. The install guide is oriented toward lp.net developers and contributors, not toward sysadmins wanting their own instance. The code is nowhere near a packageable state (at least it wasn’t last time i looked). I guess the latter has been made on purpose – or should i say, no effort has been made in that direction… – link
You might be saddened to know that the guys working on launchpad in #launchpad on freenode officially suggested I _not_ setup another launchpad instance. Some of these people were Canonical employees.
I wanted to play with mirroring the gnome bugzilla in a dev launchpad instance just to see how the software worked. I was primarily told that launchpad (as software) is unable to sync with another launchpad instance and would be strongly discouraged from doing what I’d envisioned. I was also told that while they were very interested in any improvements that I might make, they did not want another big launchpad instance. They promote launchpad.net as a service vs launchpad as an open source bugtracker.
So… my official opinion on this is that Launchpad is dumped code that is not really a community effort. Canonical is against any competing big launchpad installs and is very uninterested in splitting parts of it off such as Malone so that someone can use it as a stand alone bugtracker… – link
I highly doubt it. I’ve been trying to set it up in a VM at work for a few weeks now, and it is very much impossible. The lack of / incomplete / incorrect documentation, bizarre deployment process, and hidden / unavailable components makes for way too high of a secret sauce to normalcy ratio for any human to figure out. We’d *like* to use it for a group of projects (both FLOSS and proprietary, both public and internal), but so far my attempts to give it a trial run have been an utter failure. – link
Brand, brand, and brand. Even such a simple and basic question like the following becomes “complex” and can’t be answered by Launchpad devs because of their brand obsession. From What license is used for bug icon in Launchpad?:
Asked by Andrey Cherepanov on 2009-04-20:
I like nice bugs icon in Launchpad. On what license I can use they in my project?
Karl Fogel (kfogel) said on 2009-04-28:
We’re discussing internally; more soon! It’s a complex question, because some images, like the logo, identify strongly with Launchpad.net, whereas other images might not identify so strongly (not sure if the bug icon is in that category, we have to figure that out). Because of the “recognizeability” issue, this is not just about copyright license but also about trademark policy. So, we’ll get back to you as soon as we can. Thanks for asking.
No answers followed – apparently the decision was made to traditionally copyright all icons and images.
A user writes in email:
I was very happy when I knew that [Launchpad] was open sourced in 2009, but I quickly disenchanted. And Launchpad is not even translated after almost 9 years of existence. Wow. You know that the community is not really involved when a software is not translated after 9 years, including last 3 years as open source software.
Look also at Ubuntu One: Server-side is closed source.
Then there are the Amazon-affiliated advertisements in the recent Ubuntu 12.10. Now, when you search something on your local computer (applications, files, etc.) with the Unity dash board, your search for local files is also sent online to display Amazon-affiliated advertisements. The Electronic Frontier Foundation wrote an article about this,
Privacy in Ubuntu 12.10: Amazon Ads and Data Leaks:
Technically, when you search for something in Dash, your computer makes a secure HTTPS connection to productsearch.ubuntu.com, sending along your search query and your IP address. If it returns Amazon products to display, your computer then insecurely loads the product images from Amazon’s server over HTTP. This means that a passive eavesdropper, such as someone sharing a wireless network with you, will be able to get a good idea of what you’re searching for on your own computer based on Amazon product images.
It’s Not Just Amazon
The new version of Dash that comes with Ubuntu 12.10 introduces more than just Amazon ads. It includes a new legal notice that you can see by clicking the “i” in the corner of Dash that states that by using Dash, you automatically agree to send your search term and IP address to a number of third parties:
> Unless you have opted out, we will also send your keystrokes as a
> search term to productsearch.ubuntu.com and selected third parties so
> that we may complement your search results with online search results
> from such third parties including: Facebook, Twitter, BBC and Amazon.
> Canonical and these selected third parties will collect your search
> terms and use them to provide you with search results while using
Ubuntu’s Third Party Privacy Policies page lists all of the third parties that they may send your search term and IP address to, and states: “For information on how our selected third parties may use your information, please see their privacy policies.” In other words, once they give your data away, it’s no longer their problem.
So Ubuntu doesn’t even care about what third-parties will do with their users’ data. Microsoft, anyone?
You feel that something is changing when your local searches are accompanied by corporate advertisements.
Time to use KDE 4? It has the same trends. A user writes:
When Gnome 3 was released, I tried KDE 4.x, but some easy and basic settings with KDE 3 were no longer possible, for example just changing the bottom panel color. Now it’s so complicated. You must create a theme with special SVG format files…
Also, the order of windows in the windows list was changed, without any possibility to customize it or to set it the way it was with previous versions. Now it’s so unergonomic, because when you open a new window, instead of putting it in the end of the list, it moves all already opened windows in the windows list of the panel, so the order is always changing. See this report: Task Manager setting “Force row settings” changes button sort order from row-major to column-major
It was opened in 2009 and closed as WONTFIX, even if there are proposed patches, a lot of user activity, 120 votes and even a user proposing a package rebuilt with patches.
KDE3 was an immense field of options, but I suppose that now, KDE 4 adopts this kind of reasoning. See rekonq: rekonq should show a menubar / make menubar switchable
This report asks to add in rekonq, the default KDE web browser, an option to have a real main menu bar (like most software) instead of an icon that we must click to display a drop-down list menu. Very good dev’s answer, Andrea Diamantini wrote “We decided this way, sorry. And we really like it. No plans to reintroduce it.”
OK, so devs don’t care anymore about users, even in KDE.
I could write about Firefox, removing features, like the “named separators” feature, just because devs don’t use it, and even if a lot of users complain about data loss because they were relying a lot on named separators to classify their bookmarks and they lost all that during Firefox updates.
What’s the problem? Is free software now just a market for devs working for very big tech enterprises and wanting to feel power and fame as if they were a big boss?
I think the lesson here is that as long as users put up with such nonsense, perhaps for the sake of the latest (non-configurable) bells and whistles, this is what they’ll get – dwindling options in Linux.
What is or isn’t done in GNOME is up to its devs, but nothing says you have to use it, or continue to use it as it devolves into Microsoft Windows.
And reading those dev comments, it’s so clear that most of their thought and energy is devoted to their marketing and ‘brand presence’, and so very little to making quality, innovative software. By some strange coincidence, that’s just what has been largely lacking in the field of Linux apps.
I hope you’ll pass this article along to help raise awareness of what these devs have planned for Linux and YOU.
Many thanks to additional unnamed (by request) contributors to this report!
UPDATE: A print article based on the above article and covering wider impacts in Linux will be appearing in Issue #122 on January 17, 2012 in Linux User & Developer magazine – be sure to pick up a copy:
As a followup to my previous reservations about systemd and the means of its introduction, there is a very informative discussion happening on Gentoo Forums, including design flaws of systemd, the consolekit problem, and the expenses of policykit. I think the Gentoo community and philosophy really shines there:
“…it’s because everything he comes out with wants to take over our machines, with a mess of so-called “integration” requiring changes across the board. Til he finally realises what everyone was on about, and drops the project for his next shiny adventure, leaving everyone else to pick up the pieces.” – steveL
Elsewhere, Linus Torvalds is heard to “call bullshit” (and more!) on Kay Sievers’s excuses and poor maintenance. It’s nice to see Linus is aware of what’s going on.
Further, a udev fork is already underway and gaining popularity, which is good due to the aforementioned problems with udev maintenance and mission creep. Hopefully this will grow into a strong and independent replacement.
At the very least, it’s great to see there is a population of Linux users, admins and devs who are aware of the implications of these changes, and that they’re already exploring alternatives.
Udisks2 is emerging, and while this could have been good news for Linux, it is instead a prime example of how Linux is in decline.
Author David Zeuthen explains his reasons for rewriting udisks here. To put it simply, it’s all about Gnome. It appears that increasingly udisks is becoming an internal Gnome component and less a universal Linux tool, certainly not command-line friendly. That means there is no real replacement for hal without adopting almost complete desktop environments. This is not a good state of affairs for Linux development. I haven’t tried it yet, but it will be interesting to see what a mess udisks2 makes of systems which aren’t running Gnome, since the udisks2 author seems to barely consider such use, and even works against it. udisks v1 certainly proved difficult enough with many non-Gnome users having endless polkit and consolekit issues. Rather than addressing this, udisks v2 aims to worsen it.
David Zeuthen seems to have no use for the Linux command line either – new in version 2’s docs for the command line tool:
This program is not intended to be used by scripts or other programs – options/commands may change in incompatible ways in the future even in maintenance releases. Scripts and/or other programs should either use the D-Bus APIs of udisks2-daemon(8) or native low-level commands such as mount(8).
Want to write a quick script to mount a device? Forget it, according to David Zeuthen – that’s not to be done in Linux. While this update may make Gnome’s Disks utility prettier, it undermines the core philosophy of Linux, which is that programs interoperate using simple command line interfaces and text streams. Apparently, the vision here is to make it as closed and convoluted as Windows.
This has become a trend in Linux – increasing use of convoluted and buggy library APIs and mostly-broken security mechanisms, the abandonment of simple command line interfaces, and continuous breakage due to usage and API changes. This effectively turns Linux into Windows, where users can’t do much from a command line, and even when you should be authorized to do something on your own system, that system denies you permission. This decline of Linux is being enabled by desktop environments like Gnome and KDE which seek to replace core Linux tools with their own too-good-to-be-true tools, then change these tools to demand that more of their desktop environment be completely installed, security problems, bugs, and all. Lightweight apps get drawn into this cycle using the likes of gvfs and udisks, which renders them bug-ridden and bloated. Users then have to sacrifice their system security and performance to use them at all.
It’s hard to give a negative review of free software development, but I think this kind of narrow-sighted, monopolistic development does more to undermine free software in the long run. Simply put, this change to udisks leaves Linux with no good options for device management.
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.
This is a quick review of my experience installing Aptosid on an Asus A53E-XN1 laptop. There wasn’t much info on how Linux would cooperate with some of the newer hardware in this machine so I thought I’d enter it in the record that it works great, providing you’re using a newer kernel and drivers.
The Asus A53E-XN1 is a budget laptop (under $400) with very decent speed. It uses an Intel B940 dual-core processor which also serves as its GPU. From what I read, it doesn’t include 3D acceleration (B940 is i915 with 3D accel disabled), so it’s definitely not for gamers. But I found it does have OpenGL support and does handle basic OpenGL 3D games smoothly. For video playback, it plays smoothly, except for some minor tearing when playing HD video (this was no great concern to me so I didn’t try tweaking it). Display is decent – glossy but not glass-flat, so reflection isn’t a problem. Its aluminum body keeps it very cool, including palm-rests, and it has a well-made feel overall. The touchpad is one of the best I’ve encountered, and the keyboard is well-made. The built-in card reader works. Its weakest point is a typical 5400 RPM hard drive. All-in-all it’s a nice machine which includes a 1 year spill/drop/surge/fire damage warranty. (I have no affiliation with Asus other than being a long-time customer.)
Model: ASUS A53E-XN1 Provided OS: Windows 7 Home Premium 64-bit CPU: Intel Pentium B940 2.00GHz 2MB L3 Cache RAM: 4GB 204-Pin DDR3 SO-DIMM (2 slot total capacity 8GB) Hard Disk: 320GB 5400 RPM Optical Drive: DVD Super Multi [ burning not tested ] Graphics: Intel HD3000 Graphics (Sandy Bridge) [ i915 ] Video Memory: Shared memory Communication: Gigabit LAN [ atl1c ] and 802.11b/g/n WLAN [ rtl8192ce ] Screen Size: 15.6" wide glossy 1366x768 LED backlight Ports: USB x3, HDMI [ untested ], VGA [ untested ] Card Reader: 5-in-1 card reader for SD, MMC, MS, MS PRO, SDHC (SD 2.0) [ works ] Webcam: 0.3MP [ uvcvideo - untested ] Warranty: 1 yr ASUS Accidental Damage Warranty - Drops, Fire, Spill, Surge
I booted an aptosid-2011-02-imera-xfce-amd64-201107131632.iso CDR, then copied the 11GB contents of the /dev/sda1 fat32 recovery partition to a usb stick just in case. (The recovery partition is 25GB but only 11GB is used – wasteful Asus! Windows 7 consumed about 30GB and was on a separate system partition from the large data partition. Note that there is some unusued space before the first partition – not sure what they used this for.) And I backed up the MBR and partition table. Then I ran cfdisk and deleted all the partitions and created three 10GB system partitions and a data partition. I had to format the new /dev/sda1 partition myself because for some reason Aptosid’s installer won’t install to an unformatted partition (they tell me this is by design).
Note that kernels older than about 2.6.38 or .39, and xserver-xorg-video-intel drivers older than 2.15 may not work with Sandy Bridge, or may work poorly. Since Aptosid is up to kernel 3.0 this wasn’t an issue.
I found some odd settings for the drive checking so changed them to more reasonable defaults (check drive every 20 days or 40 mounts):
tune2fs -i 20d -c 40 -T now /dev/sda1
On the first dist-upgrade, I got an error that the firmware couldn’t be loaded and that I needed to add contrib and/or nonfree repos. So I did so and installed the firmware:
apt-get install firmware-realtek
On a reboot the wireless then showed up. I installed lxde, which didn’t include a network manager, so:
apt-get install network-manager network-manager-gnome
Network Mananger picked up both the wired and wireless and connected fine. The built-in function key which dis/enables the wireless hardware worked (as expected).
The built-in function keys for mute and volume worked out of the box with XFCE. For LXDE the keys didn’t work, so I mapped them in openbox to my own volume script. (I didn’t test lxpanel’s volume control.)
The screen brightness built-in function keys work in both desktops (hardware driven?) There is also a key that turns off the display. Other function keys didn’t seem to have functions assigned.
Suspend did not work (went to a text display and hanged), but this could be because I have no swap setup. [Update: suspend is reported to work with this fix.]
Pressing the power button in LXDE goes into immediate shutdown (which personally I like). The LXDE and Openbox menu options for Shutdown bring up LXDE’s shutdown menu. With XFCE, I think pressing the power button brings up a menu.
The lxpanel battery and CPU monitors work normally (although the time to recharge is given as 0:00, but they seem to be having general problems with lxpanel’s battery monitor in that regard). The temperature monitor read “NA”, but I haven’t investigated what sensor packages may be missing.
The 5-in-1 card reader worked without configuration when tested with a Sandisk 16GB SD-HC card. (By then I had devmon running and it mounted the card as a drive and opened the file manager.)
X11 ran fine for video – no messing with any configuration or manual installation of drivers required (good job Intel!) DVD playback in vlc was good, as was most AVI playback and Flash video. Playback of HD video revealed some minor tearing.
The touchpad had a double-tap problem – unless one double-tapped VERY quickly and precisely, it was ignored. Single and triple taps worked okay. I resolved the double-tap problem with the following:
mkdir /etc/X11/xorg.conf.d nano /etc/X11/xorg.conf.d/synaptics.conf # creates missing file
I put these contents into /etc/X11/xorg.conf.d/synaptics.conf:
Section "InputClass" Identifier "Touchpad" # required MatchIsTouchpad "yes" # required Driver "synaptics" # required Option "LBCornerButton" "8" # browser "back" btn Option "RBCornerButton" "9" # browser "forward" btn Option "MaxDoubleTapTime" "130" # corrects double-tap problem EndSection
In addition to correcting the double-tap problem, this also enabled corner taps for back and forward in a browser. This takes a little getting used to, but did work marginally.
Aptosid’s default audio setup (alsa) worked without further installation or configuration. Built-in speakers are Altec Lansing – typical laptop quality and not particularly loud.
I have not tested the webcam, HDMI port, or VGA port. The ethernet and power ports are in the middle of the left side. The VGA and HDMI ports are along the left side toward the front. There is one USB on the front left, and two on the middle right. The speaker and mic jacks are on the front right side.
As for games, I haven’t tried much, but FlightGear flight simulator installed without issue from the Debian repos, and seemed to run normally. I also tried billard-gl (3D billiards game), whose 3D effects were smooth.
Overall, it was a breeze installing Aptosid on this machine – one of the easiest Linux installs I’ve ever done, especially on a laptop. Kudos to the Aptosid team and Debian!
For more info on Aptosid, see my previous post: My Move From Arch To Aptosid