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

Re:Don't care

[rvw]

This is the second release in the history of Debian I didn't give a fuck about.

Well then - finally you got your first post, then you spoil it on a second release!

Re:Don't care

[Anonymous Coward]

Whatever goodwill anyone had for Debian, they pissed it away with systemd.

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:Also fixes data-loss caused by systemd screwup

[Eunuchswear]

Frankly, tells us more about Debian, Ubuntu and Fedora than systemd.

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.

Re:They will care, probably sooner than they think

[Peter H.S.]

You are talking bullshit here, we've been testing systemd for 6 months and it is unstable, rolls the system back to start state for trivial reasons. Not to mention needing all kinds of shims for the parts that haven't even been written yet so it could "function" in a current system. What a bunch of badly designed over complicated garbage

There are no "shims" necessary to run systemd. On Debian there is "logind-shim", but no one should use that instead of the proper systemd-logind.

Comments like that, and your bizarre claim of " rolls the system back to start state" makes me suspect that you don't have actual personal understanding and experience of systemd management.

Sure, truly understanding systemd require some serious study, something way too many have neglected, thinking they could just wing it when time came. The payback for the time spend studying is that systemd also have some serious cool technology that is far superior to everything else in Linux/Unix land.

Re:They will care, probably sooner than they think

[Peter H.S.]

[snip: about "journalctl -b -1 -p err"]

You are cherry-picking the one thing that isn't logged by most syslog daemons by default,, in a disingenious attempt to show that syslog is "worse", even though it is off by default because it is of little use. If we cared AT ALL to have the "log level" information, it would be logged.

I chose the example because it has proven really useful to me. The example will quickly show any serious error that may have cause a system to fail. Being able to filter out all boot-sessions that aren't relevant is really useful. Being able to see all serious errors on a system at a glance is really useful too. Being able to easily combine such queries into one is pure gold.

But there is so much more that syslog doesn't log. This brings on another fundamental problem with text logs; they are hard to parse for machines due to their lack of structures, and they become hard to parse for humans too if they contain too much information.

Monotonic and micro-precision timestamps are great, but they foul up the readability of syslog textfiles simply because they make the lines longer. So basically syslog can't put the same amount of logging info in the log files, not for direct technical reasons, but because the log file format is inadequate.

The systemd journal on the other hand, can easily be extended with ever more fields as needs arise. And it can do so without breaking userland!

Because another problem with the unstructured syslog text logs are that they have no programmatic API or even "labels" for each part of a logging entry. That means the very structure of the log entries has become a sort of API, so changing that structure by adding more information, and thousands of userland log-watcher scripts that rely on "cut" simply breaks down.

The discussions of the many limitations of syslog,

Fine. Then solve the problem where it should be solved, and add this to /etc/syslog. You systemd apparatchik like editing non-script-based config files, right?

Many of the problems can't be solved by adding features to syslog. If you want "metal-to-metal" logging you just got to design something like journald for so many technical reasons, including that the Linux kernel only accept one owner of /dev/log.

But as said, the most fundamental problems are the total lack of coordination between stuff in Linux. It is almost impossible to improve some things because of that. The Rsyslog team have fought valiantly over the years, but the sheer lethargy and no formal coordination means changes are hard to impossible.

The systemd team solved this problem in the most elegant way possible; they made a new logger that were 100% backwards compatible with syslog, but at the same time introduced radical new features. The end-users could user whatever option that suited them best, and userland didn't have to change a line of code, while still benefiting from the new features.
This way all the systemd Linux distros and userland programs can slowly migrate to using the new journald logging API. No "flag day" problems!

# probably already in the config
source src { system(); internal(); }

# here's your damn filter
filter f_err_only { level( "error"}; };

# pre-filtered log output
destination err_only_log { file("/var/log/err_only_messages"); };

# link the filter to a destination
log { source(src); filter(f_err_only); destination(err_only_log); };

Now you can read those messages only using "less". You DID know that syslog has very flexible log routing and filtering capabilities, right?

I think the above examples greatly illustrate several problems with syslog text-files.
But first; despite spanning several lines, it isn't even remotely close to what "journalctl -b -

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

Most Importantly It updates all the system librari

[anthony.minessale]

Especially for multimedia manipulation. Our project FreeSWITCH http://freeswitch.org/ needed most of the updates in jessie to be able to run properly. All the libraries like libavcodec, libavformat and vlc etc. it's harder than it looks to swap out libraries because you need harmony among all the software it supports. Sometimes changing one library can cause a lot of issues that are not always immediately visible. New releases, even if not exciting on the outside, often have a lot going on behind the scenes.

Alternate

[Anonymous Coward]

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

Re:Alternate

[0100010001010011]

Check out FreeBSD

There are more reasonable alternatives

[FreeUser]

> Gentoo + OpenRC here, fuck systemd. If the rest of you enjoy having something shoved down your throats for political purposes

THANK YOU FOR TELLING US WHAT YOU USE!

