Debian Unstable (also known as sid) is one of the 3 distributions that Debian provides (along with Stable and Testing).
It’s not conceived as a product for end-users, instead it’s the place where contributors are uploading newer packages. Daily. Yes that means that Unstable is a quickly moving target and it’s not for everybody. But you can use it and your computer won’t explode.
1. It contains mainly stable versions of the software
Yes, you read it right. Unstable is not full of development versions of the various software. It happens on some software but then it’s usually a conscious decision of the maintainer who believes that this specific version is already better than the previous one.
The packages in sid are supposed to migrate to testing, the place where the next Debian stable release is prepared. So maintainers are advised to only upload stuff that is of release quality, the rest should be uploaded to experimental instead.
2. It doesn’t break badly every other day
Breakages happen but they are not a big deal usually. It has been long time since I could not reboot my computer after an upgrade or since the graphical interface was no longer working. The kind of breakages that you have is that one software stops working, or triggers an annoying bug, or that a few packages are uninstallable.
In most cases, you can save yourself by downgrading to the version available in Testing. Or by finding a work-around in the bug tracking system. Or by not upgrading because you have apt-listbugs installed and you have been warned about the problem.
3. It’s the basis of other distributions
If Debian Unstable was really so bad, it would not be a good basis to build a derivative distribution, isn’t it? But Ubuntu and SiduxAptosid (to name only two) are based on Debian Sid.
4. It’s not inherently less secure than Stable or Testing
High impact security vulnerabilities will usually be quickly fixed in Stable and Unstable. The stable upload is done by the security team while the unstable one is made by the maintainer. Testing will usually get the fix through the package uploaded to Unstable, so testing users get security updates with a delay.
For less serious vulnerabilities, it’s entirely possible that stable does not get any update at all. In that case, unstable/testing users are better served since they will get the fix with the next upstream version anyway.
Of course, it happens that maintainers are busy or that something falls through the cracks, but there are other people watching RC bugs who will fix this if the maintainer doesn’t react at all.
5. I use it on my main computer
And many other people do the same. And you can do the same if you meet the criteria below:
- you can work on the command-line (enough to downgrade a problematic package, to edit configuration files, etc.);
- you know how to work with APT and multiple distributions in /etc/apt/sources.list;
- you are able to read/write English so that you can read/file bug reports when needed;
- you have another computer connected to the Internet that you can use to lookup documentation (or the bug tracking system, or the support mailing lists) when your usual computer is off-line for a reason that you don’t understand.
If you feel you are not ready for the jump, click here to subscribe to this blog (or here via the RSS feed), I’ll surely teach some of the required skills in future articles.
PS: All that said, if you have a working sid installation, do not upgrade it just before an important presentation, or before a trip. It will always break at the most annoying time. Unless you like to live dangerously, of course.
Isn’t reason number five a “FIXED: works for me” rather than a true reason?
“Works for me” often is good enough, but even more often “works” includes a lot more than that… 🙂
Well, it depends, I’m not really representative of the average user… because I know how to fix a lot of the problems but I’m also an advanced user so I notice more of the problems as well than someone who is always using only a browser, a mail client and an office suite.
But there’s value in knowing that many people are using unstable, both because it means that it works for them and that there are people who will face the same problems than you and you will be able to leverage this pool of knowledge (through the bug tracking system and the mailing lists) to get things fixed (or find work-arounds).
“sidux” is now called aptosid. It’s almost vanilla sid, unlike Ubuntu. The best thing about aptosid is that there is a promise of support: it’s basically Debian unstable, with a dedicated community behind it. You’re right, it doesn’t blow up very often, and if it does, aptosid users have another great resource: the aptosid forums. I’ve used it on my main laptop for about 18 months.
Thanks for the notice, I was wondering why the sidux website looked so empty… that explains it.
Dear Raphaël, thank you for this excellent article. You gave me some pretty nice idea, I’ve completely forgotten.
It’s not really about Debian Unstable (I don’t care so much about “old” vs. “new” software), but about Debian (en particulier) and free software (en général):
Free software empowers me to change things, I don’t like (on a local level), and to talk about things, I like (on a broader level).
Yeah!
> you have another computer connected to the Internet that you can use to
> lookup documentation (or the bug tracking system, or the support mailing
> lists) when your usual computer is off-line for a reason that you don’t
> understand.
People with only one computer can run into horrible trouble. Having two computers doesn’t half give you a big safety margin, something a lot of people forget.
I once installed woody. (Does anybody remember this?) Then I upgraded to sid. I still use that system for most of my tasks. Any questions about sid’s stability? For me apt-listbugs was the biggest time saver. Actually by now I frequently mix in experimental. Guess what? Even experimental packages are not that broken. During freeze many maintainers upload stable versions to experimental. (Example: python3.2)
If you experience problems or bugs in sid, then reporting bugs helps a lot. (This one may seem obvious, but too few people do this actually. Why?) With the exception of one particular dash bug caused by some NMU some years ago most big problems are solved quite quickly.
I’ve had trouble with using testing/unstable only one time, with xfig. It was really really annoying to me at the time. Some time later I learned better how to manage the packages…
Truth is Debian must rethink all this stable/testing/unstable thing, and change apt to manage all that properly. Making your system being able to handle multiple sources (stable+testing+unstable…) should be something normal, should become something at the heart of how the distro works, and not an ugly hack.
The tools we have were all created with an idea that a person would choose one of these versions, and just stick to it. What we need is a tool that implements the idea of a “version” only as some kind of script. Like “install these versions of these packages”… My feeling to day is that our systems are always weird chimeras because we always have some changes from the official versions. This has to become the norm, not something strange and unnatural.
I know that it is possible to manage your system to make what you want, but this still requires a lot of “hacking”. We must automate the task of having a “hacked” system, today we have great automation for having systems with specific versions, but not chimerical systems…
So the problem is not so much about using Debian SID. It’s about how to deal with it when you need to change from SID. Just using SID is easy, just make a sid-only apt/sources.list, and be helpless if something breaks. Now, handling a SID+testing+stable system is another story…
When “apt 2.0” arrives will be the day people will stop feeling bad about using SID. Not “moving to SID”, because that’s exactly the concept we must demolish, the concept that we are using “stable” or “SID” or something else. We haven’t quite yet reached the point where we transcend the idea of having a specific verion isntalled in out machines…
Nic, you’ll have to explain what you miss to properly handle multiple sources in your system… I always have stable/testing/unstable/experimental activated in my sources.list and I have no problem dealing with the result. It’s not an ugly hack… you just have to know the various ways to pick a package from a given source and ask apt to stick to this distribution.
Maybe we lack a graphical tool to create the /etc/apt/preferences file that dictates how APT will manage updates coming from the various sources. But the building blocks are already in place and it doesn’t look like a hack to me.
Maybe the graphical tool is not what is missing. Selecting a specific version is not that of a problem either (example:
). However the next safe-upgrade will just upgrade the package. What needs automation is the changing of this tracking information. A change like this has already happened in the past: The “automatically installed” flag. I envision something like
or even
.
Helmut, you can solve this upgrade problem with /etc/apt/preferences (see man apt_preferences) but you have to keep a manual list of packages and associated distribution. It will work some time but at some point the interdependencies might cause trouble and won’t allow you to continue to track the upgrades in the target distribution without also upgrading other packages.
Repeating yourself is not helpful. Reading my comment would have been. I was not addressing a lack of feature but a lack of usability. Why does aptitude allow you to query its database using search, show, why, etc? Why does it allow you to change it using markauto, forbid-version, etc? Wouldn’t simply editing a text file be much easier? No, it would be a nightmare and so is /etc/apt/preferences.
Right, sorry Helmut, I did read your comment but I wanted to point out that even with proper command support like you gave, the result will only work if you do this kind of mix on a limited number of packages.
The more you mix, the more likely you’re going to encounter incompatibilities due to changes made in the newer releases. So making it more easy to use those features would likely result in users getting hit by such problems more often. Unless you use only validated combinations (like using backports.debian.org on a stable system).
I hope you see my point now.
You are right in that such mixing can cause problems if used improperly. However mixing backports and stable or mixing experimental and sid should almost never cause them. You can do harm with a knife, is this a reason not to have one?
You’re damn right ! Sid is my distribution for 3 years now and it’s incredibly stable. My last crashes were experimental distribution’s fault.
The only reason we can’t always use sid is it’s not newbieproof : there is few bugs and only people who has a certain level of knowledge of GNU/Linux can fix them. My mom couldn’t use sid for exemple.
For a start, someone could write proper documentation. For instance, the apt_preferences manpage might mention that it doesn’t work properly if you have set APT::Default-Release – I once spent hours figuring this out…
Michael, this would be a good opportunity to provide a patch.. 🙂
(or file a bug about it)
I don’t think this is true. You can combine both, you just need to know that packages part of APT::Default-Release have a priority of 990.
I’ve used unstable for maybe 5 years now. I will say that I believe average users should not use it because while in my experience major issues are rare, average users do not have the skills to resolve them when they do occur.
That said, over the last 5 years unstable has improved tremendously. I used to have issues with graphics or the kernel on every other upgrade but I haven’t had to deal with these issues in a few years and I feel comfortable upgrading any time. I consider moving to experimental if only to add more excitement to the system. It’s boring when everything works as expected 😉
Thank you DDs!
It’s called Sid because it might break your toys. Major breakage may not happen *that* often, but still it happens and the more often you update the more likely you are to get bit.
It’s called unstable because it is like the shifting sands. Newer versions of software coming in all the time which may bring binary incompatible updates, configurations that change, database formats that change, which may make custom stuff break, make things temporarily uninstallable, or cause certain feature not to work temporarily.
It’s defining stable as ‘doesn’t crash’ or ‘works for me’ that leads to trouble, whether it’s Debian unstable or beta versions of Ubuntu, when you tell people this who are not able to deal with issues and not all that willing to learn either.
Later, Seeker
My reason: http://backports.debian.org/ , Sid is for specialists not for me! Debian live my desktop since 2000! Debian works anytime very stable, not crash! I put Debian live my pendrive, works fine too! Thanks DDs!!!!
Hi Raphaël,
thank you for your article on the usability of debian unstable.
I agree, it has turned into a usable system in the past years. I have been using nothing but unstable (kanotix/sidux/aptosid) for the past 6 years on all my desktops and notebooks. At least 2 of those are production machines. The last and only time one of those was unbootable was on the upgrade from Xorg 6.9 to Xorg 7.0. It took us 2 or 3 hours to get that fixed. So i do go along with your recommendation to have at least a second device at hand to join the net and be able to access your trusted support facilities.
For a plain debian sid install there is not much support around, as the word goes: ‘If you use it, you should know how to fix it if it breaks.’ We at aptosid try to filter out broken packages that would affect our users and also build a community and support-net around unstable. Over the years it shows this is feasible, even for users that are not deep into the matter. Still we expect our users to be familiar at least with the usual maintenance tools like apt and dpkg to make them happy campers.
From my point of view, unstable getting showcased a bit more is a win-win situation. Users get recent packages of the software they want or need and debian gets a wider testbed for packages meant for the next stable release.
Hi Ferdinand, thanks for this feedback. I think it’s great to build a community and support-net around unstable, but why are you doing that as an external project?
Can you give examples of what broken packages you filtered out?
I would love to be able to direct users to some friendly debian.org/debian.net place (web forum, mailing list, whatever) where they can interact with other users of unstable. I have more troubles sending them over to aptosid for this… maybe because I’m too much of an hardcore Debianer. 🙂
Many people ask me why it is an external project. When we started out some years ago, there was no acceptance for an unstable-based project in debian. Still today it is seen as useless and/or dangerous by some people inside debian. Not only sid has changed though over the years, so has the acceptance of such projects (CUT was widely discussed in 2010).
As debian has been in freeze for quite some time, sid is rather tame at the moment. The last package i remember we fixed was tar.
Since this is a very interesting topic, specially at an year’s end, here is some more 20 cents!… :]
First of all, I think the only persons that could really enjoy using a “stable” system are system maintainers who want a very reliable and tested and well documented box to do something. That’s what someone would install in space shuttles, I guess. But for e.g. desktop users stable can be as bad as unstable. IMHO the bugs that appear in more recent packages can be as much of a nuisance as the absence of new features in stable. Both are equally “broken” in that sense. You invariably will like to mix both to either avoid an existing bug in SID or get a bugfix/new feature from SID.
In my machines I have come to the conclusion that the best for me is to make stable the default version, but most of my packages are actually from SID. I just do “apt-get -tsid” all the time. And in practice, when I really need something very up-to-date I install from the original source code. I have been using my own Python2.7 and self compiled Linux kernels for example…
All that has some advantages and some problems. And it’s all just natural consequences of the natural compromises: software stability/recency, personalized/documented-and-tested-by-others… And I feel the tools (apt and all) should reflect that more directly.
I know it is _possible_ to manage a mixed system, but look what the “OP” is talking about, and how other bloggers have reacted. We have people arguing whether end-users are supposed or not to be using SID, or if end-users should stick to stable. I say end users and everyone else should be using the same thing, with a range control that ranges from “I am a cardiac granny” all the way to “are you nuts???”.
End-users should be using stable, but they should be able to easily test SID packages, or use backports and things like that… We must stop thinking that the versions are what people are going to install. We must stop thinking there are “stable users” and “sid users”, and think more of people using backports, debian-multimedia and other kinds of monsters.
But anyway, maybe there isn’t really much we can change, and all we lack are better documentation and package maintenance… There reason things look hackish to me is probably because I don’t understand well how stuff works, and feel like doing something awkward while it is actually exactly how it was supposed to be done.
I’ve had a love/hate relationship with Debian for many years. I’ve taken a look at other distros, but for some reason I always come back to Debian. I “hack” it when I need, and I get my job done… Now should the end-user be using stable or SID? I don’t know. The end-user should decide. Instead of us deciding what Ms. Enduser should be using, we should instead talk about how we could help she make a better choice and better migration between both.
“End-users should be using stable, but they should be able to easily test SID packages, or use backports and things like that… We must stop thinking that the versions are what people are going to install.”
It’s easy enough to add backports to your list of repositories.
Once a new release is out for a few months, maybe more maybe less in some cases, it starts to be too different to be able to easily test out SID packages because it gets to a point that by the time you install all the dependencies then you might as well just upgrade to SID.
Testing is a the middle ground. There is still some potential for significant breakage, but much less likely, most likely breakage would be in the form of some packages that can’t be installed because of some transitional situation, but still not suggested for those not willing to learn some of the ins and outs of how package availability vs. dependencies affect things and how to work around some of the things that may come up.
Later, Seeker
For those who want the counter-argument for this blog post: http://rhonda.deb.at/blog/debian/5-reasons-why-unstable-is-not-for-everyone.html
The Linux world is full of people running distros like Arch and Gentoo. Sid is easily more usable than either of them but still provides the experience of a rolling distribution and the need to hack on your system every now and then to keep it running.
Rather than discouraging people from using sid, debian should be trying to win over users from the hacker distros to help test sid and experimental, IMHO.
Well said!
I can’t speak for ferdinand but I use aptosid because debian scares ordinary users away from sid (see another recent post on debian planet for example). sidux as it was back then promised and delivered a supported sid. First I used testing for a while but it takes too long for fixes to get there. And my several tries of ubuntu about two to three years ago showed it to be more buggy than sid although the last two releases have been good. But anyway don’t give sidux/aptosid a hard time. it is an awesome distro very close to debian.
Don’t worry Tim, I don’t want to give aptosid a hard time, on the contrary. I want to encourage such communities but I wish they were advertised directly from debian.org, I don’t see the benefits of being a derivative.
It could be done as a Debian sub-project like Debian-Edu/Junior/whatever, but its target would just be people who like bleeding edge software. I also mentioned it once that it would be a good opportunity to collaborate on “Constantly Usable Testing”.
Correct me if I’m wrong but didn’t the stable/unstable part of Debian refer to the software collection and not to if it crashes or doesn’t.
I.e. unstable gets new software versions whereas stable doesn’t, i.e. the versions are stable. That would lead me to believe the “unstable” name for SID is well deserved.
I use it on my main computer
And the question is: For how long?
Ro, for about 12 years. 🙂
In truth, I used stable during a few years in the middle of those 12 years (and had a sid chroot for the Debian development). But it’s been at least 3 years that I have been running sid on my work laptop.
5 year at work and at home 😉
If you use SID give a watch to SMXI a tool developed by H2.
some links:
home of smxi: http://www.smxi.org
support forum: http://techpatterns.com/forums/forum-33.html
smxi on distro watch
http://distrowatch.com/weekly.php?issue=20090406#donation
Thanks im trying out Sid now
I got a question tho, why is it if i want to just until uninstall Brasero, it trys to uninstall everything else like gnome & gnome-desktop. This doesnt happen in ubuntu.
http://img524.imageshack.us/img524/2193/workspace1001d.png
Another question, if i try to uninstall tomboy, why does it want to install gnote? And Vice Versa. I dont want any of these programs. I just want to uninstall.
http://img405.imageshack.us/img405/5662/workspace1003.png
Same thing happens it i try to uninstall OpenOffice, it goes and replaces it with Abiword.
If this is how Debian is … Then Debian blows.
Thanks if u can help
Hi Bonster, comments in this blog post are not the best way to get support. You might want to ask on user mailing lists like debian-user@lists.debian.org.
brasero is part of the default Gnome installation, so if you remove it, you have to remove the meta-packages gnome and gnome-desktop-environment at the same time. Since those packages are the one that “pulls” all the desktop-oriented packages, when they get removed, all the desktop-oriented package are marked as being not needed anymore.
The same metapackages have “alternative” dependencies, they depend on “either gnote or tomboy”, and “openoffice.org or abiword”, so if you remove one, it will prefer to install the alternative version as opposed to removing the meta-package entirely.
You want to look into “apt-mark unmarkauto” to tell APT which package you want to keep before removing the meta-packages gnome and gnome-destkop-environment.
Silly question, but can’t you just pin ~prequired and ~pimportant packages to stable in order to guarantee that you’ll boot-up to a working shell environment in all cases? AFAIK, breakages in other packages are less critical and could be dealt with so long as you can “work” with the pc….
Good idea.
It is not possible to use “~p” in the apt_preferences file though, is it?
Would then probably require a script to add stanzas for every matched file once.
I am a Linux Desktop User, not an expert. At home, I am working on two notebooks. The older one is running Debian Testing, the other Aptosid.
No real problems until today. I like the rolling release thing, for me, its comfortable.
Saying that other distrubutions are based on sid is a point against it; one of the things I hate about Ubuntu is their lack of QA on the many packages they blindly import from Debian.