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"
More liek PWNNering amirite giuz?
Bad news
http://michaelsmith.id.au
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.
wait for first update. they released, again, without actually following their policy (which they are so anal about otherwise, re: docs, firefox, etc) of actually getting rc bug count to 0 before release. following historical trends of bug closure towards release, i was not expecting jesse until late summer at earliest.
Lulz. Startup with Kubuntu 15.04 takes twice the time as with 14.10. systemd reduces boot times, my ass. Maybe it smokes Upstart and OpenRC in microbenchmarks, but didn't we learn something about microbenchmarks in the 3DMark days?
Thanks to its rolling release Unstable branch, I haven't installed Debian in a long time. So this question is directed to those who are planning a fresh install. Does the Jessie installer give a choice between init systems? I know I can choose the default and then change using apt-get, so this for now this is more of an inconvenience than a dealbreaker.
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.
Isn't there at least one mainstream distro that isn't going along with this systemd madness? To quote brilliance seen on slashdot:
Many features.
In the bloat.
Off to FreeBSD.
In a safety boat.
burma shave
nt
They must have noticed all their downstream forks are using systemd and decided it was time to change.
If systemd is in Debian, we might have consider that it won, even though there was a ton of backlash
Unlike closed-source environment such as Windoze / Apple, those of us using Linux will always have a choice
Instead of 'read the docs' we have the choice of going to other distros that do not use systemd
Copping out is never the Linux users' way
chaotic forces of the universe, into Fair Scheduled Pottering-engineered equality init system. Libtards have one less thing to complain about.
It's a bit sad to see that the summary only speaks about systemd and merely links to the release notes for the rest. This is a great release with lots of improvements. GNOME 3.14, LibreOffice 3.4, GCC 4.9.2, Perl 5.20. I'm still trying to figure out what the -ctk9 will do with the kernel. There's also much improved UEFI support. So much more than just systemd happened in this release, something which a lot of users don't even have to interact with, it's a shame that's all that the summary talked about.
Perhaps it will kill your glorified memories of how GNU/Linux used to work. Things are changing and most importantly, things are improving. You don't have to like those improvements, but they are. The people that make GNU/Linux distributions, especially Debian, are super-serious about it. They would not have used systemd if it threatened the system's existence.
Things are changing and most importantly, things are improving
Things in the Linux scene are changing, and yes, there are things that have had tremendous improvement, __despite__ the wrath of systemd
Why you start up so fast? Very nicely done!
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.
You mean untested, unaudited code that is forced into production environments? Code that has full network access as root?
We went through this song and dance in the 1990s with sendmail that had multiple security holes in it, be it remote root or local priv escalation. The stakes are quite high these days... are the distro maintainers confident that they are doing their best to provide security for their customers?
I'd question that. No systemd based distro has been certified with EAL, FIPS, or Common Criteria yet.
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.
You mean untested, unaudited code that is forced into production environments?
Untested, unaudited and forced into production? 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. This is hardly something brand new that just came from nowhere.
"...but only 394 votes ultimately decided Pluto's fate: 237 in favor of demoting the planet and 157 against."
1 vote decided for the systemd takeover in debian.
There was a split 4-4 vote in the debian technical comittie.
Which was then tie-broken by the chair who just happened to be a rabid force-it-down-your-throght supporter.
Then there was a GR with 1 pro-systemd option and 3 or 4 anti-systemd options, so all the anti-systemd votes got split and diluted (together they would have defeated the systemders 60 to 40)
Fuck these people. SJW pieces of shit.
(Same type people banned marrying young girls everywhere, also look at planet.debian.org during the systemd debate: transgender this, women that, bla bla bla. fucking pieces of shit ruin everything good)
---
The "bug" (RFP) has been tagged as "won't fix"
If you aren't a progressive, the debian people
do not want your software, they state this here
in more concise words:
https://bugs.debian.org/cgi-bi...
Opensource isn't about code anymore, it's
about community and beliving and professing
the correct thing. If you do not believe
the correct thing you are removed (example: Ted Walther)
or your software is attacked and removed from its
host (As gpcslots2 was in the past by feminists:
http://esr.ibiblio.org/?p=1310 )
How do you feel about this change?
Anything special to note here or is it safe to just run dist-upgrade from 7 and try if it boots?
There are no atheists when recovering from tape backup.
Code that has full network access as root?
On one of my non-systemd systemd:
ps -ef | grep inetd /usr/sbin/xinetd -dontfork -pidfile /var/run/xinetd.pid -stayalive
root 1482 1 0 Apr19 ? 00:00:18
You mean like that one?
get with it, run a manly operating system ya big Jessie.
https://wiki.debian.org/systemd#Installing_without_systemd
You mean untested, unaudited code that is forced into production environments? Code that has full network access as root?
So, what systemd things have access to the network?
Not running as root, running as user "systemd-timesyncd"
Watch this Heartland Institute video
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"?
So, what systemd things have access to the network?
PID 1
http://0pointer.de/blog/projec...
"Oh, you can't because you haven't got the brains or balls to do anything other than sit in the corner whining."
And fork Xonotic
(And before that, Crossfire RPG)
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.
>So set up a distro maintained by straight white males, for straight white males.
All of them before the SJW invasion.
Seriously. There are a small number of people whose opinion is worth listening to even when it disagrees with the groups managing almost every single major distribution of Linux. Granted, some of them will be on slashdot. But definitely not anywhere near the number that pop in to these threads and whine. I use Linux to get things done. I have also used FreeBSD quite extensively, but there are a number of applications that don't quite support FreeBSD, and there is no equivalent of Red Hat. I plan to deploy Ceph soon for example for a storage cluster, and I want to be solving issues related to making Ceph work effectively, not spend time getting it up and running, compiling things myself. So I'll go with a *nix distribution that Ceph is most extensively tested against (RedHat or Ubuntu when I last checked).
If you want to build Debian without systemd and deal with all the niggly annoying issues that will come out of that and get progressively worse, go for it. Just don't pretend it's a viable option for anyone trying to get shit done, trying to keep systems running, trying to get systems up and going in short time. Sure, if you have an abiding interest in operating systems, love compiling kernels and creating custom builds of your favourite distribution, go for it. But the idea that any organization using Linux for critical systems would consider rolling their own distro to avoid systemd is ridiculous. Systemd won. Get over it. Discussions about how it is better or worse are mostly academic at this point. We are approaching almost a year since RHEL switched - if it was that catastrophically bad, we would know by now.
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.
here we go...
Guess it's time to change my email address...
The base of everything that will effect the number one operating system on portables (Android) and possibly "internet of things" has been upgraded after 24 months of work by individuals and Fortune 500 and all we will discuss is systemd.
If they weren't involved, it is like winning lottery for Microsoft and they didn't even purchase a ticket.
as in only systemd? did you read the the link?
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
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."
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.
Thanks, Poettering. :(
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.
You're correct and my memory was wrong. Fedora 15 came out in 2011 so it's only four years in production.
Anyway, you can't say that it's not tested.
I'd question that. No systemd based distro has been certified with EAL, FIPS, or Common Criteria yet.
What does that have to do with security? All of the certifications you've mentioned are an evaluation of how desperate a vendor is to bid on government contracts, not of the security of a system.
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
Debian 8 has libjpeg-turbo, replacing libjpeg8 and matching most other distributions.
About time. For some time now, the IJG has practically been run by some kook who insists he's the only one who understands the "fundaments of DCT image compression" and furiously trolls any attempt to prove otherwise. The latest versions of libjpeg feature various compatiblity-breaking "improvements" that actually make the compression worse both subjectively and objectively.
Good-bye Debian. It's been fun, but you've changed, and not for the better.
Ignorance and prejudice and fear
Walk hand in hand
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.
It's pretty naive of you to think that systemd is written perfectly, and without bugs. No software is like that. All it takes is one small buffer overflow, and something like systemd running with extreme privilege could very quickly become extraordinarily dangerous. Maybe it doesn't do some particular action now, but exploit a flaw in it to run custom code, and all of a sudden it's doing things you ever expected it to.
Many Social Justice Warriors are straight white males. They're working on distros for straight white males.
Social Justice is a mental disability that can affect anyone of any sexual orientation, of any skin color, and of any gender.
So what should we use instead? xinetd? It's not like this type of functionality has not been around for some time.
"It's pretty naive of you to think that systemd is written perfectly, and without bugs. No software is like that." - who said it was, even software thats been running for years can turn bad. the AC inferred that systemd "things" all run in PID1 which is complete crap. All other "things" in the systemd project (as opposed to the systemd daemon) are configurable as to whether they are used or not.
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
They would not have used systemd if it threatened the system's existence.
Sure. Let's assume that because it's the emperor, he must be wearing the finest of clothes.
As comrade Reagan used to say: Trust but verify
Will Btrfs work well on this version? It says that the kernel is 3.16.7, and the newest kernel is 4 versions ahead, and the Btrfs wiki claims that it's best to use the newest kernel possible.
Oh you just discovered he runs the servers for the HR department?
Fedora, in production?!?! LOL, just stop, it hurts.
Well, many systemd proponents will lie shamelessly about its characteristics. That is one reason why I have long since concluded that there is a massive PsyOps campaign behind getting it established. That also means that the NSA has its fingers deep in there, possibly without Poettering realizing. (And arrogant and incompetent lead developer is the perfect way to get lots and lots of bugs in there that will make the TAOs job much easier breaking into Linux in the future.)
History is full of inferior (and often grossly so) technological solutions being successful, just because they were pushed hard enough. The customer is stupid, and unfortunately that seems to be true for most of the Linux users as well.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
If you extend the concept of SJWs just a bit, you can fit movements like National Socialism right in there. They most definitely started out as SJWs.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
How are going to verify in the future that it is still not reading from them? In complex C-code?
The only legitimate reason to have sockets open is if you _are_ reading from them. Anything else is either gross incompetence or preparation to read from them at a later time, possibly clandestinely.
But thanks for giving me yet another reason to stay away from that Trojan Horse.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
It reveals the weakness of the Linux "community" as more and more contributions are paid and done for profit, and the rest don't have the resources to go another way. I don't have a problem with that, but I think there are going to be more controversies like this in the future.
Nothing wrong with using Fedora in production. It depends on what you want. If you want stable and boring the no, don't use Fedora. But if you want to use the latest technology and is OK with rolling forward every 6-12 months then Fedora is actually a great OS to run in production. There's a reason why "software collections" is a big feature in RHEL, and that is that it's more and more common that you actually need newer versions than what's in your "enterprise" distribution. And if that's the case then using a newer distribution could actually be the right solution. There are of course reasons why you wouldn't use Fedora. If you want a support contract or require certain certifications then use RHEL or something else.
Already a little bit older, but still completely relevant:
- There are no technical merits of systemd that are important or critical, just some convenience issues
- Systemd is in hurried development, a stable feature set is nowhere in sight
- The development leads are known incompetents with inflated egos and no communication skills
- There are a number of design decisions that are very, very bad for security and stability
At the same time I see:
- Systemd is pushed strongly with emotional (not factual) arguments
-> This is a coordinated and targeted propaganda campaign. A campaign focused on technical merits is not even attempted seriously.
- Systemd opponents are ridiculed, insulted and their arguments are not taken seriously, very much SJW-style
- Systemd is getting very hard to avoid
I can only deduce that there _must_ be one of or a combination of the following going on:
- Linux was getting too hard to hack and the intelligence community is pushing for systemd to fix that
- Linux did not generate enough support revenue for Red Hat and this is intended to fix that
- Red Hat wants total control over Linux and systemd is their attempt to establish that
So if it walks like a duck, quacks like a duck, the most probable explanation is that it
is a duck and hence I conclude that something nefarious is going on and the last three
items are the most likely candidates IMO. I cannot believe that two known incompetent
hacks with bad personalities can screw over a whole large tech-savvy community all by
themselves. They must have significant, coordinated help, with significant propaganda
and manipulation experience. Whether it is military PsyOps or just commercial PR, the
effects are the same. And they are massively negative and destructive for Linux and
its community if not repelled decisively.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
You obviously aren't aware of inetd or xinetd, although you probably have them running, started by your precious sysvinit.
(x)inetd does not control what it attaches, the user does and via plain-text files that are in easy to find standard locations. And no, I do not use them. The whole idea struck me as pretty problematic wayyyy back.
Another characteristic of the systemd-cretins: They think they know everything, and all others are clueless. They also think that anybody that does not like systemd has no clue about UNIX system administration. The actual reality is very different.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
As I understand it, sysd startup time is faster when you a lot of applications to start at boot time. Because sysd starts the apps in parallel, it goes faster.
But, if you are running a standard desktop. sysd is probably slower.
My understand was: Devuan was supposed to come out at the same time as Debian 8.
I would be interested to know if anybody has tried Devuan, and what was the experience like?
I wonder if they'll update to Xfce 4.12 sometime in the future but am not holding my breath.
So set up a distro maintained by straight white males, for straight white males.
Done!.
Despite a CompSci degree and over 15 years of using nearly every breed of Linux at work and home, I feel like a guy who just wants the car to go listening to automotive engineers get angry over a debate on number of cylinders.
I upgrade only when forced to, these days: Linux met all my needs years ago. I was just compelled to upgrade from a long-obsolete Mint to 17.1, which I gather will be around for years before all support stops.
Is there any hope of this particular Good Thing vs Bad Thing debate being settled by, say, 2017?
That's all most of us want to know.
Proof's in the pudding, guys. My hat is off to everybody who tries out the new distro and takes the proverbial arrows in the back so the rest of us can know about a year or so from now if all the dark predictions about "systemd" come true or not.
You obviously aren't aware of inetd or xinetd, although you probably have them running, started by your precious sysvinit.
First, most modern Linux systems come without an inetd or xinetd, because they have no services which aren't supplied by long-running daemons. Second, inetd won't listen on things it doesn't need to listen on, let alone xinetd.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
History is full of inferior (and often grossly so) technological solutions being successful, just because they were pushed hard enough.
Notably, Unix.
Watch this Heartland Institute video
So no slackware users are female, homosexual, black or trans.
How do you know?
Watch this Heartland Institute video
(x)inetd does not control what it attaches, the user does and via plain-text files that are in easy to find standard locations.
Uh, just like systemd?
Watch this Heartland Institute video
First, most modern Linux systems come without an inetd or xinetd, because they have no services which aren't supplied by long-running daemons.
Please name a modern Linux system that comes without [x]inetd.
Second, inetd won't listen on things it doesn't need to listen on, let alone xinetd.
Neither will systemd. As I said above on my system with no xxx.socket units systemd is not listening on any socket.
Watch this Heartland Institute video
Where did you miss the statement that even in this simple, non-complex fashion (i.e. not like systemd at all) I think this is a bad idea?
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Only somebody truly clueless about the history of computing could make such a statement. Also, relevance?
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Those who do not know multics are condemmed to reinmplement it, badly.
Watch this Heartland Institute video
It is pretty close to 4 years since the Fedora 15 was released with systemd:
LibreOffice was 3.3.2 (4.4 now)
Apache was 2.2 (now 2.4)
Kernel was 2.6.38 (4.0 now).
It is absurd to suggest that systemd isn't proven and tested in the wild for a long period.
Also note that some systemd code like udev, existed even before the systemd project was announced, so at least part of the systemd code is much older than 5 years (udev was released in 2003).
Perhaps it will kill your glorified memories of how GNU/Linux used to work. Things are changing and most importantly, things are improving. You don't have to like those improvements, but they are. The people that make GNU/Linux distributions, especially Debian, are super-serious about it. They would not have used systemd if it threatened the system's existence.
Linux is dead. Someone said udev would kill it, and they were right. Oh wait...
http://etbe.coker.com.au/2015/...
For some reason the men in the Linux community who hate women the most seem to have taken a dislike to systemd. I understand that being âoeconservativeâ might mean not wanting changes to software as well as not wanting changes to inequality in society but even so this surprised me. My last blog post about systemd has probably set a personal record for the amount of misogynistic and homophobic abuse I received in the comments. More gender and sexuality related abuse than I usually receive when posting about the issues of gender and sexuality in the context of the FOSS community! For the record this doesnâ(TM)t bother me, when I get such abuse Iâ(TM)m just going to write more about the topic in question.
While the issue of which init system to use by default in Debian was being discussed we had a lot of hostility from unimportant people who for some reason thought that they might get their way by being abusive and threatening people. As expected that didnâ(TM)t give the result they desired, but it did result in a small trend towards people who are less concerned about the reactions of users taking on development work related to init systems.
The next thing that they did was to announce a âoeforkâ of Debian. Forking software means maintaining a separate version due to a serious disagreement about how it should be maintained. Doing that requires a significant amount of work in compiling all the source code and testing the results. The sensible option would be to just maintain a separate repository of modified packages as has been done many times before. One of the most well known repositories was the Debian Multimedia repository, it was controversial due to flouting legal issues (the developer produced code that was legal where they lived) and due to confusion among users. But it demonstrated that you can make a repository containing many modified packages. In my work on SE Linux Iâ(TM)ve always had a repository of packages containing changes that havenâ(TM)t been accepted into Debian, which included changes to SysVInit in about 2001.
The latest news on the fork-Debian front seems to be the call for donations [4]. Apparently most of the money that was spent went to accounting fees and buying a laptop for a developer. The amount of money involved is fairly small, Forbes has an article about how awful people can use âoecontroversyâ to get crowd-funding windfalls [5].
MikeeUSA is an evil person who hates systemd [6]. This isnâ(TM)t any sort of evidence that systemd is great (Iâ(TM)m sure that evil people make reasonable choices about software on occasion). But it is a significant factor in support for non-systemd variants of Debian (and other Linux distributions). Decent people donâ(TM)t want to be associated with people like MikeeUSA, the fact that the anti-systemd people seem happy to associate with him isnâ(TM)t going to help their cause.
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.
Please name a modern Linux system that comes without [x]inetd.
Ummm. The DEBIAN JESSIE install that I just did yesterday (small mail server) included no [x]inetd.
I didn't ask for it and Debian didn't include it by default.
Just getting used to 'systemd' too..
Mike
-- Mike Greaves
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.
Yep, along with all the other problem the outdated init system presents that we have spent years and years patching and adding helper programs to work around.
GP is reading from his own CV. He also has 3 years experience in doing the needful with Java 9.
And you don't? How do you ever have a hope of finding a job in IT? Next you're going to tell me you don't have 3 years experience as a Windows 10 admin. Maybe this industry just isn't for you.
But it's not causing systems to go unstable and crash all the time.
Not ALL the time, no. But I expect systems to NEVER crash, rarely crashing is not good enough. Systemd's PID 1 crashed on me when a script left a dead symlink and I tried to restart the daemon owning that symlink. Nothing like that EVER happened to me with sysvinit and starpar.
Yes I am aware that particular bug was fixed. But what this tells me is that the design of systemd makes it possible for trivial bugs to crash PID 1. What's next? A PID 1 crash triggered by a problem with a socket, mount point, or device file?
Maybe it doesn't need to be hacked. Perhaps causing a denial of service by triggering a bug that causes PID 1 to crash is enough to accomplish the attacker's goal.
If someone attacks systemd systems till it is secure enough or till no one likes to use it and return to sysvinit...
R.I.P. Debian, you have been a faithful friend for many many years. And there's dark forebodings for the whole of Linux, too. As an environment where I could always agree with the important choices that were taken, I mean.
Debian and RedHat were born roughly at the same time. I remember how sad I was to see a split in the Linux world, but a good option was available to me: I could let the jacket-and-tie folks go the way of RedHat, and keep navigating on the interesting seas that Debian was heading towards.
Now, no more. The Debian spirit is all but extinguished,and we are bound to have two RedHats for the price of one.
Pity. Occasion lost.
Now, what will I do with my beloved Debian tee shirt?!?
It is absurd to suggest that systemd isn't proven and tested in the wild for a long period.
I made no claim about its maturity in my comment, though I'd say that in Debian's case it's much less tested than its successor and perhaps it would have been wise to present it as an installation option to make fallback easier in case systemd's init is troublesome. Btfs has been in development since 2007 and still hasn't supplanted ext4 due to niche problems, but Debian felt it was appropriate to push systemd as default. I say this only because Debian has generally been very conservative when making massive changes like this in the past, so it's uncharacteristic to change something as important as the init more recklessly than, say, switching from KDE3 to KDE4.
All I was doing with my comment was pointing out that the other AC was exaggerating to make systemd sound more mature and better-tested than it really is. It looked like an attempt to suggest systemd has been in development as long as upstart, which is untrue.
Also note that some systemd code like udev, existed even before the systemd project was announced, so at least part of the systemd code is much older than 5 years (udev was released in 2003).
I had a feeling someone would try this argument. Udev is older than the systemd project (and init), and has been included by default in distros for a long time now. Trying to insinuate, as you are, that this means systemd is that old is disingenuous. Especially in a discussion that's clearly focusing on the systemd init. The summary mentions the init part and boot times, the original comment in this thread was "systemd v initd", etc.
Nobody here was talking about udev, so trying to use it to insinuate systemd-init has been around longer than 2010 is deliberately misleading.
He checked both of them to make sure...
I had a home server on Wheezy (or, should I say, "stable". Wow, not gonna make that mistake again). I did a dist-upgrade before I'd read the release announcement and spent five minutes wondering why my home page no longer came up.
"What do you mean, 'Please upgrade your kernel before or while upgrading udev'? What do you mean, 'can't install linux-image-amd64', udev is broken'?" What the hell happened to my beautiful Wheezy -
- oh, crap, what do you mean, Jessie with systemd is the new stable ALREADY.
I also tried Pikoro's instructions above twice in a VM at work; *twice*, got the installer failing on me at the "Installing Software" step. And no hint as to what went wrong. So screw it, I thought. I'll install off the live image with all the defaults including that f'ed up systemd, rather than off the xfce-image.
"Oh, look. Broken a third time at the 'Installing Software' step. Using no online repositories (behind a work firewall with a corporate authenticator I can't use in the install environment) with the default first DVD image. And it still broke in the 'Installing Software' step." ... so, my hat off and some deep respect to Pikoro and those who got Jessie to install without the systemdevil, let alone *with the ordinary defaults*. I'm just glad I got an archived copy of 7.8.0, because:
- an on-the-metal upgrade FAILED to upgrade and has forced every service offline
- two VM installs with the xfce-cd, trying to keep systemd out failed
- a third VM install with the first full DVD, trying to keep out systemd failed
- and a fourth VM install, with the live disk image and accepting all the defaults failed.
Damn you RedHat, damn you everyone who brought systemd to light.
And damn you Debian, for going along with this - and pushing me the biggest Debian lie I've ever seen - "upgraded painlessly without forced downtime".
Call my evidence anecdotal, call it a data point in a shifting window. I call it the next day I can spare re-installing Debian 7.8.0, excluding every Jessie/Stable repository and repartitioning a 20W machine I set up over four years ago so that these upgrade stuff-ups will never necessitate me restoring from backup again.
Thanks for Wheezy, Debian. I hope against, but do believe that's going to be the last time I thank the Debian project again and hope like crazy Devuan does a good fork.
All other "things" in the systemd project (as opposed to the systemd daemon) are configurable as to whether they are used or not.
Indeed. Could you please point me to the section in the documentation on how to configure not to use journald?
(x)inetd does not control what it attaches, the user does and via plain-text files that are in easy to find standard locations.
# systemctl status rsyncd.socket
rsyncd.socket - Rsync Server Socket
Loaded: loaded (/usr/lib/systemd/system/rsyncd.socket; disabled)
Active: inactive (dead)
Listen: [::]:873 (Stream)
Accepted: 0; Connected: 0
# cat
[Unit]
Description=Rsync Server Socket
Conflicts=rsyncd.service
[Socket]
ListenStream=873
Accept=yes
[Install]
WantedBy=sockets.target
What is this, a non-text file? How is systemd controlling this, any more than xinetd was?
First, most modern Linux systems come without an inetd or xinetd, because they have no services which aren't supplied by long-running daemons.
Every modern Unix-like system has inetd or xinetd available, many install one of them by default.
The service we require xinetd for on every production server is: Netbackup's bpcd.
Second, inetd won't listen on things it doesn't need to listen on, let alone xinetd.
# readlink -f $(which init)
# netstat -plant|grep systemd
#
How is systemd any different?
Ummm. The DEBIAN JESSIE install that I just did yesterday (small mail server) included no [x]inetd.
I didn't ask for it and Debian didn't include it by default.
Just getting used to 'systemd' too..
It didn't install xinetd systemd is the default :-p
# apt-cache search xinetd
?
If you don't need the feature, it doesn't listen on any socket.
The default installation on most distros will probably not use socket activation, but some systems will *require* socket activation, just like in the past they required inetd or xinetd.
Last time I tried Fedora (11 or 12) It broke constantly. Although much of it was possibly due to KDE4 going through its "infant years".
Wait, you're telling me systemd is stable? Like, debian-stable level (or should I say debian-level stable)?
A super important core system software that had its initial release 5 years ago?
Is Debian still Debian?
The only "benefit" I've seen from a live systemd deployment is nondeterministic slow-down of boot time by 0 - 200 seconds. (Yep: 3 minutes 20 seconds.) This is on a HTPC running OpenELEC 4.x. Boot times were seconds. Now, about half the time, there's an extra minute or so of getting to stare at a text mode service starting screen informing that a job for X failed. Stare. Stare. Stare. Oh, look, it finally booted anyway.
So, I really don't get where all this "it boots faster under systemd" crap is coming from. I'm seeing unpredictable slowdowns of up to a factor of 10. (Yeah, reliable 20 second boots were the norm under OpenELEC 3.x for my setup.)
We have fedora 8 on a number of 24/7 production servers that's been running like 7 years or so.
No problems that caused me problems for maintenence or eventually converting to VM, but all the ubuntu's have been a pain with bugs that never got resolved and only mitigated in later ubuntu's. My impression is Ubuntu is fragile and broken where our fedora boxes are rock solid.
I will say, though, the fedora boxes were installed by experienced, competent developers whereas the Ubuntu boxes by IT.
Read it again, you missed the "some" and "part" words that makes you look like you can't read or intentionally ignoring his point.
You use words and talk about things you don't even understand, you make gross generalizations and I'm sure you think that makes an argument.
First, a customer is everything but stupid, surely you meant a consumer.
You make fallacious sentences like "many systemd proponents will lie shamelessly about its characteristics". This sentence is a subject of study in itself, given that its meaning changes depending on who reads it. It contains no evidence, is based on nothing but your perception of reality.
Then comes the scare tactic with this gem : "That also means that the NSA has its fingers deep in there, possibly without Poettering realizing".
It seems to me you don't have even the start of a clue of computer science and how it works. It also seems to me that you keep the NSA as the utmost authority in security.
Did you know that (you won't understand one thing of what I'm going to say but whatever) the NSA was beaten by their own weak cryptographic algorithm policy (low key length) that they imposed on foreign countries?
The NSA is not the supra smart entity you think it is.
Anecdotes 1 + 2 were running in native mode because it was initially a fresh install that was then switched sysvinit-core. Anecdote 3 I don't know (most likely compatability mode as it was several years ago). Even if all the anecdotes were only running in compatibility mode the results show systemd finishing quicker...
Does the above make things any better and how fast do you expect things to go when you're bottlenecked on I/O throughput? Is 15 seconds for a hard disk or 4(!) seconds for a RAM disk so bad?