Guest post by The Debian project is pleased to announce the third update of its stable distribution Debian 8 (codename jessie). This update mainly adds corrections for security problems to the stable release, along with a few adjustments for serious problems. Security advisories were published separately and are referenced where applicable.
I see that the Debian project continues to lay a strong foundation for many other distributions. I’ve been using stable for about a decade now (updating as they become available) and have not been let down by the project.
It may not always have the latest software, but it does tend to work right most of the time…
FortranMan,
I’ve been burned a few times with debian stable updates, it’s enough to make me nervous now.
During the systemd transition they broke syslinux integration scripts, which rendered a production server unbootable. Teaches me for preferring syslinux over grub.
At various times, upstream changes have broken exim and nginx, but to be fair I think these were all documented.
Last year Debian updated to a 3.16 kernel which caused some serious ext4 filesystem corruption for several people. Fortunately I keep good backups.
https://bugzilla.kernel.org/show_bug.cgi?id=89621
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1423672
https://bugzilla.kernel.org/show_bug.cgi?id=102731
Even though it says “stable”, system administrators really should be deploying updates to a staging region to conduct a full barrage of regression tests prior to updating production. Even then intermittent issues are possible. In any case, most clients aren’t actually willing to pay for this level of service, which means you’ve got to cross your fingers alot. I insist they pay me for daily backups though, I’ve had clients specifically complain about the cost, but I must insist…I refuse to take responsibility for fixing things without having recent backups I can count on.
Edited 2016-01-29 13:40 UTC
I only run workstations on Debian, not any servers or other production type systems, so it looks like my needs have been different from yours. I have had minor troubles with some updates now and then, but never very difficult to fix.
FortranMan,
It’s mostly a matter of personal preference, as always
Slackware, debian, and redhat are all very capable for server tasks. While it’s true I could use one distro for servers and another at home (I’ve been there), I find it frustrating to develop for one distro at home and then to deploy on another distro with different package requirements and different software versions.
I might have easily gone down another path, but my own reason for going with debian flavor is that it’s repos are more complete than redhat’s.
I like a lot about Gentoo/portage. In a fair world it might get more attention, but as is it seems too “niche” to use it for clients. I don’t use slackware mostly because I don’t have much experience with it, to be honest.
My situation is pretty similar. In the end, I try to run the same distro on everything. I do have an Arch EEE PC that I play with, but all my work computers are on Debian stable to ensure compatibility.
As you can imagine, one of the things important to me is the gfortran version number. Newer versions are nicer, but so are working systems; I stay on stable these days.
Debian says no to non-free firefox artwork.
Debian says no to non-free firmware blobs.
Yet Debian says yes to non-free mono disease.
Debian is like vegetarians that wear fur coats.
I just can’t take Debian seriously because of that. And combined with their stance on systemd being mandatory, Debian will probably never be installed on any system I maintain again.
Edited 2016-01-29 04:09 UTC
License extremist. Like the world revolves around a dogma…
http://www.mono-project.com/docs/faq/licensing/
What part of mono isn’t free?
Systemd isn’t mandatory. Its just default init. There are some stubs you have to install if you don’t want systemd that do the same tasks without pid 1 being systemd.
Having said that, not liking systemd is associated with impracticality. It works really well, better than anything else, and all objections to it are mostly hypothetical.
I have to respectfully disagree. systemd developers suffer from two faults: The “move fast and break things” philosophy and the “not invented here” syndrome. On the first issue (speaking specifically of Debian) systemd was abruptly accepted almost overnight even though it had (and still has) severe regressions and issues. It’s unproven, bleeding edge software that quite simply doesn’t belong in a stable, mature project like Debian (yet). It’s right at home in Arch and other bleeding edge distros, of course, and there will come a time when it will be good enough for the masses. But that time is not now.
As for the other issue, Poettering and gang are wearing hubris like a medal, not caring what they break in the Linux ecosystem as long as they get to flail their penises in our faces alongside a measuring stick. Yes, that has nothing to do with the technology, but it makes it difficult to like the project in spite of its fathers (and fathers it is, it’s a boys’ club and no “bloody weak women” allowed, something else that’s reprehensible but again no reflection on systemd the software).
I completely disagree that its unproven. Its running in production with huge, absolutely huge deployments. Its more than mature enough.
As to the personalities of the devs, well, you find a lot of that in foss.
This is how it works
User A: hey SystemD guys you made a change that broke my workflow. change it back!
systemd: No, we made that change for a really good reason!
User A: Change it Back, you are all evil.
systemd: Again, no, we made that change for a really good reason. you are evil.
bystander: Well, none of you are really that evil. If you simply change one aspect of how you did that, you the user can accomplish the same task in a better way.
systemd: Oh, ok. we’ll do that.
That’s simply how a lot of conversations in foss go. Not really unique to systemd.
I guess I’m just old school, but systemd as it stands is simply not there yet for me. Maybe one day it will be, and I have a feeling that will be the day it is adopted by Slackware.
And it is by no means the only FOSS project I find to be immature or not ready for production; that is a long list. systemd just happens to be on that list.
I wouldn’t call slackware stable. Its been through a lot less testing and many fewer eyeballs are on its construction. That’s basically why I left slack for Debian back in 99 or so.
In other words, your knowledge of Slackware is sixteen years out of date?
Wait, what?? Slackware is one of the most stable distros out there. Pat doesn’t ship until it’s been thoroughly tested (hence the long wait from 14.1 to the upcoming 14.2). Yes, it’s a small community, but it’s a tight community and a tight ship. I guess it’s obvious you haven’t used it in 16+ years if you don’t know that.
Read the changelogs and you’ll see what I’m talking about.
From the slackware changelog:
So, they didn’t really so much as plan to add pulse audio as it they just added something that required it for common functionality, and then realized what they did and scrambled to add it. This is what I mean.
Edited 2016-01-29 23:16 UTC
I’m not seeing the downside to running a stable, established distro with stable, established software, and when the inevitable need to move on to new technology finally arrives, they test it and make sure it works before shipping it. That’s the very definition of “stable”. “Unstable” would be shipping, say, systemd on launch day (see Fedora and Arch, i.e. bleeding edge distros) and dealing with the fallout, stability for users be damned.
And by the way, you’re quoting the -current changelog, which is the experimental branch intended for just such testing before release. The release channel only has stable, tested software. That would be like me claiming Debian is “unstable” because of Sid, when Jessie is the stable branch.
You have no point to make here.
Edited 2016-01-30 00:26 UTC
That seems like an odd case to select. The Pulse Audio addition happened early in the development cycle, around the introduction of the first beta release of the upcoming Slackware release. The only people who are affected are the developers and people doing beta testing. Every distribution goes through shifts like that early in the development cycle.
Almost every anti-systemd FUD talking point in just 2 paragraphs. Bravo!
http://awesomegifs.com/wp-content/uploads/jon-stewart-colbert-bravo…
I’m sure the entire Debian project is shaken to the core, and deeply saddened, by the news of the possibility that you won’t include them in the partition table of the old ass PC in your parent’s basement.
They’ll have to take it one day at a time, one day at a time…
such rage…
First time I’ve heard of 32 and 64 core systems being called “Old ass” too.
Edited 2016-01-30 19:04 UTC
… meanwhile in the real world.
…get your system screwed with Linux : https://github.com/systemd/systemd/issues/2402
No, read man is not always mandatory, since have to be a little bit more secured. Even the root doesn’t necessarily have the knowledge of such subtle things.
Kochise,
No surprise, Poettering has always had a total disregard for the community’s concerns. The fact that he’s resorted to censorship here rather than to engage and find a proper solution is especially disappointing for a guy in his position, does he do that often?
No idea, yet he seems to be knows for that kind of behavior. However uefi implementations are also to be pointed at to allow corruption of their variables and not able to automatically restore a default working set.
Kochise,
Yeah. I kind of wish computers had a standard mechanism to ensure that short of physical damage, the computer would always be recoverable from scratch.
I learned tons by programming my own operating system, and I had no fear doing it because I knew that I could just change disks to get a working system again. However I never had the guts to flash my own BIOS even though I wanted to because I couldn’t afford to permanently brick my computer.
It’d be very nice if mobile phones could be booted off sd cards, but they tend to be even more locked down.
Edited 2016-02-02 20:32 UTC
Current MB offers dual bios with a safe backup in case the flash fails or gets corrupted by a virus, so it’s not like it’s impossible.
Anyway, tweaking with uefi registries is already rather dubious, leave that to the embedded uefi setup screen. No one should play with that.
Ok, some really important processes seems to be on the Rails of a dead end destination:
http://phys.org/news/2016-01-eu-days-deadline-renew-data-sharing.ht…
We trust Nature. No matter how far We twist, cut, mold, hack Nature, know that it is going to behave accordingly to profound principles.
And here Yukihiro Matsumoto have it right about the principle of least astonishment (POLA). And here Yukihiro have it wrong about it being HIS own astonishment.
And here Almost every modern language have it wrong also. Think only ORACLE has corrected this, of recently, when JAVA got very near to the precipice.
This is why lots of people abstain of learning any more language or environment. On bending to near term interest, their evolution start to convolute unnaturally.
Same is happening above the stack, and below it. It has to stop. Or risk loosing entire -future relevant- ecosystems.
Congratulating Debian Community about their extremely productive efforts.
I put 8.2 on some of our new servers before Christmas. It was a bit of a change because most of our Linux stuff runs RedHat/Fedora or Suse.
Installation (net install) was slick, and they seem rock-solid. Mind you these are servers that don’t need all the frills your laptop does.
They’re working, so I won’t be messing with upgrades for a long time unless something demands it.