The electricity prices are low in France, not because nuclear power is cheap, but because they tax it less. It simply isn't economically feasible to build nuclear power plants that must operate on normal market mechanisms; it is too expensive. Gas and coal, and even oil prices makes it impossible.
The people of France and Europe are paying less for electricity generated with nuclear power. How else do I have to phrase that before you'll stop insisting it is impossible? It doesn't matter what kind market situations and various problems you can concoct about how challenging or impossible a task it is to accomplish. It has none the less been accomplished and won't cease to exist for all your insistences against it.
First, there is no real free market in France regarding electricity; almost everything is state owned, controlled and subsidized. Their national energy company, EDF, is bleeding money beyond belief, which are resulting in massive price hikes on electricity in France, with at least a 30% price increase of the next few years.
At the same time the French industry pays way more than their German counterparts, and despite further subsides this will probably be case in the future too.
My point is exactly, that nuclear power simply isn't economically feasible without massive state control, subsides, and by forcing the consumers to pay higher prices. The free market have simply rejected nuclear power as a worthwhile investment because other energy prices are lower.
You could argue that there is a free market failure that allows eg. coal to be used without its producers paying the massive costs of global climate change, and that state intervention is the only real choice in securing clean energy, and that energy price increases by going nuclear, is much cheaper than the absurd cost of climate change. But as a free market solution, nuclear power is a dying technology.
...Beside that, nuclear power also fail on price; it simply can't compete against cheaper energy sources, despite direct and indirect subsides. This is the main reason why very few new nuclear power plants are being build.
You bring to mind a quote. Never let those who say a thing can't be done get in the way of those that are doing it. France produces more than 50% of it's electricity through nuclear and has some of the lowest electricity prices in Europe. It even exports large volumes of electricity to it's neighbours.
The electricity prices are low in France, not because nuclear power is cheap, but because they tax it less. It simply isn't economically feasible to build nuclear power plants that must operate on normal market mechanisms; it is too expensive. Gas and coal, and even oil prices makes it impossible. That was the conclusion too for those Google engineers. And wind power and solar power increases in efficiency all the time and can produce electricity at lower prices than nuclear power.
The only way the nuclear power is ever going to be feasible again, is by strong government regulation, and direct subsides by forcing consumers to pay enough money that the nuclear power investors are happy.
According to those Google engineers, Nuclear power can't solve the problem either.
The problem isn't cheap energy but man made global warming and climate change; the CO2 levels are now so massive that inventing a zero emission ultra cheap energy source, that globally replaced all other polluting energy sources in an instant, no longer is enough stop the global warming process going on for hundreds of years.
You simply have to do much more than just making zero CO2 emission energy to stop the accelerating global climate change going on.
Beside that, nuclear power also fail on price; it simply can't compete against cheaper energy sources, despite direct and indirect subsides. This is the main reason why very few new nuclear power plants are being build.
I think most DD will be much more inclined to keep supporting non-systemd inits if they weren't called "jackass's", and their name and their distro weren't constantly attacked, and their mailings list trolled by people who want them to keep supporting SysVinit.
It is a failed strategy to think open source development is done by harassing developers and throwing tantrums on developer mailing lists and in bug trackers. Asking nicely and making an effort to help will bring much better results.
They want a process to handle things like shutdown, reboot and hibernate via a UI dialog. Previously, Consolekit was that process. But Consolekit was scuttled in favor of Logind. And Logind is dependent on Systemd running as pid1.
Btw, the guy that had the reins of Consolekit at the time of its closure was Poettering...
Yep. He and the ConsoleKit inventor gave the project to Canonical/Ubuntu under the lead of Martin Pitt. You can find the handover mail in the CK mail list archive (it is one of the last mails:-)
Canonical however, decided not develop CK in the end but made "systemd-shim" instead; at first a fork, but later an attempt to clone systemd-logind. Martin Pitt leads that project now.
There are still a handful of paid developers that support non-systemd infrastructure like systemd-shim and CgManager, but they will stop in the end because all new distro development is going to be systemd only. Then what?
It absolutely is true for system utilities (like init). Vim is a text editor. It edits text. It does not edit graphics, init the system, act as a login daemon or multiplex your shell. But then, it's not a system utility. Look at awk, sed, grep, less, etc etc. Look at getty and login. Look at screen.
Exactly. But look at all the systemd "system utilities" like systemctl, journalctl, machinectl; they all work exactly like any other first class Linux system tools; they all only do one thing but do it well, they can be piped, they aren't chatty when successful (and actually care a lot about exit codes), aren't interactive etc, care about text output formatting (turn off legends etc) so they are perfectly scribtable.
The point is that all the systemd tools are doing everything expected by system tools according to "Unix philosophy".
Did you know that in Debian Wheezy there are TWO init systems that work at the same time? They weren't designed to do that but because they do things the Unix way, they don't 'mind' either.
I must say I can't see a reasonable use case for this. Sounds racy in all circumstances.
But here's a "funny" where systemd is most definitely wrong (yes, I have actually been giving it a chance, I just don't like what I see). I have a VM where I have yanked a virtual disk out from under btrfs. My fstab states that I want it to mount in degraded state if necessary (such as if a disk is missing). systemd *REFUSES* even though I explicitly commanded the action. How is that the Unix way? How is that supposed to help uptime? Thank the gods it's not a production box! Then I google as to why that might be and first post I find is some someone claiming IT'S A FEATURE! So there we are, the admin and owner of the box says just do it and damn the consequences and it refuses like a Windows box.
Basically, systemd requires manual intervention to allow to boot btrfs arrays with both/a missing disk/ and in/degraded mode/ Not a bad default really.
Anyway, in order to allow btrfs to automatically boot in degraded mode with missing disks, and doing it/correctly/ you need some extra module/script/daemon to handle it, since neither the kernel nor systemd (udev) have any knowledge about the internal state of btrfs. Nothing new in that, raid etc. have always been handled by such a daemon. I think that if you use mdadm with btrfs raid, you can automatically mount degraded mode arrays. The critical point is the timeout timer; a crude method that needs to be set according to the particular array in question. Bringing up a degraded array as RW risk killing the whole array, so it is not something to be done just because a drive is late at appearing.
Now, just to complete the picture, do you know what journalctl told me about what was failing and why? It said the mount timed out. THAT IS ALL. Is this the system I am supposed to trust in production? The one designed by people who KNOW what they're doing?
Isn't that all you need to know to find the error? Also, use the "-x" with journalctl, it may give further info to generic error messages and even link to more info.
Anyway, systemd have excellent debugging facilities; try to turn on debugging ("kill -56 1" from the CLI, or by setting "MaxLevelKMsg=debug MaxLevelConsole=debug" in "/etc/systemd/journald.conf" and restart (journald or the VM)
Actually, it would not. Why not a program that grabs the requested ports and other resources that require root, then drop privileges and pass them on to the daemon. It would drop right in to any sane init out there. It could even be used on a case by case basis. Launch apache with it but not postgres, etc.
I think we agree somewhat here; yes such a program could be used with any init, and just like systemd, used on a case to case basis. My point was that the existing inertia prevented the making and adoption of such program. With systemd there is no longer any reason for not implementing such a helper program in conjunction other init systems and platforms.
In fact, I think the non-systemd platforms should clone as many of the easy implemented features of systemd as possible; that would help upstream projects a lot.
You seem pretty generous with OTHER PEOPLE's time. I'm fairly sure *BSD will never in a zillion years let systemd anywhere near their OS. They shouldn't! I'm also pretty sure a lot of daemon developers aren't going to sacrifice portability at the alter of systemd. If systemd wasn't such a tangle of dependencies, someone MIGHT implement limited bits of it in other OSes but if you hand them all or nothing, it's going to be nothing. Especially since systemd depends on a linux kernel only feature or 3.
I actually think that the BSD's will develop a systemd clone before the decade is over. Some groups have already started implementing small compatibility layers (systemBSD), others are experimenting with systemd code in order to reverse engineer it for BSD (Uselessd).
Really, over the next couple of years when people actually are starting to "get" systemd, the old ways of doing things with init-scripts etc, will seem very dated.
Appeal to authority isn't a very good argument. Many really experienced developers with a deep expert knowledge about various aspects of low level system design think the design of systemd is crap. Many others consider it too immature for primetime.
Lennart Poettering has demonstrated through his designs that he does NOT understand the "Unix philosophy". If he did, the new init system would raise little controversy and would play much nicer with others.
Appeal to authority is actually a good argument, if it wasn't then it was because heart surgeons knew nothing better about heart surgery than any random ordinary citizen. The CV's of many leading systemd developers is quite impressive.
Lennart Poettering is well aware of how Unix works and "Unix Philosophy". In fact it is sometimes a complaint against systemd that eg. that the systemd tools aren't chatty when successful ("systemctl start daemon" only provides feedback if there is a problem, just like "cp", "mv" etc), or in this case, the handling of a broken fstab.
That people use a rather cartoonish interpretation of what Unix Philosophy is to attack systemd, is another matter. That everything should be small single-function programs piped together with a text-only interface, simply isn't the case for the vast majority of Linux and Unix programs. It is a design ideal that no one really follows for anything remotely complicated. Even Vim isn't correctly designed by this cartoonish interpretation of Unix Philosophy.
Actually, systemd keeps all of that complexity and more, it just sweeps it under the rug and makes it into a single point of failure.
No, systemd _abstracts_ away the complexity like a high level API, thereby making advanced features easier to use. cgroups, capabilities(7) and name spaces are normally really complex features to use, thereby making it error prone. systemd makes it easy (no code involved, just key=value in text config files) to use.
And a single point of failure is often much preferred to having multiple points of failure, since it is much easier to harden and secure one point than hundreds. Like in the case of privilege dropping; having hundreds of implementations of hard to write security sensitive code, increases both the attack surface and the potential number of bugs dramatically. Reviewing hundreds of projects each written in their own style, is also much harder.
Also, unless the daemon decides it wants to give up all portability and lock itself into systemd, it has to implement all of that code anyway and ignore systemd. Or worse, it can add yet another compatibility shim and accommodate systemd as well.
Nothing prevents other Unix like systems in implementing similar features. In this case it would probably make the daemons much more portable across systems since they no longer need to care about how privilege dropping works on a particular system, but leave it all to the init system. It will also make the open source world more secure.
Of course, a SIMPLE utility could do that job on a case by case basis and be usable by systemd or sysvinit or openrc, etc etc. It could also be portable to *BSD and OSX (unlike systemd).
Perhaps. I suspect that the reason why such a feature never was developed was the usual catch 22: such a feature would change how init worked, making it incompatible with other init systems. Since no one could lead such a change, everything remained the same.
Now systemd have taken the lead and if other init systems care, they can now implement such a feature while remaining compatible with all major Linux distros.
Systemd's 'design' reminds me of Robin Williams talking about God getting incredibly stoned and creating the platypus.
As a bonus, that approach wouldn't screw up a simple thing like fstab.
Beauty is of course in the eye of the beholder, but perhaps your perception of systemd isn't without prejudice; many of the core systemd developers a really experienced Linux developers with deep expert knowledge about various aspects of low level system design. You may not like how systemd handles fstab errors, but it is done strictly according to "Unix philosophy", which the systemd developers like Lennart Poettering actually know a lot about.
Meanwhile, where are these experts and those amazing code reviews?
Oh, there are several. RH's for one lead by Florian Weimer, the Coverty project, and probably many white hat (and black hat) security groups; there is prestige in finding a systemd security bug. There is also a lot of systemd developers, so internally there are "many eyes" watching the code. Also, industry interest groups like the IVI automotive group, Samsung (Tizen etc) and several others are using and developing it outside the core systemd group, and are working with deep security aspects of it. All in all, systemd probably only have the Linux kernel as rival when it comes to code review and inspection.
Trying to make a virtue out that of the fact that SysVinit is so crude and broken it exposes userland to potential data corruption is just plain denial.
No, it's just a healthy understanding of the KISS principle. There is a virtue to something too simple to screw up.
SysVinit isn't designed by the "KISS principle". Sure it has almost no functionality and have problems even with even basic init tasks, but that doesn't make it KISS designed, simply because SysVinit doesn't avoid code complexity and code duplication; it just pushes the complexity into the daemons instead of dealing with the problems.
Case in point; SysVinit demands that each and every daemon implements code for dropping privileges if they e.g. need a low port number. That makes SysVinit simpler, but it also means that each and every such daemon must implement such low level, system specific, error prone and security sensitive code. Such code have historically often been exploitable.
systemd acts like a proper init system, and offers a single, centralized solution that every daemon that needs to drop privileges can use. That means that experts can implement this single code base, and it can be thoroughly tested, reviewed and debugged, instead of 100's of different projects implementing this feature, over and over again. This is much more system design by the KISS principle than the SysVinit way of doing things.
The point isn't so much that systemd daemons can be made much safer than SysVinit daemons, but that SysVinit setups are actually much more complex and obscure than systemd setups, the complexity is just showed over to the daemon side.
Stop apologising for abusers. You're part of the problem.
You are absolutely right. Notice how the systemd haters are abusing the moderation system by modding you "flamebait", probably while posting as AC's too.
The systemd haters are a toxic bunch that uses online bullying instead of technical arguments. Wasting time attacking open source developers and open source projects instead of coding an alternative to systemd is exactly why they have been routed from every major Linux distro.
Lets not forget that this whole mess was kicked off because the pro-systemd crowd filed a "systemd is not default" bug. Hows is that even a bug? Did they seriously think people wouldn't retaliate with "systemd is default" bugs?
There is firm backing behind systemd as default init system in Debian. There probably also is a lot of willingness to support more than one init system.
The problem with the eternal war by "committee weasels" and "paper warriors" is that it simply shows that continuing supporting SysVinit is the wrong thing to do for Debian, since it will be used as a permanent excuse to feud an eternal war and "retaliate" as you describe it.
At some point Debian will have to make a decision between kicking out SysVinit for good, or live with eternal flame fests on the mailing lists and in the bug tracker. This decision will be forced because of the toxic behavior of the systemd haters.
Wait, wasn't it forced into the OS they use, against the wishes of the bulk of the users?
You systemd haters are simply living in your own delusional world, undisturbed by the harsh realities: Don't do know that Debian systemd users now outnumber SysVinit users 3-1, even before Debian have released a stable systemd distro?
The vast majority of Linux users that care about init wants systemd, this is why systemd have won a landslide victory in every major Linux distro. Even in Debian the SysVinit faction have failed to mobilize even 5 Debian developers out of 1000 to sponsor a GR to use SysVinit instead of systemd.
You systemd haters are just a tiny, but very vocal and toxic minority in the Linux community. A very good indicator in this is that so many systemd haters like you are logging in as AC's. Another is that that almost all non-systemd development of Linux infrastructure have grinded to a halt. There seems to be almost no Linux developers that support the non-systemd cause.
Sure, keep on attacking open source projects and developers; that will earn you and your fellow travelers exactly what you deserve when it comes to maintaining SysVinit software and getting goodwill at upstream projects.
What you describe isn't the scenario I was trying to describe; you seem to be in total control of the software and can close a bug with impunity; if a user don't like it, they can just go somewhere else.
But imagine you where part of an large organization maintaining a small project. That project used "Library-foo", which just happened to be a target of petty war from a faction: that faction will now see you as an enemy, not because of your project, but because your projects used Lib-foo, instead of Lib-bar. The faction within your organization will then file "political" bugs against your project; each and every time you will have to explain that Lib-bar doesn't have the feature you want and besides simply breaks your software when used in the current version; every time you answer, they will retort with ever more accusations, citing complex internal policy documents, that you have to understand and reject, and then they will slander your project on internal mailing list, claiming that you won't fix bugs and doesn't respond in a timely matter etc. They will then use all the many bugs filed against you and the slandering emails, as evidence of your wrong doings and present their complaints to higher ups in the hierarchy; again you will have to defend yourself, and so on and so on.
In case of Debian, you can also experience a so called "NMU", that means your enemies, if they win the "paper war", can force a patch into your project to support their pet "Lib-bar". Now you have a turd of a patch that leads to feature regression, but you can't really touch it unless the faction will attack you again and again, complaining that your are sabotaging project decisions etc.
In short, a bug tracker is an excellent weapon for "paper war warriors" and "committee weasels". At the moment Debian is experience such a paper war, so it is becoming ever more bureaucratic and top down steered with ever more NMU's that sucks the soul out of the volunteer developers.
No. It should at least come up far enough to diagnose and fix. Did you miss the part about not coming up far enough to edit fstab?
Sure, but if that really was the case then it was a bug, most likely a distro bug, or perhaps the OP was impatient and didn't wait 3-5 minutes for daemon timeout.
systemd will always try to boot into "emergency mode" (like Runlevel 1) when fstab is broken It is quite easy to show, just spawn a systemd OS container, edit it's fstab and reboot the container, and watch how you get an emergency shell. A quick glance in the journal will show exactly what went wrong. Since systemd lives in initramfsf while booting and switches to root when the root-fs is mounted, it will be functional to some degree even if just/boot still works.
systemd is simply designed handle situations correctly that SysVinit simply can't deal with.
Trying to make a virtue out that of the fact that SysVinit is so crude and broken it exposes userland to potential data corruption is just plain denial.
I think you are paranoid in suspecting SysVinit supporters being a front end for Putin/NSA etc. Sure their relentless hate attacks against Linux developers and Linux porjects may look like a concerted effort to split the Linux community, but at least some of them are sincere Linux users, perhaps lacking modern technical insight, but well-meaning never the less.
I cannot find the option any more to filter out AC posts. It is very clear that there is a concerted attempt to deliberate inflame on here and all the inflame posts are done by ACs. How to ignore?
Yes, the AC's are out in force. The systemd haters do like that because that way they can post hate posts and moderate at the same time. The systemd haters are good at online bullying and trolling, but of course suck when it comes to make a positive contribution.
In the sysvinit scripts the philosophy is not so stark: the aim is to bring the system up to the greatest extent possible even in the presence of failures. If a single mount or service fails, we report the error and try to continue on. It's not perfect, but mitigation in the face of unexpected failure is never going to be.
If I make a typo when editing the fstab, I don't think bailing out is ever appropriate. The "nofail" flag is only useful for expected failures, and I think that the sysvinit script is correct in not using it as a basis for unilaterally failing startup when in almost all cases we could bring the system up to a state where the admin can log in and rectify things. This is going to be incorrect from the worldview of a perfectionist, but it's certainly the pragmatic choice.
There are several problems with doing things that way; first of all, its is evident that it isn't uncommon for people to have stale or plain broken fstab entries. This strongly suggest that they are unaware of this, probably because if the system boots, people don't look in the log files. Finding such critical errors in legacy style syslog text logs aren't easy either; if you don't know the nature of the error, it is hard to grep for it.
So exactly because SysVinit cover up such fstab errors, they may remain undiscovered until some other part of the system fails in a noisy matter; at that time irretrievable data loss may have occurred. Allowing such data loss isn't being pragmatic, it is bad practice by any standard.
systemd detects the fstab problem and boots into a special "emergency mode" (like runlevel 1) where the admin can diagnose and fix the problems. systemd works really well in this regard; a simple "journalctl -b -p err" will find all such errors in the boot process and display them.
That's good, but there are other ways that fstab could get out of sync with your hardware, e.g. a drive dies, or just screwed up, say, you added something post-installation and got it wrong. It's important that there be a way to boot the system up far enough that such repairs can be made, without having to get some other media to boot from.
It has always been possible to boot into "emergency mode (think Runlevel 1)" if systemd detected a fstab problem, or if there are any such mount point problems from dying disks etc. systemd have several fallback mechanisms depending of the nature of the boot problem.
I think the "work in progress" is about Debian installers detecting obviously bad fstab entries when upgrading, and eg. mark them "nofail" or ask the user to fix the fstab before proceeding.
And this is exactly the kind of thing that makes many of us wary of systemd. I saw a post from someone a few weeks ago complaining that systemd wouldn't let his system start up because there was a problem in/etc/fstab, and he couldn't edit/etc/fstab because systemd wouldn't let his system start up.
A system shouldn't be allowed to boot if important disks are missing since this can lead to "silent" data corruption".
systemd does the right thing by stopping normal boot and just boot into a safe, minimal shell. A quick glace in the log file (journal) will instantly tell you (using red letters for emphasis) that fstab is broken in such and such a way. A quick edit with Vim can then solve the problem.
If you have fstab entries for disk you really don't care whether they show up at boot or not, they can be marked with "nofail", that way systemd will ignore any missing disk errors from that entry and just boot normally.
Debian have many good sides. It also suffers from fractions; the problem isn't so much that people disagree about some time petty technical things, but that they abuse the Debian bug tracker and governmental system in order to feud their petty wars on usually innocent package maintainers. By filling "political" bugs together with a lot of whining and twisted representation of facts, and then run and complain to higher ups in the hierarchy, they can force the package maintainer into endless, repeated explanations why things are like they. You can basically force the package maintainers to always be in defensive position. Not fun at all.
In this case it is the "anti-systemd" faction that is abusing the system and the developers, but there have been several other, perhaps smaller cases before this.
The "anti-systemd" faction probably just think they are fighting with their backs against the wall, trying to claw out a place in Debian with any means necessary before it is "too late".
But if they keep on attacking Debian developers like they do now, I think their strategy will backfire. Before the bitter systemd debacles started, most Debian developers where probably quite keen to support non-systemd inits too. But this rather poisonous war just never seems to end, so some Debian developers are starting to think, that the only way forward is an outright banishment of official SysVinit support after Jessie is released.
I was kind of neutral about systemd until I realized that the only way to get centralized logging out of systemd boxes is to turn on syslog mode (journald has no concept of network transport).
At that point, I realized that the systemd developers aren't actually server admins.
It is trivial to export systemd log files to such a centralized logging server by using "systemd-journal-gatewayd", it can even export the logs in JSON to preserve the rich metadata. The details are here: http://www.freedesktop.org/sof...
So to sum up; it is easy to make systemd work with centralized logging servers, and it support a wide range of formats and encryption and security features too.
>> If it wasn't for Red Hat, Linux wouldn't exist today.
Thanks for the laugh. I really didn't think anyone could be that clueless.
Your high UID suggest that you weren't around when Linux was young. If it wasn't for Red Hat, Linux wouldn't have made it as a viable commercial alternative to MS, period! Red Hats technical contributions alone was a huge factor in Linux' success. The fact that RH understood to make money on Open Source software, something most other Linux vendors failed to do or even understand, made it possible to hire lots of software engineers, and pay lawyers to defend Linux from the barrage of constant patent lawsuits Linux faced. Remember the SCO case? And while IBM lawyers played a role in that too, IBM was only involved because RH had made Linux enterprise ready.
Here is an old statistic from 2007 that shows how much of the Linux kernel that is written by RH. http://www.cnet.com/news/who-w... The pattern have been like this more or less since the late 1990's. Same with other core Linux projects like gcc, kernel utils, glibc, etc. Take a look of this incomplete list: http://fedoraproject.org/wiki/...
Most other Linux distros are thriving in the slipstream of the development made by Red Hat in all core aspects of Linux as an OS.
Using script files to setup and manage daemons because init is so primitive like SysVinit is, is simply a bad idea.
Mixing executable code and declarative config statements like script based init systems do, is simply indefensible; it makes it hard to parse for both humans and machines.
No one would ever design an init-system these days that didn't use pure text files for daemon config. SysVinit and similar are relics from a time when computing was done in a completely different way than today.
I am not trying to be disrespectful here for the pioneers that made various OS's back in the 1960's, 1970's and 1980's. It is just that some of the design choices they made, reflected the contemporary problems they had.
They made some simple but very flexible init systems based on shell scripts. But the simplicity just showed all kinds of problems over to the user space developer side, like handling dropping privileges when a daemon needed a low number port etc. And many people, including me, have long been of the opinion that such init-systems have been obsolete for years (if not decades). Most if not all certified Unix vendors have replaced their script based init systems (SMF and launchd are major inspiration init systems for systemd).
As I've said elsewhere in this thread you are failing to understand good overall system design and factoring if you think a large complex program that incorporates every behavior into itself and puts only configuration options into files is 'superior'.
I do think I understand enough about how OS's work to have a qualified opinion. We just happen to disagree about some things and is having a civilized exchange of arguments.
The core of systemd is certainly a lot more complex than SysVinit and similar, and the complexity isn't avoided by using SysVinit; it is just moved into other external programs.
systemd it isn't large, and all core daemons are really lightweight when it comes to memory/cpu and other resources.
A better solution would be individual scripts which can perform all the functions required for each service and coordinate with each other, with all the commonalities between them pulled out into shared library code. This allows for any level of flexibility and initialization strategy a packager or developer requires without forcing anyone to do anything and avoiding large disruptive changes in key subsystems.
I am really not interested in whether or not you understand the Unix way of doing things, but it is a real and highly beneficial approach which you might do well to actually understand. I don't have a big issue with a lot of the functionality that we're talking about here, though I think you are very much oversold on binary logging, but it doesn't all need to be bundled together in one package that is in any practical sense impossible to incorporate what you want from without being forced to swallow the whole thing.
Sure, an improved "Super" SysVinit would have been easier to deal with for many. Upstart was one such attempt. But the problems with making such an improved script based init system is harder than it appears; Why should upstream support it, if it breaks compatibility or just have small improvements? Changing how everything works for a small gain will mean little traction for such a project, which again will mean little support from upstream projects.
What makes systemd so attractive for upstream projects is, that while it changes things a lot, it also really help upstream projects in many ways by making a cross distro compatibility layer, providing needed low level functions like logind, and by simplifying daemon development and daemon configs. I am aware that you think systemd provides no benefit for your user case; fair enough, but it is a mistake to think other people doesn't have other user cases where systemd is a huge improvement over existing solutions.
This is forced on me when I don't need or want it for exactly what reason that you can explain? If I want binary logging there are already solutions, which you have JUST NAMED which work fine. I've no need or interest in having an init system that is too big for its britches foisting another one on me. Compartmentalization IS important.
Well, you can just use a non-systemd Linux distro like Slackware. It is a nice, stable and conservative distro. So nobody is forced to use systemd on Linux if they don't want to.
But if you want to use a systemd distro, it is no problem to _only_ have flat file text logs. Just configure journald not to make any log files and forward all messages to rsyslog. systemd doesn't force you to use its binary log files at all, and you can still use rsyslog just the way you always had. This is all in the systemd documentation and man pages.
Personally I think the reaction against binary log files is based on a lack of actual analysis and lack of experience with them. The journal files is seriously good stuff for any admin.
Same with systemd; there is too much blatantly misinformation about systemd going on, with people rejecting it with weak and feeble arguments like "Unix Philosophy" etc. Trying to make a virtue out of the fact that SysVinit is crude, simple and lacks basic functionality, isn't going to convince people who have tried the advantages of systemd.
Sure, SysVinit is "simple", but only because it puts the burden and complexity on each and every program using it; daemonization, dropping privileges after getting a low number port etc. are all implemented in each and every user space program, instead of just having a single code base in init.
Having often complex executable config files where code and config statements are mixed, is simply a bad idea. Of course a daemon should be configured with structured text files like systemd uses. Using scripts for config files is just a madness that have been so normalized that the victims no longer recognize it as madness.
Slashdot Mirror
The electricity prices are low in France, not because nuclear power is cheap, but because they tax it less. It simply isn't economically feasible to build nuclear power plants that must operate on normal market mechanisms; it is too expensive. Gas and coal, and even oil prices makes it impossible.
The people of France and Europe are paying less for electricity generated with nuclear power. How else do I have to phrase that before you'll stop insisting it is impossible? It doesn't matter what kind market situations and various problems you can concoct about how challenging or impossible a task it is to accomplish. It has none the less been accomplished and won't cease to exist for all your insistences against it.
First, there is no real free market in France regarding electricity; almost everything is state owned, controlled and subsidized. Their national energy company, EDF, is bleeding money beyond belief, which are resulting in massive price hikes on electricity in France, with at least a 30% price increase of the next few years.
At the same time the French industry pays way more than their German counterparts, and despite further subsides this will probably be case in the future too.
My point is exactly, that nuclear power simply isn't economically feasible without massive state control, subsides, and by forcing the consumers to pay higher prices. The free market have simply rejected nuclear power as a worthwhile investment because other energy prices are lower.
You could argue that there is a free market failure that allows eg. coal to be used without its producers paying the massive costs of global climate change, and that state intervention is the only real choice in securing clean energy, and that energy price increases by going nuclear, is much cheaper than the absurd cost of climate change. But as a free market solution, nuclear power is a dying technology.
...Beside that, nuclear power also fail on price; it simply can't compete against cheaper energy sources, despite direct and indirect subsides. This is the main reason why very few new nuclear power plants are being build.
You bring to mind a quote.
Never let those who say a thing can't be done get in the way of those that are doing it.
France produces more than 50% of it's electricity through nuclear and has some of the lowest electricity prices in Europe. It even exports large volumes of electricity to it's neighbours.
The electricity prices are low in France, not because nuclear power is cheap, but because they tax it less. It simply isn't economically feasible to build nuclear power plants that must operate on normal market mechanisms; it is too expensive. Gas and coal, and even oil prices makes it impossible. That was the conclusion too for those Google engineers. And wind power and solar power increases in efficiency all the time and can produce electricity at lower prices than nuclear power.
The only way the nuclear power is ever going to be feasible again, is by strong government regulation, and direct subsides by forcing consumers to pay enough money that the nuclear power investors are happy.
According to those Google engineers, Nuclear power can't solve the problem either.
The problem isn't cheap energy but man made global warming and climate change; the CO2 levels are now so massive that inventing a zero emission ultra cheap energy source, that globally replaced all other polluting energy sources in an instant, no longer is enough stop the global warming process going on for hundreds of years.
You simply have to do much more than just making zero CO2 emission energy to stop the accelerating global climate change going on.
Beside that, nuclear power also fail on price; it simply can't compete against cheaper energy sources, despite direct and indirect subsides. This is the main reason why very few new nuclear power plants are being build.
I think most DD will be much more inclined to keep supporting non-systemd inits if they weren't called "jackass's", and their name and their distro weren't constantly attacked, and their mailings list trolled by people who want them to keep supporting SysVinit.
It is a failed strategy to think open source development is done by harassing developers and throwing tantrums on developer mailing lists and in bug trackers. Asking nicely and making an effort to help will bring much better results.
They want a process to handle things like shutdown, reboot and hibernate via a UI dialog. Previously, Consolekit was that process. But Consolekit was scuttled in favor of Logind. And Logind is dependent on Systemd running as pid1.
Btw, the guy that had the reins of Consolekit at the time of its closure was Poettering...
Yep. He and the ConsoleKit inventor gave the project to Canonical/Ubuntu under the lead of Martin Pitt. You can find the handover mail in the CK mail list archive (it is one of the last mails :-)
Canonical however, decided not develop CK in the end but made "systemd-shim" instead; at first a fork, but later an attempt to clone systemd-logind. Martin Pitt leads that project now.
There are still a handful of paid developers that support non-systemd infrastructure like systemd-shim and CgManager, but they will stop in the end because all new distro development is going to be systemd only. Then what?
It absolutely is true for system utilities (like init). Vim is a text editor. It edits text. It does not edit graphics, init the system, act as a login daemon or multiplex your shell. But then, it's not a system utility. Look at awk, sed, grep, less, etc etc. Look at getty and login. Look at screen.
Exactly. But look at all the systemd "system utilities" like systemctl, journalctl, machinectl; they all work exactly like any other first class Linux system tools; they all only do one thing but do it well, they can be piped, they aren't chatty when successful (and actually care a lot about exit codes), aren't interactive etc, care about text output formatting (turn off legends etc) so they are perfectly scribtable.
The point is that all the systemd tools are doing everything expected by system tools according to "Unix philosophy".
Did you know that in Debian Wheezy there are TWO init systems that work at the same time? They weren't designed to do that but because they do things the Unix way, they don't 'mind' either.
I must say I can't see a reasonable use case for this. Sounds racy in all circumstances.
But here's a "funny" where systemd is most definitely wrong (yes, I have actually been giving it a chance, I just don't like what I see). I have a VM where I have yanked a virtual disk out from under btrfs. My fstab states that I want it to mount in degraded state if necessary (such as if a disk is missing). systemd *REFUSES* even though I explicitly commanded the action. How is that the Unix way? How is that supposed to help uptime? Thank the gods it's not a production box! Then I google as to why that might be and first post I find is some someone claiming IT'S A FEATURE! So there we are, the admin and owner of the box says just do it and damn the consequences and it refuses like a Windows box.
Take a look on these discussions;
http://www.spinics.net/lists/l...
http://lists.freedesktop.org/a...
Basically, systemd requires manual intervention to allow to boot btrfs arrays with both /a missing disk/ and in /degraded mode/
Not a bad default really.
Anyway, in order to allow btrfs to automatically boot in degraded mode with missing disks, and doing it /correctly/ you need some extra module/script/daemon to handle it, since neither the kernel nor systemd (udev) have any knowledge about the internal state of btrfs. Nothing new in that, raid etc. have always been handled by such a daemon. I think that if you use mdadm with btrfs raid, you can automatically mount degraded mode arrays. The critical point is the timeout timer; a crude method that needs to be set according to the particular array in question.
Bringing up a degraded array as RW risk killing the whole array, so it is not something to be done just because a drive is late at appearing.
http://git.neil.brown.name/git...
Now, just to complete the picture, do you know what journalctl told me about what was failing and why? It said the mount timed out. THAT IS ALL. Is this the system I am supposed to trust in production? The one designed by people who KNOW what they're doing?
Isn't that all you need to know to find the error?
Also, use the "-x" with journalctl, it may give further info to generic error messages and even link to more info.
Anyway, systemd have excellent debugging facilities; try to turn on debugging ("kill -56 1" from the CLI, or by setting "MaxLevelKMsg=debug
MaxLevelConsole=debug" in "/etc/systemd/journald.conf" and restart (journald or the VM)
Digging in to it, I fin
Actually, it would not. Why not a program that grabs the requested ports and other resources that require root, then drop privileges and pass them on to the daemon. It would drop right in to any sane init out there. It could even be used on a case by case basis. Launch apache with it but not postgres, etc.
I think we agree somewhat here; yes such a program could be used with any init, and just like systemd, used on a case to case basis.
My point was that the existing inertia prevented the making and adoption of such program. With systemd there is no longer any reason for not implementing such a helper program in conjunction other init systems and platforms.
In fact, I think the non-systemd platforms should clone as many of the easy implemented features of systemd as possible; that would help upstream projects a lot.
You seem pretty generous with OTHER PEOPLE's time. I'm fairly sure *BSD will never in a zillion years let systemd anywhere near their OS. They shouldn't! I'm also pretty sure a lot of daemon developers aren't going to sacrifice portability at the alter of systemd. If systemd wasn't such a tangle of dependencies, someone MIGHT implement limited bits of it in other OSes but if you hand them all or nothing, it's going to be nothing. Especially since systemd depends on a linux kernel only feature or 3.
I actually think that the BSD's will develop a systemd clone before the decade is over. Some groups have already started implementing small compatibility layers (systemBSD), others are experimenting with systemd code in order to reverse engineer it for BSD (Uselessd).
Really, over the next couple of years when people actually are starting to "get" systemd, the old ways of doing things with init-scripts etc, will seem very dated.
Appeal to authority isn't a very good argument. Many really experienced developers with a deep expert knowledge about various aspects of low level system design think the design of systemd is crap. Many others consider it too immature for primetime.
Lennart Poettering has demonstrated through his designs that he does NOT understand the "Unix philosophy". If he did, the new init system would raise little controversy and would play much nicer with others.
Appeal to authority is actually a good argument, if it wasn't then it was because heart surgeons knew nothing better about heart surgery than any random ordinary citizen. The CV's of many leading systemd developers is quite impressive.
Lennart Poettering is well aware of how Unix works and "Unix Philosophy". In fact it is sometimes a complaint against systemd that eg. that the systemd tools aren't chatty when successful ("systemctl start daemon" only provides feedback if there is a problem, just like "cp", "mv" etc), or in this case, the handling of a broken fstab.
That people use a rather cartoonish interpretation of what Unix Philosophy is to attack systemd, is another matter. That everything should be small single-function programs piped together with a text-only interface, simply isn't the case for the vast majority of Linux and Unix programs. It is a design ideal that no one really follows for anything remotely complicated. Even Vim isn't correctly designed by this cartoonish interpretation of Unix Philosophy.
Actually, systemd keeps all of that complexity and more, it just sweeps it under the rug and makes it into a single point of failure.
No, systemd _abstracts_ away the complexity like a high level API, thereby making advanced features easier to use. cgroups, capabilities(7) and name spaces are normally really complex features to use, thereby making it error prone. systemd makes it easy (no code involved, just key=value in text config files) to use.
And a single point of failure is often much preferred to having multiple points of failure, since it is much easier to harden and secure one point than hundreds. Like in the case of privilege dropping; having hundreds of implementations of hard to write security sensitive code, increases both the attack surface and the potential number of bugs dramatically. Reviewing hundreds of projects each written in their own style, is also much harder.
Also, unless the daemon decides it wants to give up all portability and lock itself into systemd, it has to implement all of that code anyway and ignore systemd. Or worse, it can add yet another compatibility shim and accommodate systemd as well.
Nothing prevents other Unix like systems in implementing similar features.
In this case it would probably make the daemons much more portable across systems since they no longer need to care about how privilege dropping works on a particular system, but leave it all to the init system. It will also make the open source world more secure.
Of course, a SIMPLE utility could do that job on a case by case basis and be usable by systemd or sysvinit or openrc, etc etc. It could also be portable to *BSD and OSX (unlike systemd).
Perhaps. I suspect that the reason why such a feature never was developed was the usual catch 22: such a feature would change how init worked, making it incompatible with other init systems. Since no one could lead such a change, everything remained the same.
Now systemd have taken the lead and if other init systems care, they can now implement such a feature while remaining compatible with all major Linux distros.
Systemd's 'design' reminds me of Robin Williams talking about God getting incredibly stoned and creating the platypus.
As a bonus, that approach wouldn't screw up a simple thing like fstab.
Beauty is of course in the eye of the beholder, but perhaps your perception of systemd isn't without prejudice; many of the core systemd developers a really experienced Linux developers with deep expert knowledge about various aspects of low level system design.
You may not like how systemd handles fstab errors, but it is done strictly according to "Unix philosophy", which the systemd developers like Lennart Poettering actually know a lot about.
Meanwhile, where are these experts and those amazing code reviews?
Oh, there are several. RH's for one lead by Florian Weimer, the Coverty project, and probably many white hat (and black hat) security groups; there is prestige in finding a systemd security bug.
There is also a lot of systemd developers, so internally there are "many eyes" watching the code. Also, industry interest groups like the IVI automotive group, Samsung (Tizen etc) and several others are using and developing it outside the core systemd group, and are working with deep security aspects of it. All in all, systemd probably only have the Linux kernel as rival when it comes to code review and inspection.
Trying to make a virtue out that of the fact that SysVinit is so crude and broken it exposes userland to potential data corruption is just plain denial.
No, it's just a healthy understanding of the KISS principle. There is a virtue to something too simple to screw up.
SysVinit isn't designed by the "KISS principle". Sure it has almost no functionality and have problems even with even basic init tasks, but that doesn't make it KISS designed, simply because SysVinit doesn't avoid code complexity and code duplication; it just pushes the complexity into the daemons instead of dealing with the problems.
Case in point; SysVinit demands that each and every daemon implements code for dropping privileges if they e.g. need a low port number. That makes SysVinit simpler, but it also means that each and every such daemon must implement such low level, system specific, error prone and security sensitive code. Such code have historically often been exploitable.
systemd acts like a proper init system, and offers a single, centralized solution that every daemon that needs to drop privileges can use. That means that experts can implement this single code base, and it can be thoroughly tested, reviewed and debugged, instead of 100's of different projects implementing this feature, over and over again. This is much more system design by the KISS principle than the SysVinit way of doing things.
The point isn't so much that systemd daemons can be made much safer than SysVinit daemons, but that SysVinit setups are actually much more complex and obscure than systemd setups, the complexity is just showed over to the daemon side.
Stop apologising for abusers. You're part of the problem.
You are absolutely right. Notice how the systemd haters are abusing the moderation system by modding you "flamebait", probably while posting as AC's too.
The systemd haters are a toxic bunch that uses online bullying instead of technical arguments. Wasting time attacking open source developers and open source projects instead of coding an alternative to systemd is exactly why they have been routed from every major Linux distro.
Lets not forget that this whole mess was kicked off because the pro-systemd crowd filed a "systemd is not default" bug. Hows is that even a bug? Did they seriously think people wouldn't retaliate with "systemd is default" bugs?
There is firm backing behind systemd as default init system in Debian. There probably also is a lot of willingness to support more than one init system.
The problem with the eternal war by "committee weasels" and "paper warriors" is that it simply shows that continuing supporting SysVinit is the wrong thing to do for Debian, since it will be used as a permanent excuse to feud an eternal war and "retaliate" as you describe it.
At some point Debian will have to make a decision between kicking out SysVinit for good, or live with eternal flame fests on the mailing lists and in the bug tracker. This decision will be forced because of the toxic behavior of the systemd haters.
You systemd haters are simply living in your own delusional world, undisturbed by the harsh realities:
Don't do know that Debian systemd users now outnumber SysVinit users 3-1, even before Debian have released a stable systemd distro?
The vast majority of Linux users that care about init wants systemd, this is why systemd have won a landslide victory in every major Linux distro. Even in Debian the SysVinit faction have failed to mobilize even 5 Debian developers out of 1000 to sponsor a GR to use SysVinit instead of systemd.
You systemd haters are just a tiny, but very vocal and toxic minority in the Linux community. A very good indicator in this is that so many systemd haters like you are logging in as AC's. Another is that that almost all non-systemd development of Linux infrastructure have grinded to a halt. There seems to be almost no Linux developers that support the non-systemd cause.
Sure, keep on attacking open source projects and developers; that will earn you and your fellow travelers exactly what you deserve when it comes to maintaining SysVinit software and getting goodwill at upstream projects.
What you describe isn't the scenario I was trying to describe; you seem to be in total control of the software and can close a bug with impunity; if a user don't like it, they can just go somewhere else.
But imagine you where part of an large organization maintaining a small project. That project used "Library-foo", which just happened to be a target of petty war from a faction: that faction will now see you as an enemy, not because of your project, but because your projects used Lib-foo, instead of Lib-bar. The faction within your organization will then file "political" bugs against your project; each and every time you will have to explain that Lib-bar doesn't have the feature you want and besides simply breaks your software when used in the current version; every time you answer, they will retort with ever more accusations, citing complex internal policy documents, that you have to understand and reject, and then they will slander your project on internal mailing list, claiming that you won't fix bugs and doesn't respond in a timely matter etc. They will then use all the many bugs filed against you and the slandering emails, as evidence of your wrong doings and present their complaints to higher ups in the hierarchy; again you will have to defend yourself, and so on and so on.
In case of Debian, you can also experience a so called "NMU", that means your enemies, if they win the "paper war", can force a patch into your project to support their pet "Lib-bar". Now you have a turd of a patch that leads to feature regression, but you can't really touch it unless the faction will attack you again and again, complaining that your are sabotaging project decisions etc.
In short, a bug tracker is an excellent weapon for "paper war warriors" and "committee weasels". At the moment Debian is experience such a paper war, so it is becoming ever more bureaucratic and top down steered with ever more NMU's that sucks the soul out of the volunteer developers.
No. It should at least come up far enough to diagnose and fix. Did you miss the part about not coming up far enough to edit fstab?
Sure, but if that really was the case then it was a bug, most likely a distro bug, or perhaps the OP was impatient and didn't wait 3-5 minutes for daemon timeout.
systemd will always try to boot into "emergency mode" (like Runlevel 1) when fstab is broken It is quite easy to show, just spawn a systemd OS container, edit it's fstab and reboot the container, and watch how you get an emergency shell. A quick glance in the journal will show exactly what went wrong. /boot still works.
Since systemd lives in initramfsf while booting and switches to root when the root-fs is mounted, it will be functional to some degree even if just
systemd is simply designed handle situations correctly that SysVinit simply can't deal with.
Trying to make a virtue out that of the fact that SysVinit is so crude and broken it exposes userland to potential data corruption is just plain denial.
I think you are paranoid in suspecting SysVinit supporters being a front end for Putin/NSA etc. Sure their relentless hate attacks against Linux developers and Linux porjects may look like a concerted effort to split the Linux community, but at least some of them are sincere Linux users, perhaps lacking modern technical insight, but well-meaning never the less.
I cannot find the option any more to filter out AC posts. It is very clear that there is a concerted attempt to deliberate inflame on here and all the inflame posts are done by ACs. How to ignore?
Yes, the AC's are out in force. The systemd haters do like that because that way they can post hate posts and moderate at the same time. The systemd haters are good at online bullying and trolling, but of course suck when it comes to make a positive contribution.
It would be a shame. A lot of people worked hard for POSIX, and I think POSIX does have a purpose.
No. Posix is supported on systemd Linux distros. Doesn't make a difference there.
In the sysvinit scripts the philosophy is not so stark: the aim is to bring the system up to the greatest extent possible even in the presence of failures. If a single mount or service fails, we report the error and try to continue on. It's not perfect, but mitigation in the face of unexpected failure is never going to be.
If I make a typo when editing the fstab, I don't think bailing out is ever appropriate. The "nofail" flag is only useful for expected failures, and I think that the sysvinit script is correct in not using it as a basis for unilaterally failing startup when in almost all cases we could bring the system up to a state where the admin can log in and rectify things. This is going to be incorrect from the worldview of a perfectionist, but it's certainly the pragmatic choice.
There are several problems with doing things that way; first of all, its is evident that it isn't uncommon for people to have stale or plain broken fstab entries. This strongly suggest that they are unaware of this, probably because if the system boots, people don't look in the log files. Finding such critical errors in legacy style syslog text logs aren't easy either; if you don't know the nature of the error, it is hard to grep for it.
So exactly because SysVinit cover up such fstab errors, they may remain undiscovered until some other part of the system fails in a noisy matter; at that time irretrievable data loss may have occurred. Allowing such data loss isn't being pragmatic, it is bad practice by any standard.
systemd detects the fstab problem and boots into a special "emergency mode" (like runlevel 1) where the admin can diagnose and fix the problems.
systemd works really well in this regard; a simple "journalctl -b -p err" will find all such errors in the boot process and display them.
That's good, but there are other ways that fstab could get out of sync with your hardware, e.g. a drive dies, or just screwed up, say, you added something post-installation and got it wrong. It's important that there be a way to boot the system up far enough that such repairs can be made, without having to get some other media to boot from.
It has always been possible to boot into "emergency mode (think Runlevel 1)" if systemd detected a fstab problem, or if there are any such mount point problems from dying disks etc. systemd have several fallback mechanisms depending of the nature of the boot problem.
I think the "work in progress" is about Debian installers detecting obviously bad fstab entries when upgrading, and eg. mark them "nofail" or ask the user to fix the fstab before proceeding.
And this is exactly the kind of thing that makes many of us wary of systemd. I saw a post from someone a few weeks ago complaining that systemd wouldn't let his system start up because there was a problem in /etc/fstab, and he couldn't edit /etc/fstab because systemd wouldn't let his system start up.
Well, systemd behaves according to classic "Unix Philosophy", see here under "Rule of repair":
http://en.wikipedia.org/wiki/U...
A system shouldn't be allowed to boot if important disks are missing since this can lead to "silent" data corruption".
systemd does the right thing by stopping normal boot and just boot into a safe, minimal shell. A quick glace in the log file (journal) will instantly tell you (using red letters for emphasis) that fstab is broken in such and such a way. A quick edit with Vim can then solve the problem.
If you have fstab entries for disk you really don't care whether they show up at boot or not, they can be marked with "nofail", that way systemd will ignore any missing disk errors from that entry and just boot normally.
Debian have many good sides. It also suffers from fractions; the problem isn't so much that people disagree about some time petty technical things, but that they abuse the Debian bug tracker and governmental system in order to feud their petty wars on usually innocent package maintainers. By filling "political" bugs together with a lot of whining and twisted representation of facts, and then run and complain to higher ups in the hierarchy, they can force the package maintainer into endless, repeated explanations why things are like they. You can basically force the package maintainers to always be in defensive position. Not fun at all.
In this case it is the "anti-systemd" faction that is abusing the system and the developers, but there have been several other, perhaps smaller cases before this.
The "anti-systemd" faction probably just think they are fighting with their backs against the wall, trying to claw out a place in Debian with any means necessary before it is "too late".
But if they keep on attacking Debian developers like they do now, I think their strategy will backfire. Before the bitter systemd debacles started, most Debian developers where probably quite keen to support non-systemd inits too. But this rather poisonous war just never seems to end, so some Debian developers are starting to think, that the only way forward is an outright banishment of official SysVinit support after Jessie is released.
I was kind of neutral about systemd until I realized that the only way to get centralized logging out of systemd boxes is to turn on syslog mode (journald has no concept of network transport).
At that point, I realized that the systemd developers aren't actually server admins.
It is trivial to export systemd log files to such a centralized logging server by using "systemd-journal-gatewayd", it can even export the logs in JSON to preserve the rich metadata.
The details are here:
http://www.freedesktop.org/sof...
So to sum up; it is easy to make systemd work with centralized logging servers, and it support a wide range of formats and encryption and security features too.
>> If it wasn't for Red Hat, Linux wouldn't exist today.
Thanks for the laugh. I really didn't think anyone could be that clueless.
Your high UID suggest that you weren't around when Linux was young. If it wasn't for Red Hat, Linux wouldn't have made it as a viable commercial alternative to MS, period!
Red Hats technical contributions alone was a huge factor in Linux' success. The fact that RH understood to make money on Open Source software, something most other Linux vendors failed to do or even understand, made it possible to hire lots of software engineers, and pay lawyers to defend Linux from the barrage of constant patent lawsuits Linux faced. Remember the SCO case? And while IBM lawyers played a role in that too, IBM was only involved because RH had made Linux enterprise ready.
Here is an old statistic from 2007 that shows how much of the Linux kernel that is written by RH.
http://www.cnet.com/news/who-w...
The pattern have been like this more or less since the late 1990's.
Same with other core Linux projects like gcc, kernel utils, glibc, etc. Take a look of this incomplete list:
http://fedoraproject.org/wiki/...
Most other Linux distros are thriving in the slipstream of the development made by Red Hat in all core aspects of Linux as an OS.
There's NOTHING wrong with script files.
Using script files to setup and manage daemons because init is so primitive like SysVinit is, is simply a bad idea.
Mixing executable code and declarative config statements like script based init systems do, is simply indefensible; it makes it hard to parse for both humans and machines.
No one would ever design an init-system these days that didn't use pure text files for daemon config. SysVinit and similar are relics from a time when computing was done in a completely different way than today.
I am not trying to be disrespectful here for the pioneers that made various OS's back in the 1960's, 1970's and 1980's. It is just that some of the design choices they made, reflected the contemporary problems they had.
They made some simple but very flexible init systems based on shell scripts. But the simplicity just showed all kinds of problems over to the user space developer side, like handling dropping privileges when a daemon needed a low number port etc. And many people, including me, have long been of the opinion that such init-systems have been obsolete for years (if not decades). Most if not all certified Unix vendors have replaced their script based init systems (SMF and launchd are major inspiration init systems for systemd).
As I've said elsewhere in this thread you are failing to understand good overall system design and factoring if you think a large complex program that incorporates every behavior into itself and puts only configuration options into files is 'superior'.
I do think I understand enough about how OS's work to have a qualified opinion. We just happen to disagree about some things and is having a civilized exchange of arguments.
The core of systemd is certainly a lot more complex than SysVinit and similar, and the complexity isn't avoided by using SysVinit; it is just moved into other external programs.
systemd it isn't large, and all core daemons are really lightweight when it comes to memory/cpu and other resources.
A better solution would be individual scripts which can perform all the functions required for each service and coordinate with each other, with all the commonalities between them pulled out into shared library code. This allows for any level of flexibility and initialization strategy a packager or developer requires without forcing anyone to do anything and avoiding large disruptive changes in key subsystems.
I am really not interested in whether or not you understand the Unix way of doing things, but it is a real and highly beneficial approach which you might do well to actually understand. I don't have a big issue with a lot of the functionality that we're talking about here, though I think you are very much oversold on binary logging, but it doesn't all need to be bundled together in one package that is in any practical sense impossible to incorporate what you want from without being forced to swallow the whole thing.
Sure, an improved "Super" SysVinit would have been easier to deal with for many. Upstart was one such attempt. But the problems with making such an improved script based init system is harder than it appears; Why should upstream support it, if it breaks compatibility or just have small improvements? Changing how everything works for a small gain will mean little traction for such a project, which again will mean little support from upstream projects.
What makes systemd so attractive for upstream projects is, that while it changes things a lot, it also really help upstream projects in many ways by making a cross distro compatibility layer, providing needed low level functions like logind, and by simplifying daemon development and daemon configs. I am aware that you think systemd provides no benefit for your user case; fair enough, but it is a mistake to think other people doesn't have other user cases where systemd is a huge improvement over existing solutions.
This is forced on me when I don't need or want it for exactly what reason that you can explain? If I want binary logging there are already solutions, which you have JUST NAMED which work fine. I've no need or interest in having an init system that is too big for its britches foisting another one on me. Compartmentalization IS important.
Well, you can just use a non-systemd Linux distro like Slackware. It is a nice, stable and conservative distro. So nobody is forced to use systemd on Linux if they don't want to.
But if you want to use a systemd distro, it is no problem to _only_ have flat file text logs. Just configure journald not to make any log files and forward all messages to rsyslog.
systemd doesn't force you to use its binary log files at all, and you can still use rsyslog just the way you always had. This is all in the systemd documentation and man pages.
Personally I think the reaction against binary log files is based on a lack of actual analysis and lack of experience with them. The journal files is seriously good stuff for any admin.
Same with systemd; there is too much blatantly misinformation about systemd going on, with people rejecting it with weak and feeble arguments like "Unix Philosophy" etc. Trying to make a virtue out of the fact that SysVinit is crude, simple and lacks basic functionality, isn't going to convince people who have tried the advantages of systemd.
Sure, SysVinit is "simple", but only because it puts the burden and complexity on each and every program using it; daemonization, dropping privileges after getting a low number port etc. are all implemented in each and every user space program, instead of just having a single code base in init.
Having often complex executable config files where code and config statements are mixed, is simply a bad idea. Of course a daemon should be configured with structured text files like systemd uses. Using scripts for config files is just a madness that have been so normalized that the victims no longer recognize it as madness.