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.

SELinux?

[eyegone]

Does it have an SELinux policy now?

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.

Awesome, but does it have

[Dishwasha]

Real time kernels? Did they resolve the funding issue?

Re:Awesome, but does it have

[Dishwasha]

No replies to this post really demonstrates how clueless and inexperienced /. readers are these days.

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

[sjwest]

I don't like systemd on debian testing which i run on laptop - but upgraded our stable server and systemd picks up init.d scripts and apart from a non on boot running script (easily fixed) i feel quite happy about systemd, i can tell you that systemd in testing is a lot different to stable. So its a bit of a mix.

i have ext3 filesystems.

Apache 2.2 > 2.4 is the worst upgrade job imho

Re:They will care, probably sooner than they think

[Barsteward]

I guess you typed out what was in your own head while you were talking to yourself.. ppssttt it is "you're talking about"

Re:They will care, probably sooner than they think

[Peter H.S.]

The journal is brilliant, anyone who says it isn't needs their head examined.

Yes, the journal really is brilliant. It just solves so many decade old logging Linux problems, and make hard stuff very easy.

I was sceptical about binary log files when I first heard about it, but just playing around with "journalctl" for 10 minutes convinced me wholly.

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

[Endymion]

Being able to do a "journalctl -b -1 -p err" is so much better than faffing around with grep and regex.

That statement alone shows the core problem with the systemd evangelists: you don' t want to learn generic tools, and instead want to use single-purpose, monolithic[1] apps. A key distinction between the two this windows-style "fancy speciality apps" idea and the design goals of UNIX-like environments is that someone has already implemented the query you want to ask the computer to run.

It's great that you found a useful way to view your log data. Now try to query on something that journalctl didn't already implement for you. What kind of query? I don't - and that's the point. We can't predict the future, and new problems show up all the time. The point of what you call "faffing around with grep and regex" is that those tools are not difficult to use, and once you are familiar with the basics you now have a general tool you can apply to any unexpected situation.

syslog severity level "error" and above

I have never even remotely needed to filter events by syslog(3)'s "level" bits - it's not a very reliable filter, as app can be inconsistent in what LOG_* flag they use. Filtering on the facility (source) or time is far more useful. If you find that particular command to be useful, then great - which would be a good example of how use-cases can vary a *lot* depending on what you're doing.

try that with grep!

Listen, if you want lessons on how to use basic unix tools, there are many available on the web. For now, what you're obviously missing is that you would use sed for range filtering, not grep. do the line-range filtering. You simply use two regex in the form sed -n '/start_line_pattern/,/end_line_pattern/ p'.

Then, once you have a useful query built with the standard tools, you save it in a 2 line shells script. Seriously, do you think we actually type this stuff out verbosely every time we want to search a logfile? Have you evne *used* a CLI? This is n00b level stuff.

how can systemd ever make it harder for non-systemd distros

If you're going to accuse someone of being misinformed, it's a good idea to actually know what you're talking about. To name the most obvious example, it is absolutely insane to have any specific application (server daemons included) depend on any particular "init system"2. Yet systemd promoted the idea of using sd_notify which created a link-time dependency. Yes, such things can be compiled out, but that misses the point. Introducing a binary, link-time dependency like this has the de facto effect of forcing distros to make an all-or-nothing choice about including systemd.

It is true that this is not entirely systemd's fault - the app/sever authors are also to blame for going along with this crap. That doesn't excuse all the social pressure Poettering's cabal put on a lot of projects.

1before anybody trolls with the usual response that systemd is not monolithic - probably by mentioning the number of binaries it compiles into - you should know that those claims will only prove you haven't actually understood what we mean when we say "monolithic"

2 this is why it was always a lie to call the systemd takeover a debate about "init systems", as systemd was never just an "init system", but also many other things as well, mostly inseperable by design

Re:They will care, probably sooner than they think

[Peter H.S.]

Being able to do a "journalctl -b -1 -p err" is so much better than faffing around with grep and regex.

That statement alone shows the core problem with the systemd evangelists: you don' t want to learn generic tools, and instead want to use single-purpose, monolithic[1] apps.

"systemtctl" is a first class classic Linux/Unix tools that works together with all the standard Linux tools like sed, awk, grep, less, tee and what not.

It isn't interactive, it isn't chatty on success, can be piped etc, just like all the good ole GNU stuff. Sure, it can read binary text files like the journal, but so can "last" that is required to be Posix compliant (used to read the utmp/wtmp binary log files). And what about zgrep?

