Today is Debian 8 release day
release.debian.org
release.debian.org
On a side note, just last night I was watching a video of Linus at DebianConf where he talked a bit about solving the linux desktop problem (https://www.youtube.com/watch?v=1Mg5_gxNXTo). Its great that SteamOS is building on top of Debian and I'm exited to see what effects this will have towards making distribution of cross-linux-distro apps easier for developers. I think the fact that valve is on Linux is going to have a big impact on providing distros that non-technical users can easily enjoy.
Anyways, thanks again :)
looks like jessie is going to be the first debian stable to be released with rc-critical issues and not "when it's done"
some of the bugs referred [2] seem quite critical indeed, maybe someone with more insight could comment on this?
[1] http://richardhartmann.de/blog/posts/2015/04/24-Debian_Relea...
[2] https://udd.debian.org/bugs.cgi?release=jessie_and_sid&patch...
https://bugs.debian.org/release-critical/
Any idea why they have gone with this?
Oh, yeah, that's Debian's systemd release.
> Oh, yeah, that's Debian's systemd release.
These are the bugs that are relevant when talking about the Jessie release: https://udd.debian.org/bugs/?release=jessie_not_sid&merged=i...
None of them are filed against systemd. I've been watching this page daily for the last month, and I only remember one systemd-related bug being filed in that time (there was one longstanding one from March affecting a rather obscure use case that sat there for a while as well, but was fixed).
But there are bugs in systemd integration if you look closely (hdparm resume issue and kde battery low issue are the ones which are on top of my mind.)
edit: Also you're looking at the wrong list :) Jessie is being released with these [0] RC bugs, and those [1] are the ones which are not fixed in jessie and sid.
[0]: https://udd.debian.org/bugs.cgi?release=jessie&merged=ign&rc...
[1]: https://udd.debian.org/bugs.cgi?release=jessie_and_sid&merge...
(This assumes that Debian doesn't decide to declare Wheezy as a new LTS release once support for Squeeze ends in February 2016... AFAIK it's not clear what their plans are there.)
Unfortunately many distros have already jumped on the systemd wagon but I think soon there will be a increasing collection of non-systemd alternatives which will continue to follow the KISS principle which made Unix and Linux so great. There already _are_ alternatives to systemd and systemv -- launchd and upstart (used by ChromeOS) for instance.
I hope soon we will have an init system which takes the best of all current ones while still following the KISS principle. Linux must keep this principle alive unless it will probably fall into the trap of Windows' monolithic bug hell. Ironically Linux 3.11 kernel was already called "Linux for Workgroups" :-)
It also uses libressl and the packages build against alternative libcs so that's pretty cool. It's also interesting in that it's a new distro rather than a fork.
Odd. If systemd is so Objectively Terrible (the general tenor of these posts: systemd is bad, it's obviously bad, with no redeeming features whatsoever), why is that happening? There can't possibly be a financial incentive.
Lots of programmers aren't particularly good at analyzing the cost of surface convenience in proportion to future technical debt. Software is just as frequently adopted purely because it's convenient, well marketed or in a self-serving feedback cycle, because it's already popular.
It's also worth noting that ChromeOS still uses Upstart.
It has replaced various kinds of NIH'ed and pointlessly differently colored bikesheds in different distros with stable public interfaces that obviate #ifdef hell in higher layers of the stack.
Your technical debt argument is very apt. It's how we ended up with piles of brittle and unmaintainable shell scripts that don't do error handling worth a damn.
I always follow the KISS principle because the more complicated a system gets the more difficult it is to be fixed. I am a Linuxer since 1990, and I am concerned that current Linux distros follow a way which will make maintainability much more difficult by leaving the KISS principle.
Do you really want to write your job descriptions in the amazingly silly XML p-list schema?
Upstart's event model doesn't even work properly.
https://bugs.launchpad.net/upstart/+bug/447654
And... did you know it's using ptrace(2) to track processes?
As a speculation from an outsider, I'll list these reasons: Release team was very motivated in this cycle (auto removal of packages, not letting any new package in freeze, very strict exceptions even for packages that fix bugs etc.), most of current rc bugs are lurking there for months without any progress (and since Debian is all volunteer work, they can't force anybody to fix 'em), and they couldn't also remove those packages because they've already removed packages they could remove. Another thing is some of those RC bugs are security issues, which are handled by Security Team for stable and oldstable, so there is no reason for security issues to delay the release. When all these are considered, they may have not deemed further delaying the release worthwhile.
I would also like to hear the real reasons from a team member, though.
There has been loss of senior development resources because of the systemd and related discussions, though (some quit, some lost motivation etc.)
edit: I don't know if he is going Devuan, but is related.
Several people in the community have asked what happened to the packages but had no reply from the Debian mailing list. I've asked several times on twitter but I too have had no response from the official Debian twitter account.
Sources:
* http://lists.alioth.debian.org/pipermail/selinux-devel/2015-...
* http://lists.alioth.debian.org/pipermail/selinux-devel/2015-...
* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771484 * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756729
The main problem seems to be there is not enough manpower to keep those policies up-to-date. Once there are "grave/serious" bugs, a non-essential package is usually dropped from testing (hence from the next stable). If people care enough, this is usually a hint to fix those bugs.
If you want to help, you can help fixing thos bugs: https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=refpolicy
Once the bugs are fixed, the package can be backported to Jessie.
We were using them just fine in a pre-prod (waiting for Jessie to be released) environment. We weren't using GPG but experienced no other issues.
Right now, to get around the problem we have ported Fedora's policies across. I'm unsure if these two bugs exist when using Fedora's policies but I'd say they would be.
I don't know enough SELinux to comment on the technical details.
MAC is a JOKE. feds only wrote SELinux because largely they're required to use MAC. there are far better things to worry about than MAC unless youre getting paid triple digits per hour. windows had MAC forever, look how no ones uses it. i could go on.
It's a month old mail stating Debian targeted today as a release date for Debian 8 (edit: latest news item in the list).
Also on identi.ca they wrote today:
"FTP/Release teams' work is complete; once CD testing is complete, the mirrors will be updated and jessie will be released!"
https://lists.debian.org/debian-devel-announce/2015/03/msg00...
Today they will make an additional announcement.
So, no that page didn't (and still doesn't) announce Debian 8 release.
“As you are probably already aware of, Debian 8.0 "jessie", is just a few hours away from becoming the next stable release. This is a heads up in case you were not aware of, as there is probably going to be a higher load on the mirrors.”
[0] https://lists.debian.org/debian-mirrors-announce/2015/04/msg...
http://openness.microsoft.com/blog/2015/04/21/microsoft-debi...
1) porting Visual Studio to Linux.
2) porting Office to Linux, or
3) contributing to Wine, with the goal of solving long-standing issues with their (above) software - but hey they could contribute in other areas too, since Wine is far from complete (a USB driver/stack is much needed IMHO).
I won't believe in Microsoft "openness" until I see one of the three above.
Edit: the fact they're using this event mainly to promote Azure services rather than talking about differences/upgrading issues from debian 7 to 8 speaks of itself.
It would probably be easier to make a stripped-down, open-source version of Windows. Then they probably wouldn't have to port anything.
I would go with FreeBSD or Debian.
[0]https://www.debian.org/releases/testing/amd64/release-notes/...
Debian is widely regarded and typically provides two to three years update support for a given code name (e.g. Wheezy or Jessie). There is a proposal for providing Long Term Support (LTS) for Wheezy as has been done for Squeeze.
But only 2 to 3 years? That is very short. What would be a good alternative with longer support? There must be market for it I guess. Don't companies simply want to run their stuff as long as possible? Many companies still use Windows XP. And that's 14 years old.
Any major distris that commit to 10 years of support or something?
CentOS/Scientific Linux/Springdale Linux are free clones with free updates. Oracle Linux is a free download, but not sure how updates work. Current is version 7 with support until 2024.
PS: if you are asking this kind of question here, you might want to take your local Linux sysadmin for coffee and explain your use cases, applications, hardware spec and likely traffic in detail.
Wow, really? That's nothing! No security updates after that?
> Ubuntu 1404 LTS has support until 2019
That sounds more reasonable. But still a bit short.
> RHEL 7 has support until 2024 (and Centos).
Interesting. Now I understand why I hear "centos" so often lately. So far, I only know Debian based distros. I wonder how much work it would be to switch to one of these two.
First of all, it's 2018, not 2017. For the latter point, there is now a LTS project, which provides +2 year after offical support ends, but they only support squeeze for now (since wheezy is on offical support and jessie is not released) and AFAIK it's not decided yet if jessie will be supported by LTS or not. So it may extend to 2020.
If you want certainty on this regard Ubuntu LTS is also a pretty good choice.
On CentOS, I don't use it so I can't comment on it in depth, but beware that number of offically supported packages are much smaller compared to Debian, so make sure the packages you want to use are supported. (There are semi-offical/unoffical repositories, but they may not be maintained as well as offical packages.) (Actually that same point applies to Ubuntu also, as only main and restricted archives are supported by Canonical and universe/multiverse is where big number of packages reside in.)
Long term support is great and all but Red Hat can only support so much, the libraries and any other ecosystem that is part of that software or programming language will be dropped by group that are responsible for it. That was my take away from the post/user comments.
In general Debian is pretty rock solid imo and as a good system admin you should stay a version or two behind and you should be pretty set imo. Waiting until 2024 is crazy in term of updates and such, I rather go OpenBSD route if you want to go that long.
"Few months" being almost 6 months (Python 2.5 was released on September 19th 2006[1], Red Hat Enterprise Linux 5 (Tikanga), 14 March 2007[2])
[1] https://www.python.org/download/releases/2.5/
[2] http://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#RHEL_5
(That being said, if obsolete version in RHEL fits the purpose of the user, that's great, and there is no reason for getting a new version, but it's wrong for those people to pressure developers for supporting old versions, and it's immoral for foss developers to continue supporting 10 year old releases at the expense of holding back progress. there was a post regarding that point lately, I'll try to find the link)
This is incorrect. stable releases are supported until one year after the new stable release, which happens to be ~3 years, so it's 2018 for jessie. If LTS project also decides to support it, it extends to 2020.
So in practice you don't get a larger number of supported packages than with RHEL/CentOS.
As such, upgrades may be painful if you have anything esoteric in your configurations.
(I actually like systemd, just adding to the list of ways that Debian makes it easy to avoid it, in the hope of the whiners whining less :P)
http://people.skolelinux.org/pere/blog/How_to_stay_with_sysv...
Depends on your definition of "stable". Since distros vary widely on what they consider to be "stable", comparing various distros' stable releases is like comparing processors by raw GHz values or dSLRs by megapixels alone.
Debian Stable is the last place to go if you want very recent builds of packages, but the first place to go if you want absolute, rock-solid stability.
Debian Sid (unstable) has the latest versions of each of the packages, though Debian's guidelines are strict enough that testing and sid are oftentimes more stable than the "stable" releases of other distros.
My advice (and this is what I do): Run Debian stable (Jessie, as of today) as a base image, and use an appropriate container for applications that require more up-to-date applications. Best of both worlds.
I can't say why that is, but I've seen it on multiple occasions. Usually you can resolve this in Ubuntu with a PPA.
Because Ubuntu releases are, well, releases. Early in the release cycle, they sync from Debian, they package their own things, then freeze the versions and release. They don't change versions of most packages in released! releases.
Debian unstable on the other hand, has no concept of a release, so maintainers upload new versions of packages into unstable pretty much all the time (except freeze time).
So what you've seen is actually the norm, not exception.
In Debian, actually, I am pretty sure there's never really a freeze in unstable as you mention. They make a new stable release from the testing branch some time (a good long while) after the freeze is called, then for a brief period you have only stable and unstable (and oldstable), and later on a new testing branch is created (not yet frozen) with whatever packages from unstable meet the criteria to go into testing.
When testing is not frozen, that means "the package has been in unstable for 2 weeks without any reported bugs" or something like that. When they're getting ready for a new release, they freeze testing, and then the criteria to get your package in for the next release gets more stringent (is it, bugfixes only? security issues only? I'm not sure, but it's probably even stricter than I think.)
I'm not closely following Ubuntu development, but they have 6 month release cycles and they do the "sync from sid" early in the cycle, AFAIK first 3 months or so, so you can expect 15.10 to have what was in sid on August-ish. This may further skew when
1. Debian is on freeze. For example, Debian was on freeze starting from November '14, which means practically sid was also on freeze. Debian import freeze date for Ubuntu 15.04 was February [0], so while normally you would expect 15.04 to have latest versions of february; in reality they were latest versions of october. (there are, of course, exceptions). When you consider import freeze of 14.10 was August '14 [1], you can see why 14.10 and 15.04 have very similar versions.
2. Ubuntu is importing from testing for LTS releases, instead of sid. This shouldn't matter in an ideal world, where the difference between testing and unstable is 5-10 days, but sometimes packages got stuck in sid so bad that it may cause a difference in what lands in Ubuntu release.
3. I'm not so sure on that but if I understand correctly, they do a complete import of Debian in the beginning of the release cycle, and then maintainers can do ad-hoc imports for individual packages until the import freeze date, so the packages that land in the release may also be older than what was on sid near the import freeze date.
I guess you'll see much newer packages on 15.10, though, since sid will be full-speed during the 15.10 cycle, so nothing to worry about for now :)
Thanks!
If you can identify the specific packages (i.e. php? nodejs? mysql? redis? etc) that you found outdated in Ubuntu it will be much easier to make a suggestion about how appropriate Debian stable will be for you.
Since the freeze is around 6 months, this means you get 6 months old software when Debian is released. There are some exceptions, like browsers that are too difficult to maintain at the same version.
We believe most people like this definition. This can be frustrating when you need the latest version of nginx but you are happy that upgrading some basic stuff won't break anything on your system: no deprecated configuration option in X, no command-line flag that doesn't exist anymore in Y. All should work exactly as before, with fewer security holes and bugs at each upgrade.
However, if you really want to have the latest version of a selected set of software, have a look at the official Debian backports. This is a great strength of Debian over Ubuntu (where backports are almost inexistant with the notable exception of the kernels): there are many backported packages. For example, if you need a more recent version of nginx and you are running Debian Wheezy, you'll get nginx 1.2.1. If you need something more recent (because you want to get SPDY), you can get nginx 1.6.2 through backports. See here: https://tracker.debian.org/pkg/nginx.
Backports are packaged from the versions that will be in the next Debian release. So, they should keep the same quality than the packages which are currently in Debian. This is a great strength over random PPA. Some of them are maintained by skillful people, some others are not. If you trust Debian for its packages, the backports are made by Debian Developers too.
For nginx, there is no 1.8 because backports are taken from the next release. As this next release is currently frozen, the version proposed in backports is still 1.6.2.
Using a Debian Stable with backports should allow you to get what you want: stability for most packages but latest releases (and latest bugs/changes) for a selection of packages.
(Second) latest post to debian-devel-announce:
https://lists.debian.org/debian-devel-announce/2015/04/msg00...
And latest post to debian-announce (concerning the latest stable point release, 7.8):
https://lists.debian.org/debian-announce/2015/04/msg00000.ht...
https://lists.debian.org/debian-announce/2015/msg00001.html
Also note that the link to the 7.8 point release above is wrong, the correct link is:
Debian is generally very good with stability for things like security updates and we certainly plan to continue using it. However, our plans for updating this time are more along the lines of "set up completely new machine with Debian 8 from the start, install our own choice of packages and applications, and then systematically migrate data/connectivity from the old systems to the new ones". We expect the time and money costs of having the transition period to be less than the potential downtime if direct upgrades take as much effort as they did from 6 to 7.
Your mileage may vary, Linux has infinite possibilities and ours may just have been unlucky, the plural of anecdote is not data, etc.
Did your last upgrade issues stem from the upgrade procedure or were they because of new versions?
I can't remember all of the different problems now, but one I do remember is that if you had a typical set-up with mirrored (RAID1) drives but the boot-related partitions cloned rather than mirrored, one of the bootloaders got upgraded but not the other. That is, the drives were left out of sync and booting from one of the drives wouldn't work properly if the other failed. The thing that really concerned us wasn't so much the specific details here but that this was essentially a silent failure in the upgrade process, combined with a potentially catastrophic failure in a basic system function as a result.
I think there is quite a big difference between the theory of updating a couple of sources files and running a couple of upgrade commands and the practice of manually checking things like basic RAID configuration and reinstalling missing bootloader updates. This time around, the fact that Jessie uses systemd made the discussion for whether to even try a dist-upgrade a very short one, because literally everyone in the room agreed that the probability of failures was too high for that strategy to be worth considering. The substantial discussions were more about migration to fresh machines relatively soon vs. sticking with 7 at least until we know the LTS situation.
Did you use some tool to do that? How do you expect the upgrade process to even be able to take that kind of thing into account?
Without knowing any details it's hard to say if it was an actual bug or just plain old human error, but it sounds like the latter.
I've long forgotten exactly why these systems were first set up that way. Presumably it was because at the time someone was leaving their options open about the RAID set-up for the main drives/partitions and bootloaders of that generation didn't support MD well so keeping boot as a non-RAID set-up was not uncommon. Whatever the history, the fact is that before the automated part of the 6-to-7 upgrade there was a fully working system, and after it there wasn't.
How do you expect the upgrade process to even be able to take that kind of thing into account?
I don't think it's rocket science to suggest that if you're migrating to a new bootloader, and you've got a system with multiple drives in it (RAIDed or otherwise), and you're installing an OS that is widely used in server or multiple-OS environments, just assuming that you should upgrade the bootloader on one specific drive and ignore anything else is not a great idea. What if the sysadmin installing the update wasn't the person who installed the original and simply hadn't realised how the /boot was set up?
Without knowing any details it's hard to say if it was an actual bug or just plain old human error, but it sounds like the latter.
There was no "error". The situation before the upgrade was what it was, and after the upgrade the problem was quickly detected and fixed. But it took time and effort to do that, instead of having a smooth, fully automated upgrade process. Again, the fact is that before the automated part of the 6-to-7 upgrade there was a fully working system, and after it there wasn't.
Will the 7-to-8 update now expect everyone performing it to be intimately familiar with the implications of things like systemd? Because I'm betting plenty of people will encounter it for the first time as part of this upgrade cycle.
What about package compatibility? Some packages have been entirely removed in Jessie; see the political debates about FFmpeg vs. Libav for a relatively high-profile example. That is inevitably going to break some people's install scripts/tool recipes/etc.
My point here is that there are significant changes as part of the upgrade, and upgrades always carry a degree of risk, and my personal experience (based on several different projects) of the 6-to-7 upgrade process was that the risk was real and the fully automated part of the process was not able to do everything necessary itself. Consequently I would not recommend that anyone assume a 7-to-8 upgrade will necessary go completely smoothly and be fully automated either.
[Edit: To be clear, I'm not saying you shouldn't do it or something awful will happen. Nor am I criticising Debian for not anticipating every possible scenario and handling everything completely automatically. I'm just saying my experience last time around was different to kasabali's experience, and as one data point, projects I work on where the experience was not as smooth last time but the desire is to move to 8 quite quickly are generally favouring a clean install and application migration strategy rather than an in-place upgrade. The expectation of those teams is that this will incur less risk and might be faster anyway once you take all implementation and testing effort into account.]
Upgrade scripts certainly could try to predict every crazy thing people do with their computers, but past a certain point, it's not very productive. People are creative.
In the end, the admin must make the decision whether reinstalling and reconfiguring a server has a lower general cost than verifying and potentially fixing an upgraded installation.
If you did something unorthodox, such as building a boot process dependent on a manual step to clone drive, you surely must be prepared to deal with this in any number of situations that can arise?
All non-standard solutions carry a debt where all future admins must understand what you built and how this affects operation.
The point remains that this doesn't matter. Before the upgrade, there was a fully working system. After the automated part of the upgrade, there wasn't. The original question was how safe the upgrade from 7 to 8 is, and this is a demonstration of the fact that such upgrades can carry risk. I'm not saying don't do them, I'm not expecting Debian maintainers to be omniscient, and I'm not telling you your child isn't beautiful. I'm just saying if you're thinking about moving from 7 to 8, be aware of the potential that there will be things the automated tools can't or won't do for you that may break your system, and plan your upgrade or other migration strategy accordingly.
I'm not a DD and I have no vested interest in it, but that particular data point is an outlier no matter how you look at it.
There are more obvious situations where updates will break your system. Most common probably when you've installed third party packages with dependencies on system software. But that's not generally what's referred to when asked if the update process is stable. Such things will break no matter how stable the process in itself is.
We've a lot of 7.x instances (bare metal and VMs both) and a few running jessie for about 2 months. The upgrade was flawless. systemd had quirks, but that faded too.
All in all, go ahead, it's yet again a nice little step forward.
If you have a fairly vanilla 7.8 system (i.e. no source compiled stuff on there, mainly just big name packages etc.) then you should be fine doing it now or in a few days.
We updated some simple 7.8 installs to the rc jessie release a month or so ago and everything went fine apart from an obscure bug with monit and inherited umasks. Got around that by manually installing the sid deb of monit.
Edit: the main thing you'll want to do is go read up on systemd ahead of upgrading as it's quite a change and there are still some wrinkles ('systemctl daemon-reload' is a new command we've had to use quite a bit).
So i basically won't be missing any important and hip packages? :D
That way you start with a very lean < ~700MB base install with no unnecessary garbage on your system to worry about.
release can happen any moment!