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.
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
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
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
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.
"...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.
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"?
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.
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."
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 can't choose any of those through the installation GUI. All of them require a custom pre-seeded install or post-install action.
If you upgrade an x86 system, both systemd and sysvinit will be installed and you can select sysvinit from the GRUB menu.
repeating crap troll bait won't make it true
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
Why you start up so fast? Very nicely done!
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.
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.
There were already emerging chains on Jessie last year where packages needed a recompile or work to run without systemd effectively That's not to say that every system had such chains but that they were starting to emerge and complicate work. The systemd advocates never said Jessie wouldn't work without systemd but rather that:
a) Jessie was likely the last version that would work while being a broad based distribution without systemd
b) They couldn't insure that upstream packages would continue to support initd based features for 2-3 years so not using it would introduce security issues
c) Given the speed of systemd development and its ties with architecture the changeover was likely to be vastly more breaking 3 years later (i.e. 2015 is going to be much easier than 2018).
As for choice and flexibility... Debian is a compiled distribution Most packages don't introduce complex chains of dependencies but some do. And on those Debian has had to make choices about defaults. The way those choices are made is by looking at the direction of upstream. Debian's policy is pretty clear. If the initd people want initd then work with the upstream software to make sure their software is not introducing systemd dependencies and work with the package maintainers or easy option switches. Debian supports that. What they can't support is 2 different distribution. If Devuan ever comes to be then you'll have a long term systemd free Debian. If not Crux, Alpine... exist . No one is taking away choice from Linux.
People here have posted good reproduction steps here several times. Also, I've seen them posted to reddit. Every time the systemd fanbois attack the poster rather than the problem. Returning a zero exit status for a service that fails to start is a serious problem. Swallowing stderr is an even more serious problem. That makes it very difficult to troubleshoot problems. I've wasted days with Red Hat 7 trying to troubleshoot SELinux-related problems. I had to resort to using strace to see the actual error messages. With Sys V init scripts, they print stderr directly to the console, rather than silently deleting messages, so that made it much easier to find the cause of problems in Red Hat 6 before the switch to systemd.
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
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.
Your reasoning would sound more fair if *sysv* was the newcomer. It is like exactly 20 years of core and experience disappeared overnight and was necessary to redo all over again. And I still do not understand why you do have to upgrade server from sysv to systemd when there are no dependencies on sight without a single courtesy warning in the installation scripts, and *ignore* the sysv packages installed, not even upgrading them to debian 8.
Why not posting with a true user?
correction "it is not exactly"
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
For me startup is very quick with systemd, it's the shutdown that's slow. About three minutes to shutdown.
those 2 "problems" you listed have been thoroughly debunked thats why they are crap troll bait
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
stderr is logged in the journal so it can been viewed as many times as you like via the journalctl program - so how is that a problem? try reading up on so called problems before taking spurious claims as fact
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
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, on my computer it shortened startup time by about 10% (not much), the shutdown time however is another matter. if i forget to unmount nfs, it pauses for 2 minutes showing countdown and then continues shutdown. i've had many wtf moments with systemd.
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.
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.
So much in a hurry? Clearly they are hiding something.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
THREE MINUTES? WTF? Does it have to send all your recorded keystrokes to the NSA first or what?
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
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!.
It is also the one init that goes into crisis mode if that usb devices you have a entry for in fstab is not present on boot.
A short hint Poettering, when it comes to unix boot, / is paramount, everything else is "best effort". Because once / is up, the sysadmin has the resources to get anything else sorted and mounted.
Oh wait, systemd is part of the effort to push everything into /usr...
If you want to make PoetteringOS go do so, and stop shitting all over long established, and time tested, behavior!
comment first, facts later. http://chem.tufts.edu/AnswersInScience/RelativityofWrong.htm
Likely he has a network mount going, and because systemd can't tell NFS from EXT it yanks down the network before unmounting, as networking is earlier in the dependency graph.
So it will sit there and wait for the network mount to time out before moving on.
I guess having a network mount service alongside a mount service get systemd panties in a twist. Or perhaps Poettering only use dropbox...
comment first, facts later. http://chem.tufts.edu/AnswersInScience/RelativityofWrong.htm
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.
Plausible. Also a strong indication of inexperience and incompetence on the side of the systemd team. Of course we already knew that. It is not like they could have looked at what was already there and find solutions that work, like mounting/umounting NFS at a different time....
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
What do you mean by fair? From from the perspective of Jessie or fair from perspective of some broader Linux community? if you mean the formers: Debian can't control what upstream software producers do. If in 2016 an upstream package has no interest in fixing a security hole that only impacts sysv what are they going to do about it? They would then have to have a security update that could break init scripts.
As for how to handle upgrades on existing servers that have complex code I really don't have much of an opinion. Certainly systemd breaks stuff on existing servers as far as init scripts which is one of the reasons I think changing the default was important to do early before the forking between systemd-linux and sysv-linux got large enough that automated updating became unworkable. I assume basically that Debian wants updates to Jessie to be a lot like new installs and not have to support two systems in the field. So that end users understand version upgrades can break stuff, while minor updates don't. Knowing you are updating from 7 to 8 is the warning that breaking change could occur. And then they are moving them over to the new update.
As for 20 years disappearing overnight. Sort-of yes. The direction systemd is going towards is uniform process management like you see on mainframes and minis and away from the workstation process management that Unix uses. I think that's the right thing to do, but I'm not going to deny that in many ways the people who are supporting the systemd / IaaS / PaaS stacks are trying to put back into Unix the stuff that Ritchie, Thompson... were taking out.
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.'"
When the issue was raised to them enough for Poettering to take notice, their "solution" was a default timeout on every service for both bootup and shotdown.
This then blew up the following Fedora alpha, because they had a service that ran on first reboot after a system update that ended up taking long enough to tripped said timeout...
Their overall development methodology seem more at home with a website than a central OS component.
comment first, facts later. http://chem.tufts.edu/AnswersInScience/RelativityofWrong.htm
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.
Indeed. And if all the other places they screw up where not enough, this combination of incompetence and arrogance when working on _infrastructure_ would be quite enough to never allow their trash on any of my systems.
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.
Debian is all about choice, that's why it is opensource and you can fork it if you don't like their design choices. Many successful distros started as a fork of Debian, including Ubuntu, so I don't see why the same can't happen for sysv init lovers.
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...
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.
Debian also got out of its way and is updating all servers to systemd without our asking
There's a simple reason for this: Debian is not a democracy. I don't know where people get these silly ideas. It's a project run by a few core maintainers who make all the decisions. Linux on the whole is about choice, choice of which distribution you run, and choice of how to configure that distribution within its provided parameters.
The only thing new here is that suddenly its a parameter you actually care about. Nothing else has changed in the way systems are run.
Don't like it? Why not support one of the forks?
This seems to be a common problem with changing from another init to systemd.
Basically, you have to mark your non-essential, auto mount on bootup, fstab entries with the option "nofail". It does make sense, as you can have essential parts of your system mounted on other partitions.
I would hope that this issue is handled by the upgrade process to systemd. Inform the person doing the upgrade to add the option, or automatically add the option to the fstab file for non root partitions.
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?!?
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?
For me startup is very quick with systemd, it's the shutdown that's slow. About three minutes to shutdown.
Mine is actually slower but not by a huge amount, somewhere between 5 and 10%, varying from one boot to the next. The shutdown is either quite a bit faster, enough so that I worry whether things are being shut down correctly, or a whole lot slower, with no rhyme or reason as to why or which one I'll get on any particular shutdown. Systemd's "improved" logging system is, of course, no use in figuring it out.
Yeah, nofail. Thats up there with their abuse of debug in the kernel command line.
nofail is simply about supressing the error message on a failed mount, nothing more, nothing less.
Have the whole system go into panic mode because of a vestigial USB mount is missing is not sane by a long shot.
comment first, facts later. http://chem.tufts.edu/AnswersInScience/RelativityofWrong.htm
I agree that they abused "debug" in the kernel command line. Though that's a whole other can of worms, and you could argue that the term "debug" is generic, and should apply to all systems, not just the kernel. Using "kernel.debug" and "systemd.debug" would be more specific ways of flagging what system should enable debug messages on boot, and would be specific enough to avoid all the confusion that lay at the root of this problem.
The use of "nofail" here does fulfil a purpose though, even if it does cause some people headaches when changing init systems. But, like I said, this should probably be handled by the upgrade process, not by systemd itself.
If you don't want systemd to panic about a failed USB automatic mount on startup, then you have a number of options.
* Specify "noauto" in fstab
* Specify "nofail" in fstab
* Install an automount system, and delete the entry from fstab.
* Use the systemd automount feature, and delete the entry from fstab
Look, systemd is different. It's not a complete drop-in replacement for sysv init, though it can work as such 99% of the time. Accept that it can be different, and work from there. Moaning about it just makes you sound like an overprotective old man with his lawn.
(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?
This is worse than Debian deciding it is much work supporting people running Apache and upgrading all the servers to Nginx wihout our asking because it is "better". I do not see why you dont bugger off too.
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.
Plausible. Also a strong indication of inexperience and incompetence on the side of the systemd team. Of course we already knew that. It is not like they could have looked at what was already there and find solutions that work, like mounting/umounting NFS at a different time....
Actually, it's a strong indication of inexperience and incompetence on the side of the "sysadmin" who experience this issue.
I have several servers and desktops with NFS mounts and systemd, and they all start and stop extremely fast.
Some desktops have the home mounted as NFS, and they shutdown in less than 2 seconds, which always amazes me.
Perhaps the difference is that all my NFS mounts are defined as systemd units, and they are all using the "on demand" feature of systemd, which equals automount. Automount was how I was handling my NFS mounts before systemd, so as not to break my systems in case of network issues, which would mean a reboot.
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?