Debian 8.7 Released (debian.org) 124
Debian 8.7 has been released. An anonymous reader quotes Debian.org:
This update mainly adds corrections for security problems to the stable release, along with a few adjustments for serious problems. Security advisories were already published separately and are referenced where available.
Please note that this update does not constitute a new version of Debian 8 but only updates some of the packages included.
There is no need to throw away old "jessie" CDs or DVDs but only to update via an up-to-date Debian mirror after an installation, to cause any out of date packages to be updated. Those who frequently install updates from security.debian.org won't have to update many packages and most updates from security.debian.org are included in this update.
86 packages have been updated -- including some fixes for systemd. ("Rework logic to determine when we decide to add automatic deps for mounts; various ordering fixes for ifupdown; systemctl: Fix argument handling when invoked as shutdown...")
There is no need to throw away old "jessie" CDs or DVDs but only to update via an up-to-date Debian mirror after an installation, to cause any out of date packages to be updated. Those who frequently install updates from security.debian.org won't have to update many packages and most updates from security.debian.org are included in this update.
86 packages have been updated -- including some fixes for systemd. ("Rework logic to determine when we decide to add automatic deps for mounts; various ordering fixes for ifupdown; systemctl: Fix argument handling when invoked as shutdown...")
Re: (Score:2)
If FreeBSD worked with my tuner devices (cx88 PCI cards and an xc5000 USB device) together with MythTV, I'd consider switching. Might be time to check again.
Drip (Score:3)
worked with my tuner devices (cx88 PCI cards and an xc5000 USB device) together with MythTV
You're like a wet dream for QA people
Re: (Score:2)
cx88 PCI cards
http://corona.homeunix.net/cx8... [homeunix.net]
https://gist.github.com/dreamc... [github.com]
xc5000 USB device)
https://wiki.freebsd.org/Webca... [freebsd.org]
Requires dvb-fe-xc5000-1.6.114.fw firmware
https://www.linuxtv.org/downlo... [linuxtv.org]
MythTV
http://www.freshports.org/mult... [freshports.org]
Re: (Score:2)
Re: (Score:2)
You sound just like an apple fan boy. I have noticed similarities between both. Not that I don't like BSD, on the contrary.
link:
http://www.slackware.com/ [slackware.com]
Estimated time until systemd-related flame war... (Score:1)
...5 parent posts. Tops.
Re: (Score:1, Insightful)
I like systemd, but I went through the SMF transition with Solaris and the complaints were basically the same. Systemd is lightyears better than anything it replaced. If you're an honest person, you'd probably come to the same conclusion.
Re: (Score:1)
Do tell one reason how Systemd has actually helped something? It it were really so great, It would have not interrupted my and other peoples work so often.
Re:One can hope (Score:5, Interesting)
Systemd has helped raise awareness of the *BSDs.
Many former Linux desktop users who were driven away by systemd have ended up using FreeBSD. Many who ran Linux servers have started using OpenBSD instead. Those who ran Linux on older or less-powerful hardware have discovered the joys of NetBSD.
Systemd has turned out to be one of the best advertising campaigns for the *BSDs.
Re: (Score:2)
I used Linux exclusively from the mid-90s until almost exactly two years back. I was aware of the BSDs, occasionally read about them and once installed it for a few hours just to see, but never had any real reason to bother with them. Seemed like it would be a lot of pain for a worse experience, particularly when you had to build all the ports and cope with worse hardware compatibility.
One of my work colleagues is a long-time Debian user. For the last 18 months, his servers are running
Re: (Score:2)
Moving from a pre-systemd to a systemd Linux system fundamentally changes many aspects of system administration and maintenance, not just because of the init system replacement, but also from the replacement of all the other tools which systemd absorbed or replaced, or made mandatory. While FreeBSD has its minor differences, a contemporary BSD system is significantly more similar to a pre-systemd Linux system than a systemd Linux system.
Re: (Score:2, Insightful)
Systemd has turned out to be one of the best advertising campaigns for the *BSDs.
And yet it's market share is quite stable measured at 0.00% and has for the past 3 years for internet servers.
As much as I see this message come up over and over again, the number of people who legitimately shifted to BSD can be counted using your appendages. In the real world BSD's market share increased by only a few people who got upset because they refused to read a manual and decided that changing the OS was the only way forward.
Hurrah.
Re: (Score:2)
Systemd has helped raise awareness of the *BSDs.
Many former Linux desktop users who were driven away by systemd have ended up using FreeBSD. Many who ran Linux servers have started using OpenBSD instead. Those who ran Linux on older or less-powerful hardware have discovered the joys of NetBSD.
The number of sys admins specifically using older distributions or looking at BSD variants where they can is astonishing. There are a ton of bugs to troubleshoot in systemd that can only be solved seemingly by rebooting, and that's not any guarantee. Admins simply don't have the time to debug systemd alongside all the other problems they have.
Re:One can hope (Score:4, Insightful)
Re: (Score:1)
Before SystemD I had no need to understand the init process, just a bit of bash and a the old change to rc.d. init just worked. Now I'm aware of a number of inits capable of providing the functionality of a modern init system without the fundamental design flaws of SystemD or encroaching into all aspects of userspace.
Before SystemD I trust most of the decisions my distribution with regard to packaging or trivially avoid or reverse those decisions. Now I have Jenkins CI, jenkins-debian-glue and a my own repr
And other OpenRC-based distros (Score:1)
In particular, Gentoo. I did (very seriously) consider a BSD -- but would have always preferred a linux distro because I can get Steam working and I saw that the BSD kernel was dropping Linux ELF compat for security reasons (which may make sense -- I'm not here to judge).
I used Debian (or a derivative -- Mint, Ubuntu, and, very long ago, Corel Linux, but we don't have to dwell on that...) for around 16 years. When my Ubuntu box started getting insanely slow, I thought it was perhaps time to just go back to
Re: One can hope (Score:1)
I had high hopes for systemd. I thought it would be like launchd on OS X, which has never caused me any problems. But systemd was nothing like that. It has caused me nothing but problems. It's a lot like GNOME 3. The potential is there, but the reality ends up being awful. I'm saddened that all real Linux distros now force it. I don't want to use a niche distro like Devuan.
Re: (Score:2)
Re: (Score:2)
Yeah this is nothing to do with systemD. Try installing crashplan on *any* distro and feel free to notice that it's using the max open file handles.
I believe crashplan uses inotify()... and if you have any decent count of files to be backed up, you'll hit your sysctl limit of open file handles. What we need is a single handle event notification in the linux (like *bsd kqueue) kernel and it would make these apps a lot simpler and less resource intensive.
Re: (Score:2)
CentOS 7 is systemd-based as well.
Re:One can hope (Score:5, Interesting)
You forgot to add "Run Redhat through a shredder".
I like Red Hat and I appreciate all they've done for open-source in the enterprise, but the desktopification of core Linux aspects is a bad thing. It's fascinating to see how Microsoft took a desktop o/s and shoehorned it into a server product, while Red Hat is taking the perfect server and adding stuff like systemd to make it more convenient for desktop users.
systemd is bad for servers. It adds nothing, just makes everything brittle and clunky. Maybe it's awesome for plug & play devices and soundcards and window managers but none of that is relevant on servers. No wonder even in the CentOS docker images it's not enabled by default - it's USELESS.
Re: (Score:2)
systemd is bad for servers. It adds nothing...
My understanding (which may be wrong) is that the impetus behind SystemD from the server side might be containers. Currently, these can't be managed centrally (AFAIK), but with SystemD...
Just something I heard in passing during a Docker presentation, so I can't provide references.
Re: (Score:2)
My understanding (which may be wrong) is that the impetus behind SystemD from the server side might be containers. Currently, these can't be managed centrally (AFAIK),
What supposedly prevents this? There are many packages for maintaining containers.
Re: (Score:2)
My understanding (which may be wrong) is that the impetus behind SystemD from the server side might be containers. Currently, these can't be managed centrally (AFAIK),
What supposedly prevents this? There are many packages for maintaining containers.
True. Even kubernetes can be installed with yum and can run under the dictatorship of systemd.
Re: (Score:2)
systemd is bad for servers. It adds nothing, just makes everything brittle and clunky.
That's funny given that it was primarily designed with servers in mind. Oh it boots quickly and that makes you think it's "desktopification". How silly.
Re: (Score:1)
systemd is bad for servers. It adds nothing, just makes everything brittle and clunky.
That's funny given that it was primarily designed with servers in mind. Oh it boots quickly and that makes you think it's "desktopification". How silly.
If the boot time is critical for your servers and shaving just few seconds, then you are doing it wrong. You should study how set up active/passive cluster setups or if that isn't enough how you set up active/active cluster with load balancing, context switching or with reverse proxies. That's how you keep providing services while being able simultaneously to do maintenance and even migration to newer system without outages. And when you get good at it reaching five nines isn't even too hard.
Also, regarding
Re:One can hope (Score:4, Informative)
That's funny given that it was primarily designed with servers in mind.
Not sure that's true. It was inspired by launchd from Apple [0pointer.de] (specifically this video [youtube.com]). Personally I think launchd is cleaner, but that's partly because Apple has full control of the ecosystem.
Re: (Score:2)
systemd is bad for servers. It adds nothing, just makes everything brittle and clunky.
That's funny given that it was primarily designed with servers in mind.
Of course! That must be why the documentation is hosted on "freedesktop.org", which is self-described as "an open source / open discussion software projects working on interoperability and shared technology for X Window System desktops".
Re: (Score:2)
Yeah it's almost like a fundamental part of the system can have two purposes. Amazing isn't it.
Instead try and look up what it does and why it does it rather than championing the name of a domain which is hosting their documentation.
Of course (Score:2)
Yeah it's almost like a fundamental part of the system can have two purposes.
Ah, so either when you said "it was primarily designed with servers in mind" you were making shit up, or you are when you say that it fundamentally has two purposes. No need to explain further, you're busted.
Re: (Score:2)
I like Red Hat and I appreciate all they've done for open-source in the enterprise, but the desktopification of core Linux aspects is a bad thing.
Uh you realize Red Hat only has one little side project for workstations and it's essentially the server version with a GUI and a cheaper license? Fedora is just their testbed, they don't care about the desktop. For me it's pretty clear that the core feature of systemd is resource management for containers and other forms of light virtualization. If you run a dedicated server, you don't need it. If you use a hypervisor and full VMs you don't need it. If you want to "app-ify" your servers with Docker then sy
Re: (Score:2)
I'm sorry you don't actually administer any servers and therefore can't appreciate it.
Good point. Nowadays we have $15/hr visa workers for that - they get along very well with their counterparts when they call Red Hat helpdesk - maybe I could put you in touch in case you're looking for a job. I hear Infosys is on a hiring spree this winter.
Re: (Score:2, Insightful)
And here its made my life much easier and I've had zero issues with it. I hate Pottering as much as anyone but if something he's done has made my life easier, the way systemd has, then kudo's to him.
Your post however contributes nothing.
Re: (Score:2, Insightful)
Your post however contributes nothing.
My post doesn't try to take Linux over one feature at a time by replacing things that were not broken with more and more legs of the same octopus. I'm happy if systemd made your own life easier but that doesn't mean everyone should bend over and take it quietly.
Re: (Score:1)
Ofcourse ot does. Most of us happily moved to systemd. Good luck convincing us it's faster to learn FreeBSD then Systemd. And Btw, i used to use FreeBDS (versions 4 and 5) and liked them quite a bit. Moved away to linux mostly to reduce maintainance.
If others went to FreeBSD, good for them. Good for BSD, they need more users. But nobody cares about your philosophical view. You think you are forced to systemd or entitled to systemd free distro, well, go fund it. Majority has no problem, it's only the vocal m
Re: (Score:2)
Majority has no problem, it's only the vocal minority that distorts the picture.
And you know that how?
Re: (Score:2)
No I mean how can someone talk on behalf of the "silent" majority
Re: (Score:1)
And here its made my life much easier and I've had zero issues with it. I hate Pottering as much as anyone but if something he's done has made my life easier, the way systemd has, then kudo's to him.
Easier? Probably millions of wasted man hours and you call it easier? Whether it's the broken documentation (which is voluminous but useless because it misses key facts all over the place - a bit like Microsoft documentation; written by documentation "specialists" so it looks pretty but doesn't actually tell you what you need to know because the "specialists" are ignorant about the system they're supposed to be writing about) or the broken dependency management (which has race conditions all over the place,
Re: (Score:2)
Easier? Probably millions of wasted man hours and you call it easier?
Microsoft keep doing that with their new "features" and people keep paying them.
Re: (Score:2)
... was sysvinit really that better? I was under the impression that you're picking between a brand-new pile of shit, or an old-fashioned and badly outdated pile of shit.
Re:One can hope (Score:5, Informative)
The old pile of shit was willing to keep its fingers out of other people's pies if you wanted to try something else along side it.
It also understood imperatives. If you tell it run something NOW, it does just that, every time.
Re:One can hope (Score:5, Insightful)
More importantly to me, I've used the old pile of shit for 20 years. I know how it works, I know its quirks and shortcomings, and I'm comfortable with all of that.
I have no particular aversion to trying new things. I ran ntpd for years, now I use chrony. I ran exim for years, now I use postfix. I ran apache for years, now I use both apache and nginx. I ran cvs for years, then svn for years, and am now aboard the git train. I was able to gradually step through all of those changes and take time to learn them properly. And when something went wrong along the way, the problem was isolated and I could troubleshoot it in isolation.
systemd on the other hand wants to implant itself underneath every aspect of the OS like a kludgey layer of Elmer's paste, where even such basic functionality as DNS resolution wants to worm its way through an unnecessary and complex intermediary service. Not to mention that when systemd goes tits up, it has a tendency to take the entire machine with it.
No thanks.
Re: (Score:1, Insightful)
The old pile of shit was willing to keep its fingers out of other people's pies if you wanted to try something else along side it.
Oh? I never realised that systemd was the only way to start and stop programs? You want to use systemd just to boot the system and then revert to using xinetd to dynamically start your services, followed by a lot of rc scripts (fun fact, systemd can simply run them for you). Then you go right ahead. It's a very strange form of sadism but I'm not going to judge.
It also understood imperatives. If you tell it run something NOW, it does just that, every time.
Yep, one of it's worst features that lead to a lot of dependency related headaches and failed startups simply because something was done in the wrong
Re:One can hope (Score:5, Informative)
Actually, I want to to use other tools to help boot the system. With sysvinit, I can easily plug modules at will.
because something was done in the wrong order.
I know it sounds like a really radical idea, but howsabout just specifying the right order?
But here's an example: I was testing a system with BTRFS doing mirroring. As part of the test, I dropped one of the disks to simulate a failure. Systemd flatly refused to start in degraded mode. It dropped to the shell every time. There was no way to tell it "Just mount the damned thing and let me worry about it". So much for high availability. Under sysV, I just added the degraded option and it worked every time. If I want to wait an arbitrary amount of time for all the drives to spin up, I can do that in the mount script with no difficulty.
Literally anything systemd can do could already be done using simple helpers called by sysV. You even provided an example yourself.
Re:One can hope (Score:5, Interesting)
Re: (Score:1)
So the "don't boot if a single filesystem in fstab fails to mount" policy would have been a tweak to the mountall script (or better, one of the mount helper shell functions).
Or you define your filesystems correctly as something that is important to boot the system or something that is not. If it needs to be automounted then why would any sane boot process not fail? The previous behaviour is what generated a shitton of filesystem related problems from programs that started blindly reading and writing to directories that didn't exist on file systems that weren't mounted.
Anyway this is irrelevant since this is a bug in btrfs, and no other redundant FS fails this way with systemd.
Re: (Score:2, Informative)
With sysvinit, I can easily plug modules at will.
I'm going to assume you didn't RTFM if you're having problems with modules and when they get plugged.
I know it sounds like a really radical idea, but howsabout just specifying the right order?
The right order is stable during one scenario only, a controlled boot. It was a good idea in the 70s, but it's a truly horrible way to run a system of interdependent daemons, especially when boot time is such a rare state to be in for a server.
I was testing a system with BTRFS doing mirroring. As part of the test, I dropped one of the disks to simulate a failure.
So you were using an experimental filesystem and complaining that your system didn't boot in degraded mode? It's quite telling that when you search online for the issu
Re: (Score:3, Informative)
I'm going to assume you didn't RTFM if you're having problems with modules and when they get plugged.
Not KERNEL modules, init system modules.
The right order is stable during one scenario only, a controlled boot.
You prefer an out of control boot? Not sure what you mean there.
BTRFS hasn't been listed as experimental for some time now. It is considered usable in production now. The problem wasn't BTRFS, the problem was systemd trying to be clever when it really isn't. It would refuse to even attempt to mount btrfs until all disks showed present. It offered no timeout. I did have the degraded option set, such that when systemd inevitably dropped me to a shell, I could just type
Re: (Score:2, Informative)
You prefer an out of control boot? Not sure what you mean there.
I can tell. There's one scenario where a specific order applies, boot time. It's also a time you don't normally find yourself. So having an entire process manager with hard coded order is asinine and is the number 1 "feature" that every single other init system has removed.
BTRFS hasn't been listed as experimental for some time now. It is considered usable in production
By who? Certainly not the project team who say that only the physical disk format is stable, and the rest of the project is still under heavy development including the caveat that bugs may creep in.
The problem wasn't BTRFS, the problem was systemd trying to be clever when it really isn't.
Nope the problem was udev (nothing to do
Re: (Score:2)
I can tell. There's one scenario where a specific order applies, boot time.
If you can tell, one might expect ypu to make an effort to communicate more clearly. If you find you cannot, then you should clerify your own thinking first.
Boot time is also the only scenario where initializing the system is relevant. All those other systems failed to catch on, probably because non-deterministic system initialization is problematic.
By who?
By the kernel configuration, SuSE, Facebook, Tripadvisor, and a number of other operations using it in production.
Either way, systemd needs to be flexible enou
Re: (Score:2, Informative)
We never had that much modularity in the first place. Most distros all used the same core components anyway. But if you want to you can still disable pretty much any systemd component and replace it with whatever you want. I do that in Docker, I have lots of containers that use only systemd as init and journald, and my app. Nothing else is running in the container, and if I wanted something more I could easily have systemd start it for me.
Re:One can hope (Score:5, Informative)
We previously had these components:
Not only is it modular, the system is fully composable, allowing the admin to build each layer upon each layer to their own liking. The layers are not tightly-coupled, and it's entirely possible to replace any or all of the layers:
When people complain about sysvinit being old and outdated, these claims are usually considering the sysvinit+sysv-rc+initscript triad as a single entity. sysvinit is old, but it's a tool with just two purposes: running specified programs and runlevel switching. You can build anything you want on top of that. It does exactly what it was designed to do, and *only* what it was designed to do. It's not broken, and never was. If you want more functionality, you build that on top of it.
Some parts of the old system were crusty, for example dynamic networking configuration. But the vast majority worked pretty well, and pretty efficiently. And it would have been perfectly possible to fix those issues, with vastly less effort and disruption than throwing it all away and breaking much backward compatibility in the name of inter-distribution uniformity (and consequent stagnation).
Note that while common distributions came with their default, it was absolutely possible to run with all sorts of different combinations of components; Debian supported several. file-rc was a supported alternative to sysv-rc, and daemontools and other alternatives were also available. It's this very flexibility which allowed systemd to be swapped in relatively easily. But consider that once systemd was adopted, the vast majority of this flexibility was lost. The low-level init, the rc runner and the initscripts are all in one place, and it's no longer possible to swap one part for another or tweak one little bit. It's all or nothing, and that will effectively entrench it. As an ex-Debian sysvinit/sysv-rc/initscripts maintainer, I wasn't dictating that you use them all together. You want to use openrc, or daemontools or s6? Go for it, you don't need me to approve it, you do what you like. Want to change the initscripts around to do something different, be my guest. We took care not to break any custom setups on upgrade as well, e.g. preserving file-rc configuration when adding/removing/upgrading packages, as well as helper script API stability. Contrast that with the top-down dictatorial approach which comes from the systemd people: you'll use the system the way we tell you to, and no, we don't approve of you doing anything non-standard unless we like it (and good ideas only come from us, so forget it). And if you do change stuff and it breaks, that's 100% your fault since we don't care to consider this. That's the real difference, the attitude and thought behind the design, and how that affects your freedom to use your system as you see fit. And that's one major reason why my servers now run FreeBSD.
Re: (Score:2)
This needs to be +6 Informative
Re: (Score:1)
> And it would have been perfectly possible to fix those issues, with vastly less effort and disruption than throwing it all away and breaking much backward compatibility in the name of inter-distribution uniformity (and consequent stagnation).
Sure, but "Coordinated with twenty other projects to significantly improve the state of Linux service management" looks far less impressive on one's resume and in the annual bonus meeting than "Wrote groundbreaking, revolutionary init and service/network/cgroup/et
Re:One can hope (Score:5, Insightful)
What was a better way, the UNIX way, was having multiple interchangeable options for any particular cog in the machine. No reliance on a sole supplier. In Debian even HURD or BSD could be swapped out for the Linux kernel in a semi-official, if experimental, way.
Avoiding a mono-culture has huge industry implications for surviving horrific infrastructure bugs, engaging competition and A/B tests, and filling niches with the best tool for the day's particular job. If systemd was truly optional in official Debian there would be no crisis, no endless talking past each other hate filled forum threads. Instead there was an unfortunate slim-vote by a Debian technical committee and major community damage to the project with a large number of DDs and contributors losing passion for the greater project. Which is the real horror and tragedy of the thing.
Re:One can hope (Score:5, Insightful)
"The UNIX way" was to have multiple, not quite compatible, complete operating systems from multiple vendors such as HPUX, Solaris, IRIX, etc. Porting your software between those was a considerable effort, and in fact a whole standardisation body (posix) has sprung up around efforts to make those systems at least nominally compatible. And in later years, the Linux way was quite similar, with LSB attempting to keep distributions at least nominally compatible with each other, but the effort of porting an application from one distribution to another still going by the name of "porting".
I have no idea in which dimension your UNIX way happened, but it wasn't this one.
Re:One can hope (Score:5, Insightful)
You are twisting the meaning to fit a particular straw man you want to knock down. I obviously wasn't talking about Berkley vs. Bell Labs UNIX as being interchangeable cogs and was talking about the philosophy governing the interaction of the various sub and support systems within a modern Linux deployment.
Re: (Score:1)
The only way I can read your original comment is ‘you can swap out any part, including the kernel, and this is the Unix way’. As Johannes said, this a) isn't true and was never true and b) has never been the Unix way. What you said was wrong, and there's little point in claiming you meant to say something else.
Re: (Score:2)
complete operating systems from multiple vendors such as HPUX, Solaris, IRIX, etc
Using HPUX and IRIX as an example of the unix way only shows you don't understand what the unix way is. Suggested reading here [catb.org].
Hint: it's significantly more sophisticated than "each tool does one small thing." For people who think that's the Unix way, they need to read the afore linked to page.
Re: (Score:2)
"The UNIX way" was to have multiple, not quite compatible, complete operating systems from multiple vendors such as HPUX, Solaris, IRIX, etc. Porting your software between those was a considerable effort, and in fact a whole standardisation body (posix) has sprung up around efforts to make those systems at least nominally compatible. And in later years, the Linux way was quite similar, with LSB attempting to keep distributions at least nominally compatible with each other, but the effort of porting an application from one distribution to another still going by the name of "porting".
You know, I have worked for something like 30 years as a UNIX developer, later sysadmin - HP-UX, AIX, SunOS, DECOS, Linux (most HW architectures: POWER, zArch, Intel/AMD, SPARC, etc), even USS (UNIX System Services under MVS) - and the one thing that stands out to me is how easy it is, in practise to move from one to the other. As developer, I was part of a team that wrote C code which was compiled to all our UNIX systems, and while there were one or two quirks to work around (most notably HP-UX's tendency
Re: (Score:2)
"The UNIX way" was to have multiple, not quite compatible, complete operating systems from multiple vendors such as HPUX, Solaris, IRIX, etc. Porting your software between those was a considerable effort, and in fact a whole standardisation body (posix) has sprung up around efforts to make those systems at least nominally compatible. And in later years, the Linux way was quite similar, with LSB attempting to keep distributions at least nominally compatible with each other, but the effort of porting an application from one distribution to another still going by the name of "porting".
I have no idea in which dimension your UNIX way happened, but it wasn't this one.
Perfect troll or perfect idiot? No idea. Don't care.
Re: (Score:2)
... was sysvinit really that better?
It worked.
Re: (Score:2, Insightful)
Christ Almighty. Overreact much? If you don't like it, either switch to a distro that doesn't use it or move to BSD.
I was expecting systemd to be a steaming turd based on all the hysterical screaming and tears from parts of the Linux community. The reality is I've been using it at home just fine for a while now, and we have production servers at work using it without a hitch.
Debian with no pain packages?? Hmm.. (Score:1)
Thank you Debian maintainers (Score:4, Informative)
Have just reinstalled Debian after 17 years away from Linux on my home machines. I have to say I'm impressed. It worked on a 2007 MacBook without any messing around. Graphics, sound, fan speed, touchpad, brightness and volume buttons, sleep etc. all worked out of the box. The default desktop looks good. The fact that it's a root distribution and not derived from something else makes it feel solid. I'm liking it. I'm liking it a lot :-)
Re: (Score:2)
Been using systemd for nearly 5 years now and have never had a boot problem from it yet. I hear scattered reports of the occasional problem but there's nothing like the problems you claim to experience on a regular basis.
Short shell scripts? Have you even looked at an an init script the last 10 years? Init scripts are anything but short and simple. There are good reasons all the commercial Unixes moved away from SysV init long before Linux did. Systemd logging is actually quite good and verbose. I still
Re: (Score:3, Interesting)
Been using systemd for nearly 5 years now and have never had a boot problem from it yet.
Probably because you aren't actually 'doing' anything that presses systemd beyond the most simple use cases.
I bet you don't, for example, use NFS mounts, or NAS, or run applications that fail to release mounts when systemD tells them to shutdown. I bet you've never had to sit on a console watching a server hang on shutdown because systemD has walked its self into an impossible loop waiting for an application to quit, which is waiting for a drive write to finish, which is waiting on a mount that's been dis
Re: (Score:2)
The best fix for systemd.. (Score:1)
...would be to get rid of systemd.
How To disable SystemD on Debian 8 (Score:3)
http://without-systemd.org/wik... [without-systemd.org]
http://jrigg.co.uk/linuxaudio/... [jrigg.co.uk]
I did it, and it works perfectly if you don't use any Gnome & co. stuff.