Slashdot Mirror
Linux Mint Will Continue To Provide Both Systemd and Upstart
jones_supa writes: After Debian adopted systemd, many other Linux distributions based on that operating system made the switch as well. Ubuntu has already rolled out systemd in 15.04, but Linux Mint is providing dual options for users. The Ubuntu transition was surprisingly painless, and no one really put up a fight, but the Linux Mint team chose the middle ground. The Mint developers consider that the project needs to still wait for systemd to become more stable and mature, before it will be the default and only option.
it's in trying to resolve problems later on, when you'll find that systemd helps you obscure the source of the trouble instead of resolve it.
Linux is merely the kernel used by systemd. The correct name of the operating system is systemd/GNU/Linux.
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
The reason that "nobody put up a fight" is because every intelligent Linux user has seen systemd for the disaster that it is, and they've moved to FreeBSD, PC-BSD, OpenBSD, NetBSD or DragonFly BSD months ago. The only Linux users left are the ones who'd be just as happy using Windows, which is pretty much what they get when using a modern GNU/Systemd/Linux distro.
One more reason to use Mint.
That's the best they could do out of this situation.
Not quite - more likely 2015 will be year of FreeBSD on the server instead.
No. Systemd will integrate the GNU environment completely. Soon.
aaaaaaa
What needs to happen first is for major software vendors to begin supporting it. That's when you'll see enterprises at least begin to consider it.
-- "Government is the great fiction through which everybody endeavors to live at the expense of everybody else."
I've been learning more about systemd lately, and I'm liking what I'm seeing. It's cohesive, yet it's completely modular. It's modern. Its binary log files make debugging easier. It's getting more and more critical functionality every day, and this makes my Linux system easier to use each time I update it.
The deeper I dig into systemd, and the more I use it, the more I question why we even need the GNU utilities and the Linux kernel.
I hope to see the most useful parts of the GNU toolchain and the most useful parts of the Linux kernel folded into systemd eventually. This way I don't have to install a Linux distro. I can just install systemd itself, and it will give me everything I need.
If my computer boots directly to systemd, and systemd provides the command line tools and the UI, then my boot time will be shaved down to almost nothing, and I'll get to use some really nice and modular command line tools. I won't have to try to remember awkward shell, sed, grep, and awk commands and their flags, because if systemd provided alternatives, I know they would be easier to use.
I've found that systemd is all about empowering me, as a user. It's about letting me get more done with less effort. GNU and Linux aren't always about that. They're about doing things for philosophical reasons, or for scratching an itch of their developers. Systemd is all about getting work done, which is why I've found it to be so useful. If it can do the things that the GNU toolchain and the Linux kernel are doing, but it can do them better, then I'd prefer just to use systemd directly.
To be fair, Linux has always been multiple components that you can chose which one suits you best - whether its vi or emacs, gnome or kde, sendmail or postfix, apache or nginx, etc
This is a good thing, where you can swap out component A for B for any reason, and keeps the project competing with each other to get better and better.
If only you could swap out Systemd so easily, things would be great.
15.04 was junk. It broke two machines, destroyed settings and I could NOT load the software that was needed even from scratch. The software required UPSTART API, that systemd (d for dumb?) did not provide.
Systemd is failure on consumer support and community support. The forced broken transition was a mess. Now, what will happen 16.04 LTS.do to the installed based for server class machines where software patches follow proven methods... Will systemd hose them too??
YEAH I will be modded down for talking bad about systemd. But the truth hurts.
Oh man, that's good news. Those people who were dragging their feet had me going up the wall. Init's had it's day, it fleeces me out with time consuming problems ...
The purpose of existence is to make money.
How long before they have to replace anything beyond the GNU stuff with something out of the 90s to avoid dragging in the systemd shoggoth via some dependency or other?
comment first, facts later. http://chem.tufts.edu/AnswersInScience/RelativityofWrong.htm
And you are just a troll trying to control the direction of conversation away off topic to some religious bullshit.
Actually, it seems quite the opposite. We have the systemd crowd claiming that it's simpler even when there is a whole new level of complexity in systemd they don't even know about (hint, look for the systemd craziness in /lib). Like the climate change deniers, they believe that since they haven't personally seen a problem in their simple and vanilla system that there isn't a problem at all.
Mint is a fairly popular and stable distro, so they've got a great opportunity to get some hard data on the whole systemd thing. Hopefully the choice of default and how the choice is presented to users is done in an even handed manner (maybe randomized like MS did with the EU browser selection ballot in Windows) and they are gathering some stats. Even though there's no chance of it ending the dispute, I'd be really curious to see the the answers to these:
How many users choose Upstart?
How many users choose systemd?
How many users choose Upstart when it's not the default option?
How many users choose systemd when it's not the default option?
How many more downloads does this release get than a typical release (potentially indicating people switching from other systemd-only distros), if any?
UNIX? They're not even circumcised! Savages!
systemd is an abomination.
Linux's benefit for a long time now has been the ability to swap functionality out you don't like for other functionality that you do. I don't know who in their right mind thought it was okay to move critical system infrastructure systems (init, time, logging, etc) into the hands of an untested piece of software which clearly has very deep issues, written mostly by a developer who has a track record of making extraordinarily poor choices in software development and writing poor code.
What's stunning to me is that smart people in leadership positions in a variety of distributions have decided to support such an asinine system. What's even more stunning is that Lennart didn't stop them, realizing his code was not appropriate in production environments and doing the responsible thing, which is to say "We're far from ready". systemd's position as PID 1 on Linux systems creates an enormous SPOF given the complexity of the code. The only sane position systemd developers can take is "we're not ready, please don't use this even as a test in your released distributions".
For all practical purposes, the rapid and unseemly adoption of systemd means that many enterprises running distributions that now rely upon systemd have to make the decision to not trust their distribution any more if they consider their systems mission critical. This is going to make people move to FreeBSD, Oracle, Windows, non-systemd distributions, microservice/microkernels, etc in rapid fashion. It is going to literally kill Linux for the people who have not yet figured out how to deal with the loss of machines (the majority of the enterprise world). And that may be a good thing, in the sense that Linux has in many ways become indistinguishable and directionless in the sea of operating system options. It tries to be far too many things to far too many people.
Lennart likes to whine about how much the community hates him and how much people take it out on him personally. Reality is that outside of a few people who take it much too far, the reason people don't like Lennart is because he makes poor decisions with poor forethought and his advocacy and arrogance for his own approach have a seriously negative effect on a great many people, enterprises, and efforts. He likes to think he is a genius and we simply don't understand his vision, but for a great many people, his vision is the antithesis of what we like about Linux and Unix. Systemd developers don't understand the arguments of simplicity, composability, and small programs that do one thing well.
The truth is the fault doesn't rely totally upon Lennart and his team: Some of the blame can also be assigned to Linus for poor stewardship, but Linus has a set of complex motives and organizations that influence him. Linus should have killed this stuff much earlier.
I think in a few years, we'll realize what a mistake we made in giving Mr. Poettering any chance of credibility in operating system software development.
I hope it comes sooner rather than later.
because some software expects it and doesn't run without it.
shit software, but software anyways.
that's whats bad about it, really. it's just not a startup replacement but one that aims to turn developers into developing software that can't work without it,, without trouble.
why would startup utility provide user authentication? to conquer everything of course.
world was created 5 seconds before this post as it is.
Thousands of Windows user trying to switch to Mint our stuck on the "Green Screen of Indecision", not having a clue to use systemd or not!
It's a fact that the fix for corrupt logs, which systemd will often corrupt if you power-cycle your system, is to delete them and throw them away. https://lwn.net/Articles/621453/ https://lists.fedoraproject.org/pipermail/devel/2013-July/185702.html It's a fact that systemd will only sometimes recover any part of its bullshit binary logs, and only any part after any error. So if journald truncates a file because it shits itself, which it has been known to do, then you lose the whole log.
Moderators, you might want to familiarize yourself with the festering pile of shit which is Lennart Poettering, as well as the pile of crap which is systemd, before you moderate any systemd discussions. Because you clearly have no idea what you're doing.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Sounds more like Microsoft got into the Linux world.
The cesspool just got a check and balance.
Seriously. Thank you for giving me a choice. If I want to try systemd and see if I run into issues with my particular use-cases, I can. If I want to avoid the possibility of conflicts and continue with the (admittedly crufty) sysvinit scripts I can.
Ignorance and prejudice and fear
Walk hand in hand
The summary (and the article it links to) have the situation backward. Ubuntu is the distribution which is offering users the coice of booting using Upstart or systemd. Under Ubuntu you can currently chose which init software to use (as of Ubuntu 15.04). Linux Mint does not do this, at least not yet.
Linux Mint has two primary branches, Linux Mint Main (which uses Upstart for init) and Linux Mint Debian Edition (which uses SysV Init). Which each branch you get just one init technology, you don'tget to choose which one you want. This is largely becaue Linux Mint Main is based on an older version of Ubuntu (Ubuntu 14.04) and was released before Ubuntu started offering two init systems.
The mint team is doing a right thing. I'm writing this from a CentOS 7 machine that I'm using to test systemd. One day, when the XFS partition was corrupted I realized that the system can't do usual self check and self repair. Why? Because systemd.fsck module runs fsck.xfs which according to the manual "simply exits with a zero exit status". You can boot with init=/bin/bash, but can't correct system scripts to change the behavior, everything is in binaries now.
Yes and no. Certainly what you say is generally true. But there have been some components that were sticky. For example GCC was sticky and distributions had to pick a fork. Certainly EGCS vs. GCC2 was sticky and you couldn't swap without changing components. In the early days KDE and Gnome apps didn't run or didn't run well in each other's environments. There wasn't an easy way to swap on an individual level. Picking your example of Emacs one of the classic choices: X-Emacs vs. Emacs were not easy swaps and generally you couldn't have both. TeX is famous for incompatibilities.
The reason Systemd won so decisively is the other projects for an advanced init replacement failed. Had OpenRC been earlier, had upstart not floundered we are looking at a situation much closer to Gnome vs. KDE. Today we have a situation much closer to what the world would have looked like if there had been no Gnome project: old fashioned window managers and you have one GUI, KDE. In such a situation almost all of the distributions would have been KDE distributions...
Short but actual useful advice. This should be modded up.
I don't think that's terribly useful information regarding users. The question has never been which do end users support, end users mostly don't care. Among those who do care, you have a lot of traditionalist system admin types and those are probably substantially biased in the anti-systemd direction. Systemd breaks stuff they care about. The benefits won't be seen till years later and mostly will be experienced by people other than them.
What's important is not that. But rather as upstream packages drop support what happens to Mint. Say in mid-2017 if Mint is still offering the option and non-systemd has substantial costs, how many choose it. That's the relevant number for the Debian systemd debate. What percentage of users are willing to write off huge numbers of applications in exchange for a more traditionalist process management system, as more packages become dependent on advanced process management?
Let me just point out, Oracle Linux 7 is systemd only. Oracle switched Jul 23, 2014. So yet another enterprise vendor that doesn't buy into the whole "systemd isn't mission critical ready" meme you all are pushing.
The better question is why bother supporting two sets of packages and scripts that accomplish precisely the same thing. Pick one and go with it. Given the support for systemd (by people who matter, not trolls), it seems the logical choice.
It's a good thing that they bother if they have the workforce, which they seem to have.
There's no problem with that, gentoo is doing the same thing.
As long as they are also going with systemd so that when the burden of initscripts is unbearable they're not stuck with an even bigger moutain to climb, it will go well. It will still be really painful for initscripts users though.
For now, the chasm isn't so big, it will really be huge when kdbus enters a Linux kernel release, even in experimental.
What's stunning to me is that smart people in leadership positions in a variety of distributions have decided to support such an asinine system.
You don't understand why because you don't understand the benefits that systemd provides.
It makes writing an init script quite a bit easier, and since the distro leaders spend a lot of time doing that, systemd made their lives easier.
"First they came for the slanderers and i said nothing."
because some software expects it and doesn't run without it.
shit software, but software anyways.
that's whats bad about it, really. it's just not a startup replacement but one that aims to turn developers into developing software that can't work without it,, without trouble.
why would startup utility provide user authentication? to conquer everything of course.
You're right of course. Fortunately, the startup utility systemd (PID 1) doesn't provide user authentication, so you and I can sleep well at night while using systemd.
Some people will tell you that PAM is no better, but that's what most distribution use these days. But if you want and are knowledgeable enough, you can make a system without PAM for user authentication too.
To be honest, I never got what all the rage is about. As with the foaming at the mouth because of Gnome 3.
I do 'get' init and runlevels and I like them. I can change them with a texteditor and they're all fairly neatly sorted in someplace below /etc or something (can't remember exactly, to lazy to check now). I haven't used runlevels in 9 years or so, I'm not an admin, but I know when they're useful and I probably could start editing and switching them within 5 minutes.
I don't know what all the systemd hate is about, but the shrill voices of nerds who don't have enough sex to remain cool irritate me. I can asure you that I'll chime in if I find out somewhere down the line, when I need runlevels or systemd's equivalent and there's no replacement to be found - some neat newfangled click-tool or equaly easy or better neat textfiles and directories to fiddle about with.
I know very well that systemd will die a very quick death if it turns out to be a shitty system in practice. It's FOSS folks - if it's shit and there's a better, working FOSS alternative people will move (back) to it faster than you can say "Mambo out, Joomla in". No reason to get all that worked up as if the world has ended.
AFAICT that won't happen. systemd is with all the new distros - apparently for the simple reasons that it boots faster. Well, it that appears to be a good enough reason for many people, so be it. New issues probably will be patched and the simple fact that systemd has most distros on its side probably is momentum enough to make init a thing of the past.
That aside, there are, IMHO, way more pressing issues plagueing Linux and it annoys me that no one seems to care about those.
Like for instance: Why is monodevelop the only dev-environment that does not crash on me after a regular installation?
Why do Anjuta, KDevelop, Codeblocks etc. crash on me on mint pure native Debian or Ubuntu linux installs when I attempt to compile something? Isn't the C family of languages our native turf?
Why do 49 out of 50 attempts to compile something downloaded in source from Github or SourceForge fail with obscure error messages? Does something like this still happen on software systems in 2015?? Color me suprised.
Why am I tempted to register with Apple, download XCode and be done with it? This doesn't feel right.
How about fixing or getting all worked up about that shit? It's a shame I can't compile native Linux software on Linux simply due to the fact that all the rest of the bunch aren't as disciplined as Linus Torwalds and get their fucking C/C++ pipeline in order.
The truth is, Linux will be going nowhere if we don't fix some basics, simple down a little and perhaps move towards open or at least fixed-standard hardware concepts. Wether some dude or distro thinks systemd is awesome or not shouldn't matter that much.
We suffer more in our imagination than in reality. - Seneca
Actually, it seems quite the opposite. We have the systemd crowd claiming that it's simpler even when there is a whole new level of complexity in systemd they don't even know about (hint, look for the systemd craziness in /lib). Like the climate change deniers, they believe that since they haven't personally seen a problem in their simple and vanilla system that there isn't a problem at all.
There is no "systemd crowd". There are systemd users that find it easier to use than previous solutions which have bugs which won't ever be fixed like Upstart. /lib/systemd or /usr/lib/systemd. I don't use every systemd utilities, but I caved in for a lot of them and threw away xinetd, my custom FS mount scripts, my custom network scripts... ... which were a pain to tune so that they bootup correctly every time, were a breeze to migrate to systemd. So yes I don't see a problem with my vanilla systems that even distributions didn't know how to setup 15 years ago, and some still can't today.
systemd is actually far less complex than using Upstart + countless tools and daemons with their configurations scattered all other the place.
I don't see the crazyness you talk about in
And my simple and vanilla systems, with their LVM on software RAID, FS on SAN and NAS,
I was "foaming" not so long ago about systemd and Gnome 3. Then I suddenly realized there are a thousand wonderful alternatives out there. I'm not trapped into using these things if I don't want to.
SysD's binary logs have another, serious flaw: they are not designed to be sent over a network. This has been an intrinsic part of syslog for a looong time.
There are a few tools to send journald logs remotely, but they rely on tailing the binary log, then reformatting it and transmitting it over HTTPS to another tool on the destination system.
I found a feature request for journald/sysd/whatever to enable network logging, and the solution they are adding is to... tail the binary logs with basically the same tools.
Putting the disk in the middle and depending on file tailing is such a bad solution. Many things can cause this to fail; it's a total kludge.
I discovered this when investigating how to send journald logs to Splunk. The solution there is to... tail the binary logs with journald to a text file and have Splunk monitor the text file.
Now, this is not a fatal flaw. Journald could (I assume) be enhanced to natively send logs over a network. But, this shows that systemd is not enterprise-grade or production-grade, and was not designed with that kind of reliability in mind.
Reading this, all I could hear was the voice of the Simpsons' comic book guy.
What's your take on the new Avengers movie?
My spoon is too big.
systemd's position as PID 1 on Linux systems creates an enormous SPOF given the complexity of the code. The only sane position systemd developers can take is "we're not ready, please don't use this even as a test in your released distributions".
So that everyone can see the level of BS of this user : "Linux's position as a kernel on Linux systems creates an enormous SPOF given the complexity of the code. The only sane position Linux developers can take is "we're not ready, please don't use this even as a test in your released distributions".
This is the level of discussion, it's pathetic actually.
For all practical purposes, the rapid and unseemly adoption of systemd means that many enterprises running distributions that now rely upon systemd have to make the decision to not trust their distribution any more if they consider their systems mission critical. This is going to make people move to FreeBSD, Oracle, Windows, non-systemd distributions, microservice/microkernels, etc in rapid fashion. It is going to literally kill Linux for the people who have not yet figured out how to deal with the loss of machines (the majority of the enterprise world). And that may be a good thing, in the sense that Linux has in many ways become indistinguishable and directionless in the sea of operating system options. It tries to be far too many things to far too many people.
The problem for you shills of proprietary OS vendors and appliances, is that Linux actually succeeds in being many things to far too many people (in your eyes).
You'll have to do better than that: while you shills cry here, Linux succeeds, and with systemd, is available in even more products than before.
You know the stupid Cloud rage going on right now, systemd allows Linux systems to be rapidly deployed there.
Yes, you shills have no purpose in this matter actually, you've already lost.
Lennart [...] likes to think he is a genius and we simply don't understand his vision, but for a great many people, his vision is the antithesis of what we like about Linux and Unix. Systemd developers don't understand the arguments of simplicity, composability, and small programs that do one thing well.
I guess the problem is that systemd is heavily dependent on Linux, whose "developers don't understand the arguments of simplicity, composability, and small programs that do one thing well", to quote you. These developers (Linux kernel and systemd) only understand the arguments of programs that just work, are robust, adaptable, coherent, fast and efficient, easy to use, difficult to break, the most secure possible.
The truth is the fault doesn't rely totally upon Lennart and his team: Some of the blame can also be assigned to Linus for poor stewardship, but Linus has a set of complex motives and organizations that influence him. Linus should have killed this stuff much earlier.
I think in a few years, we'll realize what a mistake we made in giving Mr. Poettering any chance of credibility in operating system software development.
I hope it comes sooner rather than later.
So you came to the same conclusion as myself. Except that I think Linux, Lennart and co are far more intelligent than you are, and I just happen to agree with them on technical ground with my knowledge of the field. Even my experience of 15+ years of building special purpose Linux OS from scratch agree with systemd and Linux OS, and even with GNU most of the time, believe it or not.
on't know who in their right mind thought it was okay to move critical system infrastructure systems (init, time, logging, etc) into the hands of an untested piece of software which clearly has very deep issues,
Yes, upstart is pretty crappy, isn't it.
Watch this Heartland Institute video
Oh that makes sense.
Oracle Linux is just rebranded Redhat. Oracle switched because Redhat switched (ditto CentOS and all the other Redhat-based distros), not because they saw any inherent superiority in systemd. (And guess who Poettering works for? Hint, their logo is a crimson fedora.)
Sure, Oracle is big enough they could have forked it, but then it wouldn't be 100% Redhat compatible, and they'd have to hire developers to actually write code rather just have a script that globally replaces Redhat trademarks with Oracle trademarks. Both of which would cut into Larry Ellison's bottom line, so won't happen.
The claim of the other poster is that systemd is not enterprise ready. I'd say Oracle's endorsement is a fairly clear refutation of that or at least strong counter evidence.
I'd agree that Oracle's Linux team didn't care much. They were following RedHat's lead but the fact that they followed RedHat's lead still means a lot. If they hated it, they would have picked a non-systemd choice for Oracle Linux instead of RHEL.
Might want to read the SMF documentation before claiming it makes any sense...
Sysvinit [is] simply inadequate.... The model of fork and exit without clear synchronization points is inherently racy, the boot model encoded into sysvinit doesn't reflect a modern system boot, and maintaining large and complex init scripts as conffiles has been painful for years. Nearly every init script, including the ones in my own packages, have various edge-case bugs or problems because it's very hard to write robust service startup in shell, even with the excellent helper programs and shell libraries that Debian has available. A quick perusal of /etc/init.d/skeleton and the complex case statements and careful attention
to status codes required for a proper init script makes this case clear.
"First they came for the slanderers and i said nothing."
Remember the OP's claim. Oracle had to agree to the switch. You don't get more enterprise than Oracle. So their failure to pull away means they didn't think systemd was a terrible idea.
Yes. That's the bulk of enterprise deployment.
Excluding conversion (I'll agree conversions can be complex) like what?
I understand what you are trying to say, that the GGP's post is ridiculous and hyperbolic (seriously, Poettering's code isn't that bad....the absolute worst you can say about it is that he needs to improve as a software architect; that post is moronic).
Still, I don't think I would hold up Oracle as an example of good judgement. They may be thinking, "as long as it's as stable as RedHat, we don't care."
"First they came for the slanderers and i said nothing."
I don't know why this is moderated down, it is absolutely correct. Ubuntu provides and supports both upstart and systemd:
It's worth noting that while systemd is the default in Ubuntu 15.04, all of the Upstart packages are still there, and you can in fact keep using it if you wish. If you want to switch back and forth, you can use Grub and select "Advanced options for Ubuntu," where you will find an "Ubuntu, with Linux ... (upstart)" entry. If you want to permanently switch, install the upstart-sysv package.
Mint is just following their lead, which makes sense given that Mint is based on Ubuntu. This is a non-story, fabricated because editors know systemd flamebait generates traffic.
I thought it was a close call on init systems (and to be fair, systemd isn't exactly the mature, rock-solid solution a replacement init should be!)
The votes for a replacement on the Debian list should have gone with Upstart IMHO as it was the most popular option, although only 1st choice for 2 of the people who mattered.
Still, it doesn't really matter now - what does matter is that the init system is rock-solid, has buy-in from the customer base (ie the community who use Linux, including server admins) and doesn't require too much re-training to understand and administer it. I'm not sure it has any of those 3 currently.
It depends when you mean. The first vote upstart and OpenRC were falling behind. By the second vote they were far behind. There was no viable replacement. At that point the question was
a) Whether to support multiple init systems
b) Whether to unify
There weren't many upstream dependencies so this was close. Then the upstream dependencies started to spread like wildfire through Debian and the choice became:
a) Spend a ton of resources fighting the tide and offering multiple systems. Unclear how to do this.
b) Switch at Jessie
c) Hold out for one more version
There were some subtle aspects but mainly it was never really close. Systemd pulled way ahead and created dependencies.
Again when? By the time of the final vote, by now upstart isn't viable.
That's not going to be the criteria. I don't think init based systems are all that stable. Closer using your list is going to be:
a) Has buy in from the developer base
b1) offer a total environment that is more stable than init's
b2) Is designed to be a standard API replaceable with an IaaS for better stability without applications needing to be changed
c) Be easy to administer.
The 1990s concept of stability where one is worried about the stability of individual instances is being replaced by the virtualization concept of cloud stability.
Two things:
a) Oracle has to deliver stability. They have stability guarantees in their contracts
b) He specifically cited Oracle, so that's why I brought them up.
I do think highly of Oracle. There are certainly problems. But partially those are caused by over promising and partially those are caused by being held to a much higher standard than other vendors where. Oracle can be jerks but there is a good reason they have grown the way they have. So FWIW I would consider their judgement good.
OK what enterprise applications have indicated they have problems with systemd?
Oracle would rather sell you Solaris on Sparc. If Linux develops a reputation for instability, they will only be that much happier (and take Postgresql with it!).
Oracle isn't doing much with Linux. They basically repackage RedHat, so it's not like they have their top minds working on it (Oracle has very good people........but they also have a lot of really bad people).
"First they came for the slanderers and i said nothing."
Just wait till you try to boot the server with the RAID in degraded mode. Oh, the fun you'll have!
Solaris had a process manager years before Linux did. The ideas for systemd came from big box Unixes.
This is great news. I'm really excited about trying out systemd. Everybody's talking about it!!
"I like to lick butts!" by MobileTatsu-NJG (#32700246) (Score:5, Informative)
This is why systemd isn't an init system anymore, but something else entirely. It tries to be all these various underpinnings of a desktop environment at once and Gnome and KDE devs gladly fall in line.
What's really sad is that systemd seems like something I would really like, in about five to ten years when it's mature enough to screw with. It's not something I want anywhere near a production server, or even my desktop. I might never want it on a server, but I like candy-coated desktops so long as I can dig down into the guts. And also, only if it doesn't make sophomoric mistakes like the devs thinking they're smarter than all the classic Unix devs put together, in spite of copious evidence to the contrary.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
I am a skeptical.
Will Mint really fork Ubuntu? And keep an Upstart optional system?
An easier path, is perhaps have two paths (as Mint currently has).
An Ubuntu based system, which would have SystemD,
And a Devuan based system, which would offer other init systems. (The Devuan system would replace the Debian derived Mint).
You know the stupid Cloud rage going on right now, systemd allows Linux systems to be rapidly deployed there.
You lost all *your* credibility there. systemd has absolutely nothing to do with cloud deployment, if anything, it complicates existing tool sets that are already being used for cloud deployments, because it obfuscates underlying process making it even harder to debug mass deployments.
I guess the problem is that systemd is heavily dependent on Linux, whose "developers don't understand the arguments of simplicity, composability, and small programs that do one thing well", to quote you. These developers (Linux kernel and systemd) only understand the arguments of programs that just work, are robust, adaptable, coherent, fast and efficient, easy to use, difficult to break, the most secure possible.
Robust? Efficient? Easy to Use?Just Works? You might be talking about the kernel, but you're definitely not talking about systemd anymore. I would put good money on any kernel developer pissing in your coffee just for saying systemd architecture is anything even remotely comparable to the kernel.
If it ain't broke, don't fix it. The old init system worked just fine. So what if it was scripts, scripts are the heart of any unix system, and have been for years. So what if the more complicated your app was, the more complicated your init process was. Using systemd isn't going to make your special purpose Linux OS any simpler, it still has to do the same damn thing. It's only going to hide that complexity in yet another tool.
Uh, if you can pick something other than systemd, and you can, then systemd can be "swapped out".
So, by your criteria, systemd is a valid choice.
Watch this Heartland Institute video
https://www.youtube.com/watch?...
You can't compare some software on the periphery, in user land to a core component like the pid 1 bootstrap. There is very little reason to support two solutions. It just complicates maintenance and packaging and yields virtually no benefit for the dist, the end user or the overall experience.
People say systemd isn't "rock solid", but I've yet to see any demonstration of that. Major distributions have switched to it, and have been running it successfully for years now.
The amount of time, effort and money being dumped into FreeBSD/PCBSD is amazing, just look at the new feature list for the upcoming PCBSD release. Oh and by the way convert to FreeBSD we have cookies!
If systemd was just a init replacement, i would agree.
But at this point in time the one systemd tarball holds a init replacement, cron replacement, udev, firewall manager (firewalld), logger (journald), networkmanager (networkd), dhcp client, dns client, session/seat tracker (logind) that was also recently put in charge of handling power button and laptop lid events (replacing/merging shutdownd).
And i swear they were planning to put in a userspace TTY manager as well in the near future.
In essence it has pretty much become a second kernel in userspace.
comment first, facts later. http://chem.tufts.edu/AnswersInScience/RelativityofWrong.htm
I don't see any evidence that Oracle is heavily invested in either Solaris or Sparc. They were dying technologies when Oracle bought them and they have done little to revive them. Oracle has the cash for a massive push for Solaris or Sparc innovation and they haven't done it. They've let them fade.
Anyway I've met the thought leaders for Oracle Linux. Their work right now is focused on really large customer support. Oracle is using Oracle Linus to get further into the hosting / cloud / IaaS reoccurring revenue business (think classic Terremark, Sungard...) The people are strong. Areas like application centric virtualization, and virtual compute appliance (Oracle's cheap version of Netezza / Exadata) are where the focus is. Just not the sort of stuff the /. crowd cares about.
Anyway I've met the thought leaders for Oracle Linux. Their work right now is focused on really large customer support. Oracle is using Oracle Linux to get further into the hosting / cloud / IaaS reoccurring revenue business (think classic Terremark, Sungard...) The people are strong. Areas like application centric virtualization, and virtual compute appliance (Oracle's cheap version of Netezza / Exadata) are where the focus is.
Interesting, thx.
"First they came for the slanderers and i said nothing."
Nah, it's not a problem that they are in one tarball (after all, an entire distro can be found in an ISO). The problem is they are all interdependent, with more things growing dependent on them. There is no sane reason that Gnome should depend on a particular init system.
More importantly, the systemd team is taking an ad-hoc, 'code first' approach, which has led to poor interfaces between everything (internal programs and external programs).
I discuss this at length in the journal entry linked to in my sig, below.
"First they came for the slanderers and i said nothing."
To me at least keeping things distributed separately makes it harder for a developer to accidentally cross the internal/external divide.
comment first, facts later. http://chem.tufts.edu/AnswersInScience/RelativityofWrong.htm
Maybe. Gnome still depends on systemd, and it is distributed completely separately.
"First they came for the slanderers and i said nothing."