Debian GNU/Linux 8.1 (Jessie) Officially Released

prisoninmate writes: The Debian Project has announced the immediate availability of the first maintenance release of Debian GNU/Linux 8 (Jessie). As expected, Debian GNU/Linux 8.1 comes with a new Linux kernel, version 3.16.7-ctk11, which fixes the well-known EXT4 data corruption issue caused by delayed and unwritten extents, blacklists queued TRIM on Samsung 850 Pro SSDs, adds support for XHCI on APM Mustang USB, and updates Crucial/Micron blacklist in libata.

Comments

Also fixes data-loss caused by systemd screwup

[Anonymous Coward]

This releases also fixes a grave bug in systemd. Depending on several conditions, it would SIGKILL things way too aggressively on shutdown, causing data corruption and data loss if the service it just SIGKILLed in haste had anything worthwhile to do.

Interestingly enough, that bug was fixed post-haste by Ubuntu, and a bit more sluggishly by Debian the moment someone came across the issue and found a bug report in Fedora that described the root cause... while the same bug still lingers in the Fedora bug tracking. In fact, it is still open in Fedora and systemd upstream. Note that said bug was reported to Fedora in 2014-09 !!

https://bugzilla.redhat.com/show_bug.cgi?id=1141137

I sure hope this attitude is not prevalent in the RHEL side.

Re:Don't care

[jellomizer]

Debian is one of the few Linux distributions, that is trying to be a Linux distribution.
Other tend to try to copy Windows or OS X, and be Mr. Happy Friendly Desktop System.

I don't want Desktop Linux. I want a Workstation Linux. A system where I can do work on, not a system that is hiding where my actual stuff is.

If I want a Desktop system like Windows or OS X, I will use Windows or OS X... But I want a system that is uniquely Linux. And Debian is a set of a few Distributions that offer that.

They will care, probably sooner than they think

[FreeUser]

Let's not pretend everyone has issues with systemd. Plenty of people are totally ok with it.

Until they have to debug a boottime issue (which crops up quite frequently in production environments with systemd). Some overworked desktop/power-management developers and lazy devops folks have been seduced by the promises of systemd, but all it takes is one morning wasted tracking down boottime issues within binary logs and quirky systemd corner cases to make it clear just how bad an idea systemd has turned out to be.

Unfortunately, by then their strategy of subsuming other projects (sianara ntp, it was nice knowin' you), enforcing dependencies, making it more difficult to maintain alternatives (dropping support for biosdevname=0 for example) will have made it difficult if not impossible for those who wake up to switch to something that adheres to more sensible unix norms. I have used Linux since 1993, on my desktop since I could get X running with twm, and later through the gauntlet of enlightenment, gnome, KDE, e17 etc., but I fear this really is the beginning of the end for Linux as a viable alternative to anything. Unless of course Google steps up to the plate with a solid alternative (after all, they don't seem to use systemd in chrome OS). OpenRC is great, but with power management developers refusing the support anything other than systemd, it faces an uphill battle despite being a well established and in most ways a superior init system.

Perhaps the Debian Fork, Gentoo, Funtoo, Arch without Systemd, etc. will succeed in joining forces to maintain a sensible alternative or two. Because otherwise you might as well run OS X ... you get the same byzantine init and config crap, without the other hassles that in the past were worth it to run a clean Linux system, but certainly aren't with systemd in the mix.

Re:They will care, probably sooner than they think

[Peter H.S.]

Until they have to debug a boottime issue (which crops up quite frequently in production environments with systemd).

You are just talking bullshit here. I have been using systemd for +4 years now and it has been rock stable.
Besides, systemd systems are so much nicer to debug than distros glued together with shell scripts.

Just the fact that you can have full logging and the systemd tools working from initramfs is a vast improvement, and the systemd journal beats all other Linux logging options by a huge distance; field based filtering and monotonic timestamps are just great when debugging boot problems.

Being able to do a "journalctl -b -1 -p err" is so much better than faffing around with grep and regex. (the line shows all log entries from the previous boot with the syslog severity level "error" and above, try that with grep!).

Unfortunately, by then their strategy of subsuming other projects (sianara ntp, it was nice knowin' you)

You are seriously misinformed here; systemd provides a sNTPv4 client, not a ntp-server. It is a compile time option, so no distro ever needs to use it instead of their preferred sNTP-client. It is included in the systemd project for two main reasons; clock-less ARM boards and OS containers. Both have special timing needs since eg. an OS container can be "frozen" and "unfrozen" without warning. systemd provides them both with a solution so they don't gets confused by time jumps.

But perhaps you think choice is bad and there are too many sNTP clients so systemd developers should be banned from providing one?

, enforcing dependencies

Like what? systemd have extremely few external dependencies. And don't try the provable falsehood that systemd inserts "hard dependencies" in other projects like Gnome/KDE.
That Gnome have had problems supporting non-systemd distros was because those distros didn't care to maintain ConsoleKit. Gnome kept on supporting CK despite it having been abandoned for +1½ year with no upstream to provide bug-fixes or security fixes.

But thanks to systemd, there are now several alternatives to ConsoleKit. Choice is good.

, making it more difficult to maintain alternatives (dropping support for biosdevname=0 for example) will have made it difficult if not impossible for those who wake up to switch to something that adheres to more sensible unix norms.

Again, you are really misinformed here; how can systemd ever make it harder for non-systemd distros that are using mdev or vdev or eudev?

If a non-systemd distro wants to use unpredictable network names they can do so.
With systemd distros here is how you turn off predictable network interface names:
http://www.freedesktop.org/wik...

Again, thanks to systemd the Linux ecosystem went from just having udev and mdev, to also having eudev and vdev and probably several more. So if you like choice, praise systemd for providing it.

Warning if upgrading from Wheezy:

[Narcocide]

If you don't want systemd then in your /etc/apt/preferences, add:

Package: systemd
Pin: origin ""
Pin-Priority: -1

Alternate

[Anonymous Coward]

Time to move to Slackware then? Or pick another: http://without-systemd.org/wik...