The systemd journal file format (basically an appended text file with non-standard delimeters+index) is fully documented and have excellent language bindings, making it trivial to make eg. Python scripts that read/writes directly into the journal. So it is trivial to make a "jgrep" or a "jless" that can directly read the journal if that is what you want.

The point is that "field" based logging is superior to the unstructured text dumps that syslog makes.

The point of what you call "faffing around with grep and regex" is that those tools are not difficult to use, and once you are familiar with the basics you now have a general tool you can apply to any unexpected situation.

Come on, claiming that regular expressions are easy is laughable. The old joke "I had problem. I decided to solve it with regex. Now I have two problems" is still true.

Not talking about that people should know the difference between regular and extended expressions, and that each and every tool uses its own maddening variation. Basically, if you don't use regular expressions as part of your everyday job, you are unable to use it without heavy man-page consulting for just the basic syntax.

I seriously doubt that any more than a tiny fraction of Linux users are able to whip out an even moderately complex regex. And that means the vast majority of Linux users can't filter their logs to any serious degree. It is so sad to see how people are literally trawling through the logs, reading them as a book in order to find problems. People are even using "vi" to do it, yikes.
systemd's journal basically solves this problem for good for Linux newbies. It is fun to see how productive people can become with "journactl" after a 10 minute introduction.

For power users, the field based approach is immensely powerful too. If you remember how Rsyslog started a decade ago, it was exactly to overcome the many limitations of flat file text logs.

syslog severity level "error" and above

I have never even remotely needed to filter events by syslog(3)'s "level" bits - it's not a very reliable filter, as app can be inconsistent in what LOG_* flag they use.

It is a superb way to filter from both "that boot only" and "this severity only". One reason why you probably haven't tried it is because this is very hard to do using generic tools using flat file syslog text logs.

Filtering on the facility (source) or time is far more useful. If you find that particular command to be useful, then great - which would be a good example of how use-cases can vary a *lot* depending on what you're doing.

Even this is something journald does so much better than syslog; There is kernel guarantee that the source is always is always what it claims to be. Same with what program generated the log entry. It can even distinguish between two instances of the same program running simultaneously since each and every log entry is stamped with a unique id (and session ID, and machine ID so you can trail logs even if the hostname/IP changes or across multiple machines and OS containers).

As for time based fil

Re:They will care, probably sooner than they think

[Peter H.S.]

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!).

just playing around with "journalctl" for 10 minutes convinced me wholly.

So you've never tried using rsyslog to log to a database then?

Yes, so I know the many limitations of doing so. It is of course of interest to know that Rainer started the Rsyslog project exactly to overcome the many problems with the old syslog(3) interface, especially the problems with flat file text logs.

I have much respect for the Rsyslog developers work and it certainly weren't their fault they couldn't fix all the problems they set out to solve. So I am glad that Rsyslog now can read/write systemd journal files, meaning that it can be used as a log sink (at least for simpler cases) without regressing to using flat text log files.

Re:They will care, probably sooner than they think

[AntiSol]

Yes, so I know the many limitations of doing so

Such as? I've never had any problems.

I adore the power of using sql queries on logs.

How does journalctl fare in terms of having a trigger set up to automatically do things with logs when they're inserted?

Re:They will care, probably sooner than they think

[Peter H.S.]

Such as? I've never had any problems.

I adore the power of using sql queries on logs.

How does journalctl fare in terms of having a trigger set up to automatically do things with logs when they're inserted?

The classic problem was speed. A DB was fine for storing and analysing, but could be severe bottleneck for log sinks.
It isn't so great for local system logging either since DB's tend to appear rather late in the boot sequence.

With journald you can have system logging before the rootfs is even mounted, and since both systemd and journald can pivot back to initramfs after the rootfs has been unmounted, you can potentially have logging after that.

These days it seems that people are using a mixture of DB's and heavily data massaged text logs (JSON etc) combined with a special index (Splunk etc).

There will never a single log storage solution for all, since the tools chosen will reflect the problems trying to be solved. For some it is auditing that is important, for others it is analysing website usage.

But since systemds journal is structured and field based, it is very easy to convert its log entries to standard JSON etc that consistently fits other storage means. A huge improvement over the many different syslog implementations.

Re: triggers. You don't use "journalctl" for that, but the API/libraries/language bindings. systemd provides a really good and well documented framework for making triggers, but don't provide them as such. You can have instantly triggered events on file systems that supports it.
"man sd_journal_get_events" documents the C API:
http://www.freedesktop.org/sof...