His point is that you have more reasonable options for a server Linux system than a distribution that has adopted an opaque init system like systemd that is being pushed largely by the desktop crowd (not that you need it for a good desktop...lots of people have been running modern Linux desktops since the 1990s, and have kept up with the latest changes, without adding the complexity and opacity of systemd).

Some options for a systemd desktop OR server Linux system:

• Devuan - a fork of Debian with systemd removed (https://devuan.org/)
• Arch + Openrc (http://systemd-free.org/)
• Gentoo + Openrc (http://gentoo.org)
• Funtoo (http://funtoo.org)

and many more. All of which many find to be much more suited for servers than Fedora or Debian with systemd.

Re:There are more reasonable alternatives

[Barsteward]

"His point is that you have more reasonable options for a server Linux system than a distribution that has adopted an opaque init system like systemd that is being pushed largely by the desktop crowd" - what makes you think that, it benefits servers (mainlyIn cloud setups with a large number of VMs or containers), embedded as well as desktop. You can bet that Red Hat wouldn't make it a core piece of RHEL7 if it wasn't a reliable and safe option for managing services on servers.

Re:Don't care

[0100010001010011]

How many of those 'plenty of people' use their Linux machines for more than desktops?

There are some serious open 'show stopping' bugs in systemd for power users.

• NFS umount race condition causes systemd hang during shutdown Caused when NFS is mounted over Wifi.
• lack of non-ascii support
• systemd is sending wrong audit event
• System with Intel firmware RAID-1 does not mount /home on boot (udev/systemd race with mdadm issue)

I've switched over to FreeBSD for all non-Windows machines in my house. If you go through the supported hardware list and pick good hardware everything 'just works'. Everything I've tried out so far is "Do or do not, there is no try". If you find hardware with vendor FreeBSD support it's good support. (Intel GigE vs RealTek GigE).

Jails is all I need for 'visualization'. I don't need an entire new ESXi or Xen instance. My FreeNAS server has 8-10 Jails running everything from Nginx for web development to Transmission+OpenVPN for torrents.

ZFS is a great filesystem for root. When I had a PSU take out a motherboard and 1 hard drive I was able to toss the remaining good drive in a new computer and my whole system booted like nothing happened. Replaced the degraded device and didn't lose anything. My Windows machine kept crashing on boot and required some drivers.

Re:Don't care

[buchner.johannes]

How many of those 'plenty of people' use their Linux machines for more than desktops?

There are some serious open 'show stopping' bugs in systemd for power users.

• NFS umount race condition causes systemd hang during shutdown Caused when NFS is mounted over Wifi.

Who uses NFS anyways :P (over wifi!) If this is for a desktop machine, mount nfs through nautilus/gvfs

lack of non-ascii support

That is not a systemd bug (as discussed in the bug), but a problem in redhats packaging of components or initialisation scripts.

systemd is sending wrong audit event

Apparently a bug in libselinux, not in systemd. Anyways, hardly a show-stopper to have the wrong audit log entry.

System with Intel firmware RAID-1 does not mount /home on boot (udev/systemd race with mdadm issue)

This is the only one that is probably a systemd bug, or at least requires the workaround implemented in systemd.

Re: you're a total ponce

[Peter H.S.]

Systemd will fail in the long run. Systemd lovers are just like the windows fanatics of yester year. My company has thousands of Linux systems guess what none of them are moving to a distro the uses systemd and never will. We will still keep making money. And will have a freedom of choice. So go suck it systems lovers.

Why should I care that you don't use a systemd distro? If you are making money on Linux, great. If you are using eg. Slackware to do so, hey, that is great too. I respect mr. Volkerding and his way of making a distro.

I like freedom of choice and I think systemd provides exactly that. Even if you don't like it, you benefit from the fact that there now are several udev-implementations (before there was just udev and the limited mdev) and several ConsoleKit/systemd-logind implementations (before systemd there was only CK).

But apparently the freedom of choice doesn't include the right to choose systemd.

That is a major problem with the behaviour of the anti-systemd camp; they won't accept that highly skilled Linux developers (including Kernel developers) and experienced distro and system maintainers, thinks that systemd is superior to whatever else out there, and therefore chooses to build their distro around it.

This lack of accepting other peoples freedom of choice is why you are trolling a Debian thread, even though you don't use the distro and claim you never will.

So think about what you are actually doing before saying "freedom of choice" again.

Re:Your appeal to authority means nothing

[Barsteward]

"I work with RedHat, Centos, and Fedora systems every day, and the fact is Red Hat has selected a core piece of software that is neither reliable or safe. It works well enough in most cases, but for any serious tweaking of the system (as most serious shops find themselves needing to do), systemd starts displaying some very nasty behaviours." - I never believe these types of statements/anecdotes.

"Many system engineers, Dev Op guys, and admins have seen this, which is why in the server world there is so much push back against the systemd coolaid." - there isn't that many that push back, just a very vocal few and plenty of thick trolls