Certainly. Wheezy is the new "stable", which will get security support for a year past the introduction of the next stable release. It's an excellent choice for servers, and right now it's not a bad desktop release.
In another year or so you might want to move to the testing release for a desktop that needs the latest features.
Debian testing won't have "the latest features" a year from now, though. I guess it'll have "later features", but IME desktops really benefit from tracking unstable. Which, as one might expect, is sometimes...unstable. Enter Ubuntu.
There's a pretty good reason to use Debian on servers because of the long support cycles, but on a desktop I feel like most people are going to probably prefer an Ubuntu setup.
Once, this was a valid comparison (Ubuntu/Sid). Now Ubuntu is a strange beast, a world apart from other distros in goals and just in the basic desktop experience.
aptosid is probably a better choice if you want a more stable Sid these days without the Ubuntu kaleidoscope.
I have used unstable as my main desktop for over a decade now.[1] At first there were occasional issues but these went away as I became more experienced with debian. It has been years since I encountered a bug that caused me to lose more than an hour of productivity. The most recent issue that I have had with unstable was over a year ago and it was simply a matter of pinning a version of libcairo. The only reason I remember this so well is that someone else on HN was having trouble and my comment[2] on how to fix it was my highest rated comment at the time.
[1] To be honest I actually run a mixed system with a few packages (not just oneoffs but big things like xmonad/iceweasel/awesome/git/pandoc/git-annex/gitit) from experimental. If it has been a long time (5-7 years) since you tried unstable you can think of experimental as what unstable used to be.
Debian has historically run on an approximately 2-year release cycle (and more recent releases have been closer to that cadence). Right now, Testing is kind of old, because it's been frozen in the run-up to the Wheezy release. In a month or two, Testing will probably be mostly current, and will stay that way until about 18 months' time when the Jessie freeze kicks in, and then it'll be a slow wait until the release of Jessie and then the cycle repeats.
Ubuntu is too... opinionated for my tastes, and other distros are too conservative (CentOS/RHEL) or too wild (Arch, Gentoo). Debian Testing seems to have a high-quality, comprehensive package archive and keep reasonably up-to-date, and if the price to pay is that for six months every two years you get a stable desktop environment instead... no complaints from me.
EDIT: The usual lag between Testing and Unstable is 10 days, except in big, complicated transitions and dependencies (say, when a commonly used shared library is being upgraded to a new, incompatible ABI). Again, I could probably be more up-to-date if I tracked Unstable instead of Testing, but I'd rather wait for Debian to nail down its migration plan in Unstable so I can upgrade smoothly, rather than have the latest and greatest and have to rebuild my own packages occasionally.
Just make sure you're not on "testing" if you're doing this for a desktop (note that it is uncommon to run "testing" on a server). This release means that Sid ("unstable") just became "testing". Now, many folks are running Sid fine on their desktops, but historically the Sid -> testing push is volatile in the short term, and you probably would want to wait a couple weeks.
I would think Testing is pretty much safe, since all the new packages have to live a bit in Sid (10 days by default) before they reach Testing, so they get some testing. The only issue I know with Testing is temporary removals of some packages to help with these transitions.
I'm not, because I find Debian's KVM support to be not what I expect, but if you don't like Ubuntu for whatever reason, it's not a bad time to do it. That said, Debian stable means you'd better be happy with what you have for a very long time unless you want to deal with the often-painful stable->testing or stable->unstable migration. (It can be done, I've done it many times, but expect it to break something.)
Personally, I just use Ubuntu. It's Debian unstable but shinier. :)
I'm unable to determine if you mean upstart to be a Good Thing, or a Bad Thing, or anything in between.
To me, switching back from Ubuntu to Debian was a blessing. And I simply cannot understand this need to decrease boottimes. My laptop boots into Debian under 12 seconds. That is pretty fast. Under Ubuntu, I timed it at 10 seconds.
2 seconds boottime? Is that what this upstart/systemd hastle is all about? I just do not get that.
""Well, let's say you can shave 10 seconds off of the boot time. Multiply that by five million users and thats 50 million seconds, every single day. Over a year, that's probably dozens of lifetimes. So if you make it boot ten seconds faster, you've saved a dozen lives. That's really worth it, don't you think?" "
I don't know. I mean, the trend has been hand-held devices and laptops for the past decade or so. They don't get booted every day and will be less and less. All the while, devices are getting faster hardware, making the difference even less.
Too me, it still seems not worth breaking a working standard (SysV) over.
Debian has a long release cycle and uses the stablest versions available - and I believe that 3.2 is a "long term support" kernel, like 2.6 - getting large numbers of patches, and stability updates backported.
But Red Hat used to (they probably still do) continuously backport a lot of drivers an functionality from newer kernels to their older, stable, kernel for the first 5.5 years after a release:
Debian's 3.2 kernel includes backported support for much newer hardware from more recent kernels. Debian's primary kernel maintainer, Ben Hutchings, also serves as the upstream maintainer of the 3.2 stable kernel series.
And that I think is the biggest problem of Debian. They aim stability but how can you possibly claim that your custom backports are stable when e.g. the original developers have stopped supporting it?
They may be able to pull it off with the kernel, but they can't possibly do it for all their packages. As an example: How are the Django backports to 1.2 more stable than upgrading to 1.3 when the official Django project has stopped supporting 1.2?
Who says the original developers stopped supporting it? Head on over to http://www.kernel.org and you'll see that 3.2 has longterm support (ie the kernel developers backport relevant fixes and patches). There are more details at https://www.kernel.org/releases.html including end of life dates. Given the time span between Debian releases, 3.2 is an excellent choice, if not the only one.
Since the release of Django 1.4, version 1.2 stopped receiving security fixes by the Django development team. What that means is that a Debian maintainer (which probably is not a Django developer) would have to hack any new security fix into the unsupported 1.2. And this is deemed more stable than say, upgrading to 1.3.
Note that Django is just an example, obviously there are many more packages with the exact same problem.
If the Debian maintainer has any idea what he’s doing, then this is likely to be more stable than upgrading to a new release that introduces new features and possibly incompatibilities. Fortunately, most Debian maintainers have a very good idea of what they’re doing.
Likely yes. But if I had to choose between the original developers and someone that has to maintain 20 different packages, I will chose the original developers.
I imagine few maintainers to maintain 20 different packages, and if they do, they are likely related in some way – and then I trust a Debian maintainer more to gauge the impact of a new version on the system than some upstream maintainer, who likely even uses some other distribution.
How is it not an apt comparison? What pip would do in this case is bypass apt and install the latest version of Django and its dependencies. If I'm going to do that I might as well build the database and server from source too to have the latest versions. But then why am I using Debian?
Isn't that the way it should be? Especially in a production environment - not upgrading unless you're sure your core packages don't break your product?
You seem to be missing my original point. My understanding is you want to run the latest and greatest python, best practice is pretty much to use pip & virtualenvs(I'm not a python dev, so don't quote me on that). If you want stable, use the debian packages with security updates. Best of both worlds, like I said, but it's an either/or choice.
Besides missing the origianl point, comparing pip to tarballs just seems wrong. One is pretty much manual, the other is via a package manager, albiet not the distro specific package manager, but one specific to the domain you are working within.
"But then why am I using Debian?"
Personally, I tend to stick with everything from debian direct, but there are lots of domain specific developers who'd rather have the up-to-date stuff and I can't entirely fault their desire when we're talking about real world benefits of new versions. You still benefit from the stable base even if you want to run something up-to-date. You don't see the benefit of that?
Going forward from that, you can still pip in specific versions, update projects seperatly, and obviously test them before doing so, so while you may lose some advantages, living in a specific pip world doesn't seem like the end of the world to me, as long as there's a positive reason for doing so.
"stable" does not necessarily mean "better"; In the case of Debian, it can mean "unchanging"... that is you can rely on it to not break your software even if you keep it ("stable") updated.
Security fixes that addresses issues in 1.2 will be back-ported from 1.4 by either A) upstream, or if that fails B) the Debian maintainer, or if that also fails, C) Debian security team. Thats the promise made by The Debian security team which cover the latest stable major release, and for the prior stable release for one year.
And it works. Most of all fixes are done by A or B, but the promise is one which the security team takes very serious. For one release, the security team backported security updates for 4 years. A achievement of taking responsibility in a "open source" project if I ever saw one.
I used to be all for the way backports are handled, until I had an excruciating experience with a perl module recently (the Locale::Maketext vulnerability). 1.19 is vulnerable, so they "backported" the CVE change, without realizing that this means their franken-1.19 version is exactly the same code now as the latest 1.23. All that's different is the POD and $VERSION.
Which sucks, because application software needs to handle environments with Locale::Maketext 1.19 differently to environments with 1.23, else you get double-escaping bugs.
The response? Reporting the actual, correct module version (or god forbid, sync the comments/POD as well) instead of the incorrect, unchanged version number "would break stuff". As opposed to incorporating a breaking API change without bumping module version, which also breaks stuff... Ouch.
I guess I only have myself to blame, I should be more involved with debian maintenance of packages I care about.
That's one of the reasons why I try to get as much software from the actual developers as possible, instead of relying on packages maintained by [Debian|Ubuntu|Red Hat|...].
Obviously this is a lot of work (patches, managing dependencies, ...) if you do it for everything, but if you stick to the most important packages (e.g. nginx for your webserver, postgres for your db server, ...) I think it's manageable and will give you a lot of benefits.
(Thinking about the Debian OpenSSL fiasco a few years ago, I guess one could make an even stronger argument, though to be fair it was a pretty extreme case and I don't think anything like that has happened since back then.)
//Edit: I got curious about the OpenSSL issue from 2008 and it turns out that the Debian maintainers weren't solely responsible for the bug[0].
So then run ArchLinux on your servers, and godspeed? Debian is not aimed at having the latest and greatest, but its packages do tend to be more up-to-date than RHEL/CentOS, which is its main competition in the "stable server distro that doesn't get you fired" category.
This is silly. Debian also provides rolling releases, testing and unstable. The release cycle is slow only if you ignore the constant development of Debian Sid.
Unbearable for you perhaps. However, those of us with more than a few machines to look after appreciate the glacial pace and the full support of their stable platform.
Change (well, poorly managed change) causes instability and issues. Debian has proven that they can manage change in their distribution and it makes everyones life easier.
Use Debian testing for the desktop. Desktop users don't use stable, or at least use it with backports. And what's so unbearable for the server? As others pointed out, RHEL ships even an earlier version of the kernel.
My mum is quite happy with Debian stable on her desktop, and I don’t plan to switch from Wheezy to Jessie on my laptop for a while either. What’s wrong with stable on desktops?
Nothing if the software versions available are adequate for your use. Enjoy.
I've been using CentOS 5.9 on a desktop quite happily, I just compiled R from source to get a more recent version. Worth mentioning that Iceweasel (aka Firefox) was on the ESR channel so getting updates fairly regularly.
Testing is sometimes problematic from a security POV. Since it's considered a staging area rather than a "proper" distribution, it isn't security-managed, and occasionally vulnerabilities can persist for an extended period of time.
The most common case:
v1 of a package is in Debian stable. v2 comes out, is uploaded to unstable, migrates to testing. Later, v3 comes out, is uploaded to unstable, but its migration to testing is temporarily blocked because it's waiting on a major upgrade, like a new libc version, to make it into testing, which typically is done in a carefully coordinated way.
Now a security issue is found affecting all versions of the package. The upstream will (hopefully) release a patched v3, which will immediately go into unstable. The Debian security team will backport the patch to v1, and make it available to Debian stable users on security.debian.org. But testing is still distributing a vulnerable v2. There is typically no process to specifically patch v2 just for testing, because testing is staged via migrations from unstable; the usual situation is just to wait for blockage to clear and for v3 to migrate. There are occasional exceptions, mostly near releases: if it's determined that v3 won't be able to migrate before the next stable, a specially patched v2 may be uploaded to testing to get it into the next stable.
That scenario doesn't happen that often, but it's worth being aware that testing can lag behind both stable and unstable in security updates.
Doing a bit more research, it looks like my info is out of date. There used to be a warning about it on the Debian website (I think that's where I originally got the admonition that testing may have security gaps), but the current website actually says that it is security-managed, with security.debian.org uploads done in cases where migration from unstable is held up: http://www.debian.org/security/faq#testing
You can expect most bugs in 3.2 has been fixed so it's very stable. Old doesn't mean unmaintained. Debian's kernel developer Ben Hutchings has been backporting for 3.2 for a long time with lots of security fixes and hardware enablement. In comparison, RHEL 6 uses 2.6.32 with lots of selected stuff backported. This development model avoids new random features introducing bugs.
Also, you can have newer kernels in the debian backports repo.
Congratulations to everyone involved. I've been running wheezy on my home server for a while now (/var/www moved to /srv, apt diffs package lists...) and i look forward to upgrading the production servers over the coming months.
As an aside, it's really interesting that the word 'Linux' is mentioned only once on this page - and only after the kFreeBSD kernel.
/srv will continue to be ignored just as /opt and other one-offs are ignored. Reason being that they duplicate existing functionality, in this case under /var, /usr, or /usr/local. What /srv/ really stands for is NIH.
/opt is basically for 3rd parties to install software, because they can't be trusted to behave and integrate with the regular filesystem. The last thing you want is Oracle farking around with anything under /usr or /var, because they will fuck up your entire OS for their benefit alone. That is why /opt exists, in my understanding.
/srv is a bit questionable to me. Basically it's another /var. I always used directories like /var/local and /var/share (sambd and nfs shares). However, I am understanding the FHS crew wants to freeze the /var filesystem because it was getting too crazy with all kinds of stuff being placed under /var, and the likelihood of conflicts was getting high.
/usr/local is meant to replicate /usr in the way that binaries go into /usr/local/bin, libraries into /usr/local/lib etc., but for software that isn’t managed by the package manager – at least that’s what it is used for nowadays. So a well-behaving software would happily go into /usr/local, whereas the ugly software things that want their own folder somewhere better go into /opt.
I also prefer having packages with their own hierarchies under /opt, rather than /usr/local/<package> -- in general stuff under /usr/local should put their binaries in /usr/local/bin -- their manpages under /usr/local/share/man, headers and libraries in the corresponding places -- so that I don't have to mess with my PATH settings to be able to run a command, look up a man page or link against a library.
Sometimes software isn't packaged for use on a posix-like system -- and then I might have to do some dancing to get it to work -- I usually prefer having such programs under /opt/<program-version>.
I do have another folder under local: /usr/local/xstow -- so I can easily compile packages and manage different versions under /usr/local/xstow/package-x.y.z.
Because, maybe, but only maybe, there might be software that is not split up into lib, bin, doc directories and that doesn't log into /var/log?!
There actually is quite some software like that and sometimes it even has a technical reason.
Especially some commercial and proprietary software that runs on Windows, HP-UX, SCO, AIX, Solaris and Linux tends to go the "easy way" of packaging and just put stuff in one place on every system.
And how does your point lead to the conclusion that installing such third-party software to /usr/local/whatever is a bad idea? I can just run 'ls /usr/local' to see a list of non-conforming software.
I didn't say it's a bad idea, i said it's a matter of fact that software exists that runs in /opt/ and that sometimes there are reasons to do so. For example, a particular usecase is to have a specific mountpoint that holds shared binary and configuration in a cluster environment that can't be mixed with native applications and configuration files. Also sometimes you don't have the user rights to install in /usr or policy forbids to install 3rd party software in /usr. /opt is the usual way to go then.
/usr/local is the tertiary hierarchy per the FHS, by this naming, there should be no whatever there other than bin/lib/shared/... just like on the primary and secondary hierarchies, whereas /opt is the wild wild west, often organised by software package (/opt/android-sdk), even with side by side versions (/opt/ree-2012.02), or by vendor (e.g /opt/oracle/java-7-sdk).
This is merely a convention, not set into the 2.3 standard apart from the naming 'tertiary hierarchy' otherwise implying this, but it's nonetheless a widespread enough convention — notably in use by every single configure/make/make install (and more) source distribution out there, whose default PREFIX is /usr/local — that we can expect it to be standard behavior.
/opt is a tradition inherited from older commercial unixes like SCO, AT-T et al. Made popular in the later days mainly by solaris 2 heavy usage of /opt.
Most vendor supplied software is by tradition installed in /opt, for which we should be forever thankful because most software vendor wouldn't recognize a properly packaged piece of software even if it jumped up and bit them in their arse.
Oracle was in the early days installed in /u01 with data- and log-files spread out over separate disks with mountpoints normally named /u02,/u03 and so forth. It isn't uncommon that this naming convention still partially is used on oracle installations.
Today oracle published a standard called Optimal Flexible Architecture (OFA) where all oracle products should be installed under a common top-level directory.
The oracle universal installer isn't as horrible as it used to be but it isn't a well behaved rpm/dep installation either, at least it claims to have heard about LSB-directory structure even if it doesn't follow it very well.
The docroot path? That would indicate the Ubuntu devs who chose this location had little or no sysadmin experience. Files and dirs under /usr should not be mutable, that's what /var is for.
At least they didn't locate it on the root directory. Mount points should never be on root. See the sources for stat() for the main reason why not.
I don't understand. I have /boot, /home and sometimes /srv in a different partition. I don't know of any other way to accomplish that without using putting mount points on root, unless you mean additional, non-FHS mount points...
>I have /boot, /home and sometimes /srv in a different
>partition. I don't know of any other way to accomplish
>that
/boot is typically located on the same disk as root, so that should be ok. /srv and /home, however, would be problematic root mounts. You can use automount to fix /home but /srv should be mounted under /usr or /var.
Mounting NFS or busy disks on the root dir is not a good idea on any server where filesystem i/o performance is an issue.
Personally, I would prefer Debian to Ubuntu-LTS on servers. The primary advantage of Ubuntu over Debian is access to more recent package versions, and LTS surrenders most of that advantage in an attempt to approach Debian's reliability. Besides, most use cases for servers don't require bleeding-edge packages as long as the distribution is backporting security fixes.
I wouldn't worry about LXC support; it's fairly old tech by now, and even the previous stable version of Debian supports it. LXC in Wheezy should work just fine.
The only major issue I can think of with putting servers on Debian is their very very old kernel versions. The kernel in Wheezy is missing a lot of recent optimizations in the networking and filesystem code, and doesn't support user namespaces (important for container-based virtualization).
I prefer Ubuntu LTS nowadays. Debian's support for AppArmor and SELinux is still broken and it doesn't look like they're going to fix it any time soon. On Ubuntu they seem to work fine.
We run ubuntu servers, but I'm thinking of changing over to debian. Ubuntu is a moving target with its 6-mo releases - every release has a new method for doing foo. For the 12.04 LTS, it's packages don't get version updates just like debian - meaning if you want something more recent you have to step in and install them yourself. So may as well just run debian in that case.
Ubuntu has a stronger desktop community when you run into problems (largely due to scale), but debian has a strong server community. And the Debian Way of doing things usually stays the same way for years for a given subsystem - google providing advice from 2009 is likely to still be helpful. The ubuntu philosophy... not so much. A colleague wanted to turn off thin scrollbars in the ubuntu desktop, and found that for the last four 6-mo releases, there were four separate ways to do this...
But, on the other hand, ubuntu LTS is better supported by a lot of vendors (eg AWS has an official ubuntu AMI, but no Debian one). It depends on your use case, I guess.
My sources.list has the word "testing" all this while. Should I change it to "wheezy" now? I'm asking because I guess new packages (in large numbers!) will start trickling down to testing/jessie and the possibility of breakage is high. What is a reasonable time to expect this "rush" to slowdown or come back to the pace of "normal" testing?
I can probably live with my existing "testing" for say 1-2 months, after which I would like newer packages.
I'd say switch the sources.list to 'stable' or 'wheezy' for a few weeks. After that, switch back to 'testing' and run "apt-get dist-upgrade --assume-no" and see what Debian is going to upgrade.
There is no real proper way to do this, other than testing in a VM, or a chroot.
FWIW, I've been running Debian "testing" on my machine since 2001-ish and I've never done anything special near releases. Except maybe rejoice at all the old packages finally getting upgraded. :-)
Didn't you run into any breakage of packages? I mean there's this mad rush into testing right after a new release. I'm thinking of running wheezy for a couple of months until the storm calms down.
I've found the Debian package maintainers to be quite careful, even when there's a large amount of rapid change to testing. I think they put a lot of effort and thought into avoiding breakage, even in scenarios like this. Any time I've encountered broken packages, the problem has been resolved quite quickly, especially if more important and widely-used packages are involved.
I'm using a mix between unstable and Mint for a Steam box (games, music, movies, web) and found out the label must be mistaken. It's a minimal installation, but everything from ATI drivers to multi-arch support worked perfectly out of the box. It already went through several dist-upgrades without any manual intervention (except maybe a couple of "yes/no" questions).
When did you install? Testing/Unstable are relatively quiet during a freeze, so just wait till everybody realises that Wheezy is out and you should get plenty of breakage :)
Several months ago... what you say makes sense, should I expect generally less breakage than Ubuntu or more? I wouldn't like having to install Ubuntu, mostly because it's too difficult to manage and troubleshoot...
For those running testing (or sid/experimental) I highly recommend apt-listbugs -- it will list (critical) bugs related to packages you're about to upgrade/install -- and allow you to back out. Often you can just hold off a few days, and some hardworking Debian volunteer will have made the problem go away -- before you need to experience it.
A couple weeks is probably long enough. Time for the flood of new packages to come in and anything broken to get reported and fixed. It doesn't take that long as lots of people use testing.
i had to install a testing snapshot May 4 because wasn't sure when they were releasing stable wheezy, and needed it immediately.
only package that broke the next day after full dist-update was "less" which for some reason will not co-exist with man-db. that was it though everything else updated fine
I used to run Debian on a PowerPC Mac as my main desktop system and today I still use a "portable server" Palm Pre Plus running Squeeze chroot on a regular basis. In my experience Debian is really great on non-x86 hardware. Too bad the old webOS kernel means I won't be able to upgrade it to Wheezy, at least not easily.
That said, I wish Debian would compete with Ubuntu LTS on longer support for OldStable. (Ubuntu LTS releases are now supported for five years [1] while a Debian Stable release is expected to get three years of support [2].)
I'm not sure where you got three years support bit from (could you point me?) Linked from the DebianReleases page you listed:
Q: How long will security updates be provided?
A: The security team tries to support a stable distribution
for about one year after the next stable distribution has been
released, except when another stable distribution is released
within this year. It is not possible to support three
distributions; supporting two simultaneously is already
difficult enough.
It's interesting to see Iceweasel 10 on this list with a renewed perspective. I was doing some web development last week and spent some hours chasing after an audio latency problem when using HTML5 audio on Iceweasel/Firefox 10. It turns out that according to my web server logs, nobody uses versions that old, and when I tried using a newer version I discovered that the bugs simply don't manifest.
So I recommend to Debian users who use Iceweasel: install a newer version. You can get it directly from Debian Iceweasel maintainers, and instructions are available at: http://mozilla.debian.net
131 comments
[ 3.1 ms ] story [ 176 ms ] threadIn another year or so you might want to move to the testing release for a desktop that needs the latest features.
There's a pretty good reason to use Debian on servers because of the long support cycles, but on a desktop I feel like most people are going to probably prefer an Ubuntu setup.
aptosid is probably a better choice if you want a more stable Sid these days without the Ubuntu kaleidoscope.
[1] To be honest I actually run a mixed system with a few packages (not just oneoffs but big things like xmonad/iceweasel/awesome/git/pandoc/git-annex/gitit) from experimental. If it has been a long time (5-7 years) since you tried unstable you can think of experimental as what unstable used to be.
[2] https://news.ycombinator.com/item?id=3907796
Ubuntu is too... opinionated for my tastes, and other distros are too conservative (CentOS/RHEL) or too wild (Arch, Gentoo). Debian Testing seems to have a high-quality, comprehensive package archive and keep reasonably up-to-date, and if the price to pay is that for six months every two years you get a stable desktop environment instead... no complaints from me.
EDIT: The usual lag between Testing and Unstable is 10 days, except in big, complicated transitions and dependencies (say, when a commonly used shared library is being upgraded to a new, incompatible ABI). Again, I could probably be more up-to-date if I tracked Unstable instead of Testing, but I'd rather wait for Debian to nail down its migration plan in Unstable so I can upgrade smoothly, rather than have the latest and greatest and have to rebuild my own packages occasionally.
All of these have a channel for installing the latest version of their software without having to dist-upgrade.
XFCE hasn't had a notable UI change in years (at least not discernable to me). KDE and GNOME have only mucked things up over the last decade.
Basically, be wary of "testing" after a release.
http://www.debian.org/releases/testing/
Otherwise you're right - now it probably not the best time to switch to jessie/testing.
Personally, I just use Ubuntu. It's Debian unstable but shinier. :)
To me, switching back from Ubuntu to Debian was a blessing. And I simply cannot understand this need to decrease boottimes. My laptop boots into Debian under 12 seconds. That is pretty fast. Under Ubuntu, I timed it at 10 seconds.
2 seconds boottime? Is that what this upstart/systemd hastle is all about? I just do not get that.
http://www.folklore.org/StoryView.py?story=Saving_Lives.txt
Too me, it still seems not worth breaking a working standard (SysV) over.
P.S. Mint provides only Firefox.
Zenwalk 7.2 has the 3.2.5 kernel.
What's the point of citing the kernel shipped with another distro here?
The tone of the top-level comment, I think, is "woah, Debian, you call this kernel updated?"
Rock-solid distros like RHEL/CentOS and Debian are deliberately conservative. Some folks don't like that.
https://access.redhat.com/support/policy/updates/errata/
So I don't think RHEL/CentOS can be compared here to Debian.
They may be able to pull it off with the kernel, but they can't possibly do it for all their packages. As an example: How are the Django backports to 1.2 more stable than upgrading to 1.3 when the official Django project has stopped supporting 1.2?
Since the release of Django 1.4, version 1.2 stopped receiving security fixes by the Django development team. What that means is that a Debian maintainer (which probably is not a Django developer) would have to hack any new security fix into the unsupported 1.2. And this is deemed more stable than say, upgrading to 1.3.
Note that Django is just an example, obviously there are many more packages with the exact same problem.
But if that works for you, then great :-)
Besides missing the origianl point, comparing pip to tarballs just seems wrong. One is pretty much manual, the other is via a package manager, albiet not the distro specific package manager, but one specific to the domain you are working within.
"But then why am I using Debian?"
Personally, I tend to stick with everything from debian direct, but there are lots of domain specific developers who'd rather have the up-to-date stuff and I can't entirely fault their desire when we're talking about real world benefits of new versions. You still benefit from the stable base even if you want to run something up-to-date. You don't see the benefit of that?
Going forward from that, you can still pip in specific versions, update projects seperatly, and obviously test them before doing so, so while you may lose some advantages, living in a specific pip world doesn't seem like the end of the world to me, as long as there's a positive reason for doing so.
And it works. Most of all fixes are done by A or B, but the promise is one which the security team takes very serious. For one release, the security team backported security updates for 4 years. A achievement of taking responsibility in a "open source" project if I ever saw one.
Which sucks, because application software needs to handle environments with Locale::Maketext 1.19 differently to environments with 1.23, else you get double-escaping bugs.
The response? Reporting the actual, correct module version (or god forbid, sync the comments/POD as well) instead of the incorrect, unchanged version number "would break stuff". As opposed to incorporating a breaking API change without bumping module version, which also breaks stuff... Ouch.
I guess I only have myself to blame, I should be more involved with debian maintenance of packages I care about.
Obviously this is a lot of work (patches, managing dependencies, ...) if you do it for everything, but if you stick to the most important packages (e.g. nginx for your webserver, postgres for your db server, ...) I think it's manageable and will give you a lot of benefits.
(Thinking about the Debian OpenSSL fiasco a few years ago, I guess one could make an even stronger argument, though to be fair it was a pretty extreme case and I don't think anything like that has happened since back then.)
//Edit: I got curious about the OpenSSL issue from 2008 and it turns out that the Debian maintainers weren't solely responsible for the bug[0].
[0]: http://research.swtch.com/openssl
Change (well, poorly managed change) causes instability and issues. Debian has proven that they can manage change in their distribution and it makes everyones life easier.
I've been using CentOS 5.9 on a desktop quite happily, I just compiled R from source to get a more recent version. Worth mentioning that Iceweasel (aka Firefox) was on the ESR channel so getting updates fairly regularly.
The most common case:
v1 of a package is in Debian stable. v2 comes out, is uploaded to unstable, migrates to testing. Later, v3 comes out, is uploaded to unstable, but its migration to testing is temporarily blocked because it's waiting on a major upgrade, like a new libc version, to make it into testing, which typically is done in a carefully coordinated way.
Now a security issue is found affecting all versions of the package. The upstream will (hopefully) release a patched v3, which will immediately go into unstable. The Debian security team will backport the patch to v1, and make it available to Debian stable users on security.debian.org. But testing is still distributing a vulnerable v2. There is typically no process to specifically patch v2 just for testing, because testing is staged via migrations from unstable; the usual situation is just to wait for blockage to clear and for v3 to migrate. There are occasional exceptions, mostly near releases: if it's determined that v3 won't be able to migrate before the next stable, a specially patched v2 may be uploaded to testing to get it into the next stable.
That scenario doesn't happen that often, but it's worth being aware that testing can lag behind both stable and unstable in security updates.
Sorry for the misinformation!
I just found from your link that I had no security repo configured. Just added:
deb http://security.debian.org testing/updates main
UPDATE: Here is a more correct set of settings from http://secure-testing-master.debian.net/ :
deb http://security.debian.org testing/updates main contrib non-free
deb-src http://security.debian.org testing/updates main contrib non-free
Even though they claim that contrib and non-free have no security updates, they are listed for some reason.
http://www.debian.org/vote/2013/platforms/lucas
I hope they'll tackle this security issue.
Also, you can have newer kernels in the debian backports repo.
As an aside, it's really interesting that the word 'Linux' is mentioned only once on this page - and only after the kFreeBSD kernel.
nginx on ubuntu now uses /usr/share/nginx/www
i wonder how long these conventions will continue to be all over the place.
Unfortunately, /srv/ is often ignored. Good move by Debian to make this change, and hopefully this gets the ball rolling for other distros.
/srv is a bit questionable to me. Basically it's another /var. I always used directories like /var/local and /var/share (sambd and nfs shares). However, I am understanding the FHS crew wants to freeze the /var filesystem because it was getting too crazy with all kinds of stuff being placed under /var, and the likelihood of conflicts was getting high.
But I think /srv actually makes more sense as /var is often on separate disks because /var/lib/ gets very IO heavy.
I also prefer having packages with their own hierarchies under /opt, rather than /usr/local/<package> -- in general stuff under /usr/local should put their binaries in /usr/local/bin -- their manpages under /usr/local/share/man, headers and libraries in the corresponding places -- so that I don't have to mess with my PATH settings to be able to run a command, look up a man page or link against a library.
Sometimes software isn't packaged for use on a posix-like system -- and then I might have to do some dancing to get it to work -- I usually prefer having such programs under /opt/<program-version>.
I do have another folder under local: /usr/local/xstow -- so I can easily compile packages and manage different versions under /usr/local/xstow/package-x.y.z.
http://xstow.sourceforge.net/
Especially some commercial and proprietary software that runs on Windows, HP-UX, SCO, AIX, Solaris and Linux tends to go the "easy way" of packaging and just put stuff in one place on every system.
This is merely a convention, not set into the 2.3 standard apart from the naming 'tertiary hierarchy' otherwise implying this, but it's nonetheless a widespread enough convention — notably in use by every single configure/make/make install (and more) source distribution out there, whose default PREFIX is /usr/local — that we can expect it to be standard behavior.
Similarly for /srv
Remember: the filesystem hierarchy and your underlying storage don't have to correspond.
There are other tricks which can be accomplished by union mounts or similar foolishness.
Most vendor supplied software is by tradition installed in /opt, for which we should be forever thankful because most software vendor wouldn't recognize a properly packaged piece of software even if it jumped up and bit them in their arse.
Oracle was in the early days installed in /u01 with data- and log-files spread out over separate disks with mountpoints normally named /u02,/u03 and so forth. It isn't uncommon that this naming convention still partially is used on oracle installations.
Today oracle published a standard called Optimal Flexible Architecture (OFA) where all oracle products should be installed under a common top-level directory.
The oracle universal installer isn't as horrible as it used to be but it isn't a well behaved rpm/dep installation either, at least it claims to have heard about LSB-directory structure even if it doesn't follow it very well.
At least they didn't locate it on the root directory. Mount points should never be on root. See the sources for stat() for the main reason why not.
/boot is typically located on the same disk as root, so that should be ok. /srv and /home, however, would be problematic root mounts. You can use automount to fix /home but /srv should be mounted under /usr or /var.
Mounting NFS or busy disks on the root dir is not a good idea on any server where filesystem i/o performance is an issue.
I wouldn't worry about LXC support; it's fairly old tech by now, and even the previous stable version of Debian supports it. LXC in Wheezy should work just fine.
The only major issue I can think of with putting servers on Debian is their very very old kernel versions. The kernel in Wheezy is missing a lot of recent optimizations in the networking and filesystem code, and doesn't support user namespaces (important for container-based virtualization).
Ubuntu has a stronger desktop community when you run into problems (largely due to scale), but debian has a strong server community. And the Debian Way of doing things usually stays the same way for years for a given subsystem - google providing advice from 2009 is likely to still be helpful. The ubuntu philosophy... not so much. A colleague wanted to turn off thin scrollbars in the ubuntu desktop, and found that for the last four 6-mo releases, there were four separate ways to do this...
But, on the other hand, ubuntu LTS is better supported by a lot of vendors (eg AWS has an official ubuntu AMI, but no Debian one). It depends on your use case, I guess.
I can probably live with my existing "testing" for say 1-2 months, after which I would like newer packages.
There is no real proper way to do this, other than testing in a VM, or a chroot.
Note that if you have pinning rules, then there you must also change "testing" to "wheezy".
only package that broke the next day after full dist-update was "less" which for some reason will not co-exist with man-db. that was it though everything else updated fine
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695361
I used to run Debian on a PowerPC Mac as my main desktop system and today I still use a "portable server" Palm Pre Plus running Squeeze chroot on a regular basis. In my experience Debian is really great on non-x86 hardware. Too bad the old webOS kernel means I won't be able to upgrade it to Wheezy, at least not easily.
That said, I wish Debian would compete with Ubuntu LTS on longer support for OldStable. (Ubuntu LTS releases are now supported for five years [1] while a Debian Stable release is expected to get three years of support [2].)
[1] https://wiki.ubuntu.com/LTS
[2] http://wiki.debian.org/DebianReleases
http://www.debian.org/releases/wheezy/amd64/release-notes/ch...
... software packages which are already outdated.
See also: "Issues to be aware of for wheezy" (http://www.debian.org/releases/wheezy/amd64/release-notes/ch...).
So I recommend to Debian users who use Iceweasel: install a newer version. You can get it directly from Debian Iceweasel maintainers, and instructions are available at: http://mozilla.debian.net