But there are also Ruby, Python, Go bindings etc. All in all I think systemd/journald is a major upgrade when it comes to log watchers; stable API, field based filtering, many language bindings, instant notifications etc.

Re:They will care, probably sooner than they think

[Barsteward]

"How does journalctl fare in terms of having a trigger set up to automatically do things with logs when they're inserted?" - can you imagine just how much more shit would be poured onto systemd if the journal did that? It already get 100% unjustified bullshit from the ignorants already trying to say it does more than one thing

Re:They will care, probably sooner than they think

[Eunuchswear]

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

Huh?

$ cat /etc/debian_version
8.1
$ dpkg -l | grep ntp
ii ntp 1:4.2.6.p5+dfsg-7 amd64 Network Time Protocol daemon and utility programs
$ systemctl status ntp
* ntp.service - LSB: Start NTP daemon
  Loaded: loaded (/etc/init.d/ntp)
  Active: active (running) since Mon 2015-06-08 15:20:03 CEST; 24h ago
  CGroup: /system.slice/ntp.service
          \--737 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 105:111
 
Jun 09 10:48:07 celtic ntpd[737]: peers refreshed
Jun 09 10:48:10 celtic ntpd[737]: Listen normally on 7 eth0 192.168.6.107 U...23
Jun 09 10:48:10 celtic ntpd[737]: peers refreshed
Jun 09 14:34:54 celtic ntpd[737]: 192.168.6.253 interface 192.168.6.107 -> ...e)
Jun 09 14:34:54 celtic ntpd[737]: Deleting interface #6 eth0, fe80::d267:e5...cs
Jun 09 14:34:54 celtic ntpd[737]: peers refreshed
Jun 09 14:35:00 celtic ntpd[737]: Listen normally on 8 eth0 fe80::d267:e5ff...23
Jun 09 14:35:00 celtic ntpd[737]: peers refreshed
Jun 09 14:35:03 celtic ntpd[737]: Listen normally on 9 eth0 192.168.6.107 U...23
Jun 09 14:35:03 celtic ntpd[737]: peers refreshed
Hint: Some lines were ellipsized, use -l to show in full.

What are you blathering on about?

Re:They will care, probably sooner than they think

[Endymion]

Even this is something journald does so much better than syslog

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.

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?

# 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?

claiming that regular expressions are easy is laughable.

If regex is too hard, you might as well give up now. Regex is only hard if you abuse it badly, which is true for any programming language. This is just trolling at this point.

Oh, and thanks for admitting you are an inexperience n00b. You may have been using linux since the early slackware days, but didn't seem to learn much.

As for your "challenge", I have yet to see any systemd apparatchik rise to the challenge to prove that systemd isn't an unmaintainable monolithic mess, by showing how to replace (NOT CHAIN) journald with syslog-ng or indeed run any of the systemd components in isolation.

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

Re:Warning if upgrading from Wheezy:

[Narcocide]

BTW ha-ha to all you all you guys who pushed EXT4 before it was ready for prime-time while making fun of those of us still using XFS or ReiserFS. Whose filesystem buried their inodes in the back yard now, huh?

Re:Warning if upgrading from Wheezy:

[danbob999]

ext4 was more than ready when it became default in Debian.

Re:Warning if upgrading from Wheezy:

[Narcocide]

Yea, sure, if you omit "doesn't randomly corrupt filesystem on reboot" from the list of mandatory requirements.

Re:Warning if upgrading from Wheezy:

[danbob999]

It didn't happen to me. I wasn't even aware there was such a large-scale bug. And it's not as if reseirfs or XFS were bug-free either. If I were scared by ext4, I'd use ext3, not reiser or XFS.

Re:Warning if upgrading from Wheezy:

[drinkypoo]

ha-ha to all you all you guys who pushed EXT4 before it was ready for prime-time while making fun of those of us still using XFS or ReiserFS. Whose filesystem buried their inodes in the back yard now, huh?

XFS has eaten some of my data, ext4 never has. Anecdote, data, whatever, XFS can blow me.

Re:Warning if upgrading from Wheezy:

[Narcocide]

You really gotta run that cron job with XFS. I know, its undignified, but XFS is really old.

Re: Warning if upgrading from Wheezy:

[danbob999]

ZFS is GPL-incompatible, it will never reach wide acceptance in the Linux* community (or Windows). Unless your PC has a single purpose of storing files, I doubt the file system is an important enough reason to switch to another OS. BTRFS has similar functionality and is becoming mature quickly, so that will probably be my next file system if I ever need these features or when it becomes the default in Linux distributions.

