Slashdot Mirror
Debian 8 Jessie Released
linuxscreenshot writes: After almost 24 months of constant development, the Debian project is proud to present its new stable version 8 (code name Jessie), which will be supported for the next five years thanks to the combined work of the Debian Security team and the Debian Long Term Support team. (Release notes.) Jessie ships with a new default init system, systemd. The systemd suite provides features such as faster boot times, cgroups for services, and the possibility of isolating part of the services. The sysvinit init system is still available in Jessie. Screenshots and a screencast are available.
here we go...
Guess it's time to change my email address...
"Freedom in the USA is not the ability to do what you want. It is the ability to stop others from doing what THEY want"
The screenshots aren't looking bad but that Gnome quest for removing menu bars goes a bit far. What if you find yourself with no free space in a file manager window to right-click on. I tell people to use "Edit / Paste" or "File / Create a new folder" in that case.
Stop. That's the problem, right there.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
If systemd is in Debian, we might have consider that it won, even though there was a ton of backlash. Time to go read the docs on that animal, or I'll be plain old granpa neckbeard a lot sooner.
Just did an install in a vm. No. There is no option to choose an init system. systemd is default. If you want to use sysvinit, you have to do it via a pre-install script which basically means, netinstall.
"Freedom in the USA is not the ability to do what you want. It is the ability to stop others from doing what THEY want"
I haven't seen any sign of that anywhere and I saw the opposite on a eeepc by about half a minute when I put a newer distro with systemd on it. Is there any proof or are the faster boot times just on the wish list?
They certainly have to continue to improve before systemd becomes a more worthwhile option than the things it is replacing.
The only problem systemd solves is to replace things so old that they are maintained by people that have been coding for longer than Lennart Poettering.
People be aware of some caveats upgrading. Been testing it in the last year, and using it since news year eve in less critical systems in production. systemd has to be pinned to -1 or your servers will get upgraded to it without any interaction from your part. Beware also that Apache configurations change. Some configurations might get broken. libjpeg8 was missing and docker.io still is; backports may solve this. Apache configurations changed a lot. Be also aware that things get installed by default, for instance I had to delete rpcbind from most of my servers. Be also aware open vmtools gets a little confused after the upgrade and needs to be upgraded explicitly.
Let's see here. First I heard "systemd" was coming. I had no idea what it was. Then, running Mint 17.1, I found out what it was, switched to Ubuntu 15.04 to find out. I had heard horror stories how bad it was but I thought the people complaining must be some "old lazy system admins" how learned something new 20 years ago.
Ok, so here I am in Ubuntu 15.04. I see the shutdown/reboot process is fast. Why? Because the shutdown part of the reboot is fast, not the actual startup (compared to Ubuntu 14.10). I find out probable reason why it is that way. Normally processes are first sent the SIGTERM signal to make them quit in a controlled way. But that needs some waiting.
Now I see the new behavior is to just reboot/shutdown without waiting. Any unfinished editing is lost, connections are torn down forcefully. Why? Because this is the way it should be: http://lists.freedesktop.org/archives/systemd-devel/2014-October/024452.html
Then I read more about this attitude from Wikipedia: "For instance, Poettering has advocated speeding up Linux development at the expense of breaking compatibility with POSIX and other Unix-like operating systems such as the BSDs.[12][13]".
I'm not anymore so sure about this. Personally, I will switch back to Mint until the regressions are fixed. What is the current progress and why do we have this type of "cowboy coding" process in place for standards and/or "de facto" functionality/dependencies? Why are there so many in Slashdot creating comments such as "Do you really think that systemd will kill your wife and eat your dog"?
After using and developing Debian for 18 years, this is the first release I have no plans to use, all thanks to the gnome and systemd idiocy. It hasn't been a nice experience, seeing a system build up with loving care by so many people over so long being willfully trashed by a small handful of people. I for one have no interest in being RedHat's bitch; if I wanted to be, I'd be a suffering Fedora or CentOS user. Debian has lost its independence and freedom.
I've been using FreeBSD for nearly 18 months now, and rarely boot up Debian on my systems or VMs. Going back 5 years, I'd never have imagined this is the way things would play out. Tragic.
I've used it in production for five years (5!) now. Just because Debian is slow to adopt new technology doesn't mean that it's untested. People have used systemd in real-world production systems on other distributions since 2010, and has been around for a couple of years before that.
Really, that long? Funny, because according to the systemd Wikipedia page the initial release was March 30th, 2010. The Wikipedia page itself wasn't started until August 2010, and Poettering's systemd announcement, where he mentions having an "experimental" init to compete with upstart (which had been around years before systemd) is dated April 30th, 2010.
That means that, no, it wasn't around a "couple years before" 2010, and wasn't added to any distro repositories until a year later, so your claim to have been using it on "production systems" for "five years now" is just as much bullshit as the claim that systemd existed years before 2010.
The only way you've been using systemd in production that long is if you're from the future and using systemd-timetraveld.
What compiling? I have a farm of virtualized Debian 8 servers and they have been chugging happily in the last few months with systemd pinned to -1. And who are you to tell others to shut up and suck it up?
GP is reading from his own CV. He also has 3 years experience in doing the needful with Java 9.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Ok. Yes. It seems to work. Just append this to the end of the boot string after pressing tab and you'll have a sysvinit system:
preseed/late_command="in-target apt-get install -y sysvinit-core"
"Freedom in the USA is not the ability to do what you want. It is the ability to stop others from doing what THEY want"
Anecdote 1: I've just timed a Debian Jessie single CPU hard disk based VM install with BTRFS as the filesystem, a GNOME 3 desktop where the user is auto logged in boot and where an autostart script records the time. Here are my rough systemd and sysvinit results (times are from after the kernel core finished to when the GNOME script ran):
sysvinit (apt-get install sysvinit-core)
First boot: 20 seconds
Second boot: 18 seconds
Third boot: 19 seconds
systemd (apt-get remove sysvinit-core)
First boot: 15 seconds
Second boot: 16 seconds
Third boot: 15 seconds
sysvinit averages 19 seconds, systemd averages 15.33 seconds. In this case it does appear that systemd booted the system faster.
Anecdote 2: Same as above but where the VM's disk is sitting wholly in RAM. Time for sysvinit dropped to 5 seconds and the time for systemd dropped to 4 seconds.
My personal guess is that the more you are running, the slower the disk the more likely systemd is to benefit you. You don't say how you did your comparison though or what type your "disks" were. If your comparison was between different versions of Linux distro then it could simply be that the previous version did less (which is always the fastest way to boot)...
Another anecdote: a few years back I saw Slackware systems at a University converted over to systemd. Boot times (which involved waiting for multiple NFS mounts) went from over three minutes to down to less than a minute because more of the waiting was done in parallel.
So now you're worried that someone will be able to hack systemd by making it exit a poll(2)?
systemd pid 1 may have sockets opened and bound but it doesn't read from them. How are you going to hack that?
Watch this Heartland Institute video
Really? It's the apocalypse?
Look, I don't like systemd from a design perspective. But it does do one or two things really well: It's standardized init scripts between each distribution and it has full process control. It can track a process no matter how many children it makes.
It does way too much other stuff too. The binary logs are dumb. It's not small and modular. Yada yada.
The biggest problem which needed to be solved was full process management and none of the other projects were really getting anywhere.
It sucks. It shows that Redhat controls way to much. Other projects weren't able to get in. Yea I know. But it's not causing systems to go unstable and crash all the time. Put some perspective into it.
Just upgraded my hobby server from Wheezy to Jessie. sysvinit was upgraded and remained as the init.
The only bits of systemd in the system are the libsystemd* libraries.
Maybe you have a service which has some systemd dependency?
This beta crap has been imposed over us unnecessarily and politically. Debian also got out of its way and is updating all servers to systemd without our asking, and without any visible dependencies, breaking configurations in the process. This is far more than "noise", what you have is fellow technicians and users, your customers and peers, for christ sake, telling you they are not happy. Many of us that have been months already using Debian with systemd pinned a testimonial that this would not be a required situation. To add insult to injury, everyone that speaks about this tabu is told to suck it up, man up, or that just is making noise. This is the antithesis of Debian and opensource. Debian and linux in spirit is about choice and flexibility, and many of us deflected from Windows and other flavours of Unix just because of that. We have been betrayed and sold. To the ones that say this was a consensual and democratic process. A true free and open process would be to include a choice at installation/upgrade time between the choices. If I do have a choice on the web server, on the DNS server, on the mail server, even on the kernel, on the shell that I deliver for my users, despite having defaults, than why, for christ sake, is systemd being rammed down our throats? Get a grip you and honestly, fuck you all. xxxx
No, you don't have to do it with preseed. Just sudo apt-get install sysvinit-core. At any time, for the entire lifecycle of your installation. You can switch back with sudo apt-get install systemd-sysv at any time too. Change back and forth at will; I have, and whilst I initially had big problems with it, Debian's packaging now even has filled in the gaps that the systemd project themselves seem uninterested in fixing, such as full crypttab support/compatibility that the old sysv/cryptmount ecosystem had supported.
Don't get me wrong, I was a pretty loud critic. Right now I work on embedded ARM where most COM vendors are still - in 2015 - selling brand new kit which can barely run kernel 3.2, let alone 3.7 required for cgroups/systemd - most systemd fanatics try to tell me to compile from mainline kernel sources, which ignores the fact that these things are all one-of-a-kind once-off type systems where I'd have to port the shitty once-off BSP code which barely made it over the wall in the first place (which I have done - and took weeks on my last attempt, due to shitty quirky b0rked interrupts on the MMC interface for that board), not just "yolo, git pull && recompile dawg # to hell with re-certification and customer revalidation" that web hipsters seem to assume is the case.
But honestly, the technical committee in Debian were the ones we entrusted to make this kind of decision, so it's a meta-lesson in community participation. You can make all the RedHat conspiracies you want but at the end of the day the technical committee volunteers decided it was too much work (read: they didn't have the help like you or I around) to take on spinning a distro with the option to install without systemd.
So all I'm saying is that the Linux ecosystem is shit, but we have only ourselves to blame.