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.
A little? GNONE is garbage these days that you avoid with a 20ft pole. If you want to run some other window manager, like blackbox or xfe, then GNOME apps are terribad. There is no window title because they no longer use standard calls to create their windows.
I basically removed things like Evince and replaced it with much more usable qpdfview, and that is only because of terrible user interface in GNOME.
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"
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.
I have been using Gnome 3 on Fedora for about a couple years now, and I honestly can't understand why people don't like it. In fact, I don't really feel like using other UI's anymore because Gnome 3 is too efficient. Yes, it still has its quirks. The title bar is a little big and gets obnoxious when you maximize some applications, but I'm willing to accept that in order to get everything else it offers.
The best thing about Gnome now is that it doesn't get in my way. Switching apps/windows is easy. All the useless crap I don't need to see has been taken off the screen. The application launcher is nice, though nothing particularly innovative because anyone who has used Mac OS X or Windows 7 knows what it's doing.
I'm guessing that people who don't like Gnome 3 never really learned how to use it, like people who say they hate vim. Learning how to use Gnome 3 isn't even that challenging in itself, as the main keyboard shortcuts are very standardized. Launcher and window behavior are exactly what you'd expect them to be. It's fast and sleek, end of story.
Also it can't be denied that the desktop has undergone appreciable improvements with literally every release. Two years ago the keyboard layout switcher was broken, but now it works beautifully (this feature is important to me because I switch layouts a lot). Fedora 22 has just gone into beta, and if you want to see what Gnome is like now then you can give that a spin. Like I said, I don't use anything else anymore, although when I want to remember what using Windows XP was like, I'll load up KDE or XFCE or LXDE or something. Plus if you're really that attached to Gnome 2, Gnome 3 got a "classic" mode several releases ago which basically duplicates Gnome 2's UI features. You'll get your drop-down app menu back and the little task bar at the bottom.
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.
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
I am just saying FreeBSD is a system made by sysadmin to sysadmins and not overrun by political bastardos. I sincerely doubt they will go the same route.
The co-founder of FreeBSD have already stated that systemd is a good thing and it is exactly what FreeBSD needs for the future:
https://www.youtube.com/watch?...
There are already *BSD developers working on this, including a systemd compatibility layer. So yes, FreeBSD will have a systemd clone init system, and binary log files too, it is only a matter of time.
So the twice a year I reboot is faster? That doesn't mean a damn thing to most Debian users. Ignoring stderr, nonzero exit statuses, and syslog messages is a much bigger deal. With those problems, systemd makes it nearly impossible to troubleshoot problems.
This has been debunked already: http://news.slashdot.org/comments.pl?sid=7312219&cid=49545633.
Never used RHEL7, and if they do in fact have a buggy version of systemd, well, that's their problem (and please take it up with them, because if you are using RHEL, you're probably also paying them), but Debian 8's version does not have this issue, so claiming it here in this thread about Debian is quite disingenuous. Repeat after me: systemd in Debian 8 does not throw away stdout/stderr from services. (Unless you explicitly tell it to, i.e. StandardOutput=null. The default value is syslog, btw.)
Regarding exit codes: systemd is actually vastly superior to the init script mess when it comes to exit codes:
1. It can also keep track of exits after the daemon was already initialized. And you can do neat things like Restart=on-failure to restart a service if it suddenly exits with a non-zero exit code, for example.
2. If you have the situation that service B requires service A and is ordered after it (b.service contains both Requires=a.service and After=a.service, if service A fails, systemd will NOT attempt to start service B afterwards, because it now knows that it won't work. If you boot with sysvinit + traditional init scripts, the exit code of the first init script is silently ignored and the second is always started, because the scripts that themselves call the init scripts at boot (or runlevel change in general) don't know about the dependencies between services.
Both things are nothing unique to systemd, there have been other solutions that can do the same (upstart being one of them, for example) - but it's really telling that the solution that a lot of people here yearn for, i.e. sysvinit + init scripts, can't do either of those.
And to go into a bit of depth in regard to the example discussed in the comment I linked, because apparently people can't really wrap their heads around it: systemd is not ignoring that exit code, not even the slightest. The only question here is: when does systemd consider the service to be started?
With traditional init scripts, since they were called synchronously, the only way to start a service was to have the service fork and close its original process. The boot could then proceed, and the service would be started in the background. But with systemd, the service doesn't have to fork itself in order to properly start, because it's always going to be started by PID1 directly. That simplifies tracking the service, but introduces another problem: when do we know when the service is finished starting? With forking services, this was straight-forward: the service forks, initializes and the original process exits only after initialization is complete, so a zero exit code from the daemon's original process indicates that is has been started properly (although a lot of services didn't actually do that properly, btw., they'd just fork, exit and then do initialization in the child, which means the child could die instantly but the init script would still think everything went smoothly). But if a service doesn't fork, then you need a different way of telling when initialization is complete. systemd provides various ways of doing so:
Type=simple: this is what was used in the example. Using this setting (the default), systemd will simply start the service and if the program could be started at all, it considers it to be successfully initialized. That means it won't wait for the program to exit or do anything here. And for this reason, in the example linked, systemctl start appears to think
it does not halt and wait for a rescue cd. It waits for the set timeout to expire(5 mins afik) but dont let facts get in the way of a good troll.
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
You mean untested, unaudited code that is forced into production environments?
systemd code is both thoroughly tested and audited. In fact, Red Hat has a professional security audit team that actively audit systemd code, this is more than can be said for OpenRC or SysVinit or any other systemd alternative.
They also have integrated Coverty static code checking and good coding guidelines to ensure maximum security.
systemd have been used by distros since 2011 (It predates the Linux kernel 3.0 series) and some of its code like udev goes back to 2003. It is much better tested than most other Linux software.
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.