*Yes, I know there is a fuse project and a 3rd party ZFS kernel module but they both suck compared to a real, integrated file system driver.

Re:Warning if upgrading from Wheezy:

[antdude]

But don't we want to get systemd since it is the future? :( I am just going to stick with oldstable for a while.

Re: Warning if upgrading from Wheezy:

[eneville]

ZFS is a memory hog. I wouldn't advise it. I've seen cases where the file system cannot be imported (mounted) at boot, and that situation is not one that you want when all your important data is in that pool. In general, the FS is poor in performance. Sure, if you value long term data retention ZFS is great, but so is tape storage. Why not just use ext/xfs for live data and tape for historical, then you can keep your RAM and performance. This way you get to store your archives somewhere (like you need to with snapshots anyway) just incase your system catches fire and the eggs in one basket gets destroyed.

Re: Warning if upgrading from Wheezy:

[Eunuchswear]

There is nothing fundamentally GPL-incompatible about ZFS.

The OpenZFS code written by sun isn't GPL compat, but there is no reason why somebody couldn't couldn't rewrite it and release it under GPL. It would be a huge waste of time, but GPL license bickering tends to do that.

Unfair to blame this problem on "GPL license bickering" -- Sun deliberately made their license GPL incompatible.

Re:Warning if upgrading from Wheezy:

[bro2]

So the fact that the bug didn't affect you is an argument for what, exactly?

Re: Warning if upgrading from Wheezy:

[bro2]

Can you explain why the ZFS kernel module for Linux sucks compared to "a real, integrated file system driver."? In my experience, it beats it hell out of btfrs. Maybe it's better in the later kernels (3.16++).

Re:Warning if upgrading from Wheezy:

[danbob999]

who was affected? A bug that affects only 0.0001% of users is a lot less relevant.

Re: Warning if upgrading from Wheezy:

[danbob999]

Every kernel module not in the mainline kernel suck compared to an integrated one. It needs to be recompiled for every new kernel, often breaking things, and in many cases (such as this one), taints the kernel so you loose a lot of support.

Re:Warning if upgrading from Wheezy:

[danbob999]

According to Slashdot it affected only kernels 3.4 to 3.6. I wasn't using any of those kernels so I was fine. It's more an argument against those specific (unpatched) kernel versions than against ext4 as a filesystem.

Re: Warning if upgrading from Wheezy:

[bro2]

I'm not going to discuss the use of ZFS in professional data center scenario, but for other simpler scenarios, ZFS isn't necessarily a bad choice. The data integrity features provided by ZFS is simply outstanding, and is something you do not want to live without after getting used to it. The additional suppport for software RAID makes ZFS the only choice available for anyone on a budget. It's true that ZFS needs more RAM, but that is solved by buying enough RAM. That is far from being a showstopper today. I don't where you learned that ZFS in poor in performance, but these benchmarks doesn't back up your claim: http://www.phoronix.com/scan.p...

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.

Re:Don't care

[juanfgs]

> 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!

Can you imagine what we would do if Arch/Gentoo/Someobscuredistro didnt enlighten us with their particular choice of software???

Keep doing god's work son.

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:There are more reasonable alternatives

[rdnetto]

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.

Honestly, even with systemd[1] Gentoo is actually a pretty awesome distro for a server; definitely better than Debian. The compile-times are less of an issue since most of the really large programs aren't ones you'd install on a server (chrome, libreoffice), and being able to install any of the last N stable versions (sometimes side-by-side using slots) of a package is pretty convenient when you have third party software. The way configuration files are updated after an upgrade instead of during is also much more convenient, and the stable branch is also significantly more up-to-date than Debian's.

[1] While I use systemd on my own system and find it works well for me, I can easily understand why some people would prefer to stick with one of the alternatives (at least until all the bugs get ironed out).

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

[pointbeing]

Though I have not met an actual Debian user who is "totally ok with it".

Nice to meet you, AC. Former Linux sysadmin and current Sid user here; I've been using Debian for years. ;-)

Re:Don't care

[hitmark]

So even with the latest Fedora they have yet to figure out network storage mounting.

And this is supposed to be the backbone of CoreOS...

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:Don't care

[Barsteward]

How is Devuan going, not heard about it for ages.

Re:Don't care

[Barsteward]

fuck me... software has bugs, now who would have thought it..... I take it FreeBSD doesn;t have any bugs

Re:Don't care

[kbahey]

Look at what was posted in the same thread about a serious bug in systemd that was not fixed by systemd developers, nor in Fedora, but was fixed first in Ubuntu, then in Debian 8.1. A mature well tested system should NOT have those kind of issues, which systemd is not.

Here is direct link.

Systemd has been a surprise.

[xtronics]

i had read all the negative stuff about systemd - expected a nightmare - updated a couple of machines - small learning curve - but guess what - I ended up liking it. The system found some bugs for me that had eluded me for a long time.

Big deal - I type systemctl start daemon (tab complete works here) instead of /etc/init.d/daemon . I suppose some of you are just too old to learn anything new. Yes change is work - and I'm lazy - but this is obviously the future.

And despite the disinformation posted here - you could remove systemd if you want - but it would be stupid to.

About systemd - Louder isn't righter..

Re:Don't care

[stafil]

+1

Re: They will care, probably sooner than they thin

[Peter H.S.]

Coward!

When is v8.2 coming out then?

[antdude]

:D

Re:you're a total ponce

[Peter H.S.]

You are just talking bullshit here. I have been using systemd for +4 years now and it has been rock stable.

On a VM on your mom's MacBook that you take down to Starbuck's in a record bag slung over the crossbar of your fixie.

It is exactly because the systemd-hater camp apparently consist of technical illiterates like you, that they have lost each and every technical argument on all major distros. Ad hominem attacks and poisonous threats and trolling systemd threads are all you can do. Almost all volunteer developers have left the non-systemd camp because of its toxic atmosphere where attacking open source developers and users are as normal as breathing air.

Think about it; the anti-systemd faction couldn't even muster 5 Debian developers to sponsor a GR bill to overturn the technical committees decision of making systemd default init.

The negative, hate-driven anti-systemd campaign have resulted in that 100% of all commercial general Linux distros and most of the community driven distros are behind systemd and are supporting it. Talk about a losing campaign strategy.

Re:No, that's not possible.

[Peter H.S.]

Systemd is terribly unstable and rolls state back for trivial reasons. Those of us in charge of data centers see the issues, your laptop or home pc is not a viable model of reality.

What "state" are you talking about. This is Linux/Unix, not a transactional OS. systemd doesn't perform "roll backs". What trivial reason? Maybe that could explain what you are trying to say. It really sounds like you have no personal experience with systemd nor have read anything about it.

Re:Your appeal to authority means nothing

[juanfgs]

look dude you are on dilbert!

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:oh boy

[eneville]

Sorry, you lost me at 5year investment.

The *vast* majority of drivers for Linux are, in the Linux kernel. It has been upwards of ten years since I needed to get a driver from the internet. I think that was for a SB Live card that needed emu10k, it didn't take long before that was included in the Linux kernel. What was the other thing, perhaps it was winmodems. Unsurprisingly they needed drivers and gave poor performance anyway. Nope. I can't see your argument for it being internet dependant. On the other hand, how often do you have to go off to third parties for your drivers on a windows system? Perhaps all the time since there is a lack of generic drivers on windows. Perhaps this is why windows is full of crap and malware due to unreliable third party drivers.

Re:you're a total ponce

[Eunuchswear]

And my company is 100% Debian with systemd.

So what?

Re:Don't care

[Eunuchswear]

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

That is no reason to remove the choice.

What choice was removed? You do know that systemd is an optional component of Debian Jessie? Use sysvinit or upstart if you prefer.

Re:Don't care

[Eunuchswear]

Debian can be a nice server, but i don't like using such old software on the desktop.

What component of Jessie is too old for you?

Re:Don't care

[Eunuchswear]

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

I'm with you.

If they made a netinst CD/DVD/Thumbdrive that had sysvinit by default, I'd consider going back.

Because adding: preseed/late_command="in-target apt-get install -y sysvinit-core" to the kernel boot line is just so damn hard.

Re: Don't care

[Barsteward]

Nope, i didn't respond to myself. maybe that's what you do, but i don't. I'm very happy for there to be a Devuan type distro, it should get rid of all the thick anti-systemd trolls that pollute these forums trolling about something they know nothing about.

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

Re: you're a total ponce

[Peter H.S.]

You mean one developer, who's known for throwing shit together in a crufty way, managed to convince three people at the "PNELV" by either boring them shitless or throwing a tantrum.

No, I mean many many kernel developers, including the guy who maintain all long term stable Linux kernels for the Linux-foundation. Basically the second guy besides Linus Torvalds that the LF employ.

I have seen zero kernel developers backing any other Linux init-system. In fact, the Linux developers seems to actually flee from the rather toxic systemd-hater camp that you and your juvenile behaviour are stellar examples of.

Seriously, who would ever work in a project with a poisonous guy like you?