There isn't a "revoke privileges" kernel feature either despite years of trying (it is a hard problem).
You can't do it through a capabilities interface, even?
No, it is different from dropping privileges. Here is a short explanation. In this case the user case is being able to use revoke on devices: https://lwn.net/Articles/54653...
The Linux kernel simply have limitations when it comes to device handling, especially when it comes to security.
That means userspace have to have a sophisticated session manager like logind with kernel integration in order to keep the multi-seat sessions safe.
Why would it need to be married to the init daemon? That's the part that's unclear. cgroups permit management of process groups no matter how, why, or when they were created, or who created them. It doesn't matter if init starts the process, any other daemon could have done that job.
Because cgroups track all processes that are initiated, this is why systemd can track and kill all processes and its subprocesses reliably. It also provides process isolation needed for security (and user sessions). Cgroups is therefore extremely tightly integrated into the systemd-daemon.
Here is a quote from the mailing list where Poettering explains:
"Well, logind talks to systemd to manage user sessions and user processes in cgroups. That's why it depends on systemd. And since only systemd implements that, we couldn't even support anything else even if we wanted." http://lists.freedesktop.org/a...
Things will get even more complicated with the new cgroup API, since that only allows one "writer" on the system, and that writer is supposed to abstract away the low level API so it doesn't expose "kernel knobs" anymore.
There are also the usual reasons for why it really can be limiting to freeze internal API's, and over the time some stuff have moved into "logind" and other stuff out, which wouldn't have been possible if the API had been frozen.
But as said, even if the API was frozen, logind would still require session and cgroups management, and nothing outside systemd really provides that.
systemd really provides a lot of external API's that are frozen and stable, but logind isn't one of them.
Personally I don't see the need either. It has been quite clear for years that the non-systemd distros needed to develop and maintain their own software stack. Both Gnome and KDE developers have repeatedly pleaded for this over the years.
OpenRC already exists, does everything we want it to do and (more importantly) nothing we *don't* want it to do.
Well, it is good to know that OpenRC is "finished" and won't get any new features in the future. Of course parallel boot have been inherently broken on OpenRC for the last 4 years which is why it isn't default and marked "experimental" and still no fix in sight. But who boots their pc anyway, or need service management, or OS containers, or....
As such our superior knowledge can be spent in direct and vocal opposition to systemd because everything it claims to solve are issues none of its opponents consider to be actual problems.
You are just a tiny minority that have been kicked out of all major Linux distros. In the near future 80-90% of all new Linux installations will be systemd based; from supercomputers, smartphones, IVI and other embedded, to desktops and servers.
Being toxic assholes thread jumping every systemd-thread will at best only get you a shrug from the grown ups that actually make Linux software, while at worst, upstream projects may quickly find a good excuse to dump non-systemd support.
Since the anti-systemd crowd have scared away almost all Linux developers and aren't endearing themselves to upstream projects either, and have been kicked out of all major distros, maybe it is time for a little self reflection on why you lot have lost all the battles and the war too?
Maybe spewing hate against systemd isn't a winning tactic? Maybe it was a bad idea from the start and even worse now that you have to beg for mercy in order to have your non-systemd distros supported from upstream in the future?
You lot have radicalized yourself into an extreme and negative position, so please understand if the rest of the Linux community start to give you the cold shoulder.
restarting process / containers and counting processes as servers but claiming to not reboot is cheating.
If you call a container a server and restart the container process you rebooted it. If you count processes as servers... well... its not.
At no point did they restart any OS containers or even physical servers, only the affected services. That meant all other services where available for their customers the whole time. Even for socket activated services that used SSL, connections where available all the time thanks to systemd buffering request on the socket.
They don't call processes "servers", since they run OS containers, not Google style process containers, so each OS containers have a number of running processes. Yeah, "container" can mean a lot of things.
Wow fanboy, is there anything Lennart can't do? Is there anything he touches that isn't "brilliant?"
I think the point is that he undeniable have a extremely successful Linux developer career and have now designed and implemented three major Linux subsystems of considerably complexity that is used on all major Linux distros. He really tackled extremely difficult problems head on and actually solved them.
The way he enabled systemd to be backwards compatible while still making radical changes in functionality is worth a close study for every developer group that wants their software adopted in Linux. No "flag day" at all.
All in all I would say his ability to design and architect software and being a project leader is way, way above average, and pretty much proven by his track record.
Here is an example you should be able to understand, though. Your response will show whether you blindly worship at the feet of systemd devs, or if you are capable of thinking. As you know, there were some problems with cron, it didn't handle sleep very well, for example. When you have that problem, is the answer to rewrite cron completely, or to fix cron?
You can't fix cron on Linux, this is why its core problems haven't been solved for +10-15 years. The reasons for this fossilization of an important part of the Linux plumbing system are the usual:
1. The lack of upstream: There is no upstream "cron" developer group that fixes bugs or take RFE's.
2. The recursive problem: "cron" is a collection of fragmented projects often almost abandon ware, bound together with some ancient syntax and a little Posix compliance. If you deviate from that, you new cron version won't be backwards compatible so developers/projects won't support it and distros won't use it.
3. The lack of coordination: There is no or very little cooperation between Linux distros. There are no central decision makers in Linux, that can work towards deprecation of obsolete standards and plan new ones. The latter has its upsides too, but it does mean that sometimes things can't be changed in Linux. In this case working towards a modern cron, even if it meant it wasn't completely backwards compatible.
4. Legacy setups: Deviate from classic cron and userland legacy programs and their work flow may break. Paying customers don't like that, and it means userland won't ship with any cron scripts that uses the new features.
Sure, you can make "cron-like" programs like fcron that fixes some of the problems. But first, it isn't cron, only cron-like, so lots of people will reject it. While it works on many distro's, AFAIK, it isn't default on many. In short, fcron and similar solutions will suffer from the 4 points above. No upstream project can ship a daemon with fcron-specfic scripts.
Another thing is that even improvements of cron tends just to be basic improvements of the most glaring errors. Forget for a moment the archaic "crontabs" behavior and similar: Why can't I schedule cron jobs based on inotify detecting a file change? Or when a certain disk is attached, or schedule a program _not_ to run if certain conditions are met like battery level, another program is running, a certain error-message is written in the log, or similar conditional and non-calendar based scheduling?
"cron" is based on certain assumption like calendar/time scheduling. At what point can you extent cron so it adopts new concepts while still being cron? That is the problem, because you really can't; if you fix cron, it won't be cron anymore. "cron" on Linux have for all intents and purposes been fossilized into a state from which it can never really change.
And actually no need for any development, as it is finished and works reliably. Apparently, systemd fanatics do not understand these concepts. But how could they, none of either is to be found in the object of their worship.
I think your attitude is rather typical for a segment of systemd-opponents that takes refuge in denial. But good for you that you think the non-systemd Linux stack doesn't need any developers, technology progress and new code, because that is exactly what that attitude is getting you.
So have I......so what? When Poettering writes straight code, it's pretty good. I would be happy to have him as a coworker. The problem is when he starts architecting, that's where he lacks skill. He would be wise to read some basic documents on the topic.
You will find he has read all the classic Unix books, and unlike most others actually studied Unix variants and Unix code beside Linux.
All the systemd tools are made with regards to classic Unix philosophy, they only do one thing and they do it it well, they aren't chatty when scripted, doesn't report success (error code 0) as default, aren't interactive, etc. You often see Poettering quoting directly or indirectly from Ken Thomson et al. on the systemd mailing list. systemd closely follows classic Unix tradition where it actually makes sense.
You are severely underestimating his abilities; making a program like Pulseaudio, a middle-ware layer between the kernel/ALSA stack and userspace, was insanely difficult, but an instant success that solved many real world problems that especially DE developers had, and that made it default on all major Linux distros early on.
Yeah, I know some people likes to claim that PA doesn't work on their broken distro, but the fact is that no one has ever even tried to replicate what PA does, even now where all the ALSA/kernel driver bugs have been shaken out.
The fact is that PA was both well done and brilliantly pulled off. And it wasn't a "lets rewrite everything from scratch, including every sound card driver in the kernel" solution, but a solution that maximized existing work and with a smooth transition with no "flag day".
Same with systemd; using Fedora the transition from Upstart to systemd was really smooth; no "flag day" where either only systemd or sysvinit scripts worked, all the usual commands like telinit or "shutdown -h now" still worked, and all the SysVinit scripts worked too. It really is impressive how smooth the technical transition to systemd went on RHEL, Fedora, Suse, Arch and Debian, despite it replacing several different init-systems and rather different environments.
Then sometimes he makes amusing rookiemistakes. So that's where he is as a programmer: good code, poor design.
systemd is really portable across architectures, which is the important bit for Linux. That you can't easily port it to BSD is totally irrelevant : systemd is GPL/LGPL so it can't be close sourced and therefore it will never be adopted by BSD since close sourcing software is what pays their developers.
Anyway, you can't port BSD system software to directly Linux either; it isn't made that way, neither are official system software from Unices like Solaris. The "Unix wars" are over; Linux and Open source won, the proprietary Unices have been delegated to tiny niche domains. It makes no sense whatsoever to make systemd portable to SCO Unix, or AIX.
I saw an interesting comment from Poettering regarding OpenSSL code pre-Heartbleed; he found it abysmal. And it is exactly "Heartbleed" style bugs they want to avoid, where someone drops a turd of a patch into the repo that circumvent security measures, just so some proprietary close source Unix can avoid upgrading its libraries.
Anyway, I think you are severely underestimating his abilities as software architect; he has at least 3 major projects under his belt that now all are part of every major Linux distro. Two of those projects so inherently hard that many developers had given up trying to solve the problems.
SysVinit style scripts will hang around for at least a decade more.
Enterprise systemd adaptation will probably be slow in the beginning. Still, it is interesting that RHEL 7.2 will be rebased on systemd 219 simply because customers are demanding newer OS container support and systemd networking.
While some shops never upgrade (I once found a MicroSoft Xenix (Unix) server at a customer a decade after it was deprecated), I think systemd's security features and OS container technology will make it dominate every aspect of the future enterprise market.
My advice to you is to stop running with the anti-systemd pack; they won't help pay your bills if getting a new job is difficult because your skills are outdated, and since 100% of all commercial distros are going systemd, that is core skill to master.
I can read code. When systemd writes good code, I'll support it.
Don't give me that crap; the systemd developers are proficient and experienced Linux developers. Poettering has a CS degree and has coded Linux for +10 years now, he really knows his stuff. I have yet to see a single named OSS developer with the proper domain knowledge saying systemd is badly coded. What the systemd developers are doing is seriously hardcore too, from OS containers to session management. Btw, if you are looking for code documentation, don't just stare at the code, read the man pages too (like man sd_notify) and the systemd homepage too; it also contains developer information.
As I said, I have seen many people commit professional suicide before, refusing to learn new stuff. I guess people burn out and wants to stop the world.
Not studying systemd is simply professional suicide when it comes to Linux. Sure there will be SysVinit/Upstart gigs for years to come, but the choices will be fewer, the pay lower for every year, and suddenly you are out of work and have no experience with modern Linux management or development. Good luck telling the prospective employer at a job interview, that you "refuse to learn systemd, because you don't like the coding style/Once read a blog post claiming it wasn't designed the Unix way etc."
ok, so now I'm interested. You are clearly a strong proponent of systemd (some might even say 'fanboy'). What is it about systemd that you like so much? What are the features that really help you? What inspires your advocacy?
Not really a fan boy. Actually I don't care at all what other people use as init-system. I am cool with Slackware going their own way, and I respect P. Volkerding's Linux vision, even though it isn't the same as mine.
The main reasons why I am going into the systemd debate was that I frankly was tired of all the stupid misinformation spread about it. Some of it deliberate lies, but most often it is misinformation copied from some swivel-eyed loony and then repeated again and again until people take it as truth.
My favorite example on this was the often repeated claim that Gnome had "hard dependencies on systemd" and these where "pushed/forced" into Gnome by Poettering. Just because Gnome support systemd for session management, doesn't mean it can't support an alternative too.
And in fact, Gnome did exactly that, despite that ConsolKit was dead and unsupported upstreams, they still supported it years afterwards, while pleading on various blogs and mailing lists (including Debian's) that some should either maintain CK or make an alternative. Nobody did that and the non-systemd camp can only blame themselves for that.
Perhaps one of the reasons why nobody started to make an alternative could be that so many people claimed that Gnome had hard dependencies on systemd, making it look like Gnome only cared for systemd support, so why bother. A self fulfilling prophecy.
I have been a Linux user since Slackware came on 40 floppies. I like Linux, I like the technical progress it has experienced since, and I actually remember technical discussions before year 2000 on the problems with SysVinit, and syslog and the lack of coordination of the Linux plumbing layer.
To me systemd was an answer to my prayers with what I didn't like with Linux: SysVinit (it is only simple when doing simple things, and it is only simple because it outsources complexities into daemons etc, the complexities are still there.), service management; new and inconsistent tools among each distro, and lets not forget the time wasted on grafting some service management system on top. Logging too. I had high hopes for Rsyslog when they started in 2005, and while I really respect their work, they didn't solve several of the problems they set out to solve (perhaps not incidentally many of the same problems systemd have actually solved). The reason wasn't lack of will, but total lack of coordination in Linux between userland, the OS layer (where Rsyslog belongs) and kernel.
I have always played with new tech, including ones I didn't have a need for at the moment. So when systemd came out, I actually sat down one afternoon and just started to read, and read the documentation. I then started to play around with it. It really convinced me how good systemd was, and how much potential it has.
systemd is different, and it really does require some serious studying in order to use it. You just can't wing it, even if you have loads SysVinit/Upstart experience.
There are several technical things I like about systemd and I find superior to similar solutions, especially security. But perhaps what I really like about _using_ systemd is how much the developers care for the end users. It is in the small details like awesome bash-completion, sane defaults, how everything us documented in the man-pages, there is even a manpage containing a list of all the systemd man-pages (man systemd.index ) and a reverse list of every file, config option, CLI option etc (man systemd.directives) and overview pages like "man bootup" that shows and explain the boot process. And the way they abstract away all the difficult bits into simple declarative statements that goes into structured text files. And tools like "systemd-delta" that instantly gives an overview of changed service files.
On the other hand, I keep hearing that systems administrators who use cloud services and are thus "administering" umpty-hojillions of "machines" enjoy systemd because reasons, but I never see a citation for that, either.
"Spotify", the music streaming service directly voiced their support for systemd on the Debian mailing list when they discussed switching to systemd. https://lists.debian.org/debia... Spotify have doubled the number of paying customers to 20 million (75 million users in total) since then.
Here is how they used systemd to patch Heartbleed without rebooting (they were running 5000 nginx instances on one box): https://pantheon.io/blog/how-w...
And for people who don't follow every distribution's MLs, systemd sort of snuck up on us. We didn't imagine that debian would convert to systemd, for fuck's sake. Statistically nobody even imagined that until it was happening. Who would have ever thought that the one time Debian moved quickly on something, it would be something contentious?
Debian was an early systemd adopter, it just wasn't the default init-system.
I think it was pretty clear that SysVinit was dead years ago (last I looked they haven't released for 5 years, probably because the developers doesn't even have a build and test system, so only way to test a patch is to boot with it. RH and later Debian had been defacto Upstream for SysVinit for years).
Upstart was never going to be an option for Debian as long as Canonical insisted on the CLA. This left systemd as the only serious and mature init-system and Debian developers had long worked towards it being the new default init-system when some people suddenly started to make noise about it, which lead to the CTTE decision, which lead to the GR that showed how overwhelming the systemd support was among Debian Developers.
The point is that Debian had long been on its way to become a systemd distro, what the Debian Developers decided on the GR was to keep status quo and continue to work towards systemd. It was never a sudden decision, it had been years in the making.
I wonder which Berlin is in November? I've never been there myself.
Berlin is always worth a visit. Late November in German cities are nice, since you will find small booths selling "Glühwein" and various food (like sausages) everywhere. While Berlin is nice in the summer with its biergartens, trees and sailing on the Spree, they have top notch museums too, like everything in the "museumsinsel/ Museum Island".
You simply can't get the same features such as multi-seat without such integration.
There was multi-seat X before there was systemd. How can it be that you can't have multi-seat without such integration?
multi-seat X haven't worked securely for decades. The main problem is actual in the Linux kernel, especially the way it handles devices in a multi-user environment. That is the same reason that while it has been possible to run root-less X on Linux for many years, it wasn't safe in a multi-user environment until systemd made it possible. There isn't a "revoke privileges" kernel feature either despite years of trying (it is a hard problem).
That means userspace have to have a sophisticated session manager like logind with kernel integration in order to keep the multi-seat sessions safe.
There are no good technical reasons. Having a window manager depend on a particular startup manager is poor design, there's no way around that.
The DE's really do depend on the OS layers below, there is no way around that. And systemd is exactly such an OS layer, or plumbing system if you like. It is exactly meant to provide service to userland programs like Gnome/KDE/LXQt. And having multi-seat capabilites and proper session management really require deep OS integration like cgroups.
It is poor design _not_ to provide such a unified and coherent OS layer for userland.
I discuss that here. If you think I am misinformed, I will look into it more deeply.
You are. Check out CK2, or the history of Ubuntu's shim. It was originally Canonical who was handed over the CK project, but they apparently thought the same as the CK2 maintainer, that the CK API sucked and Poettering's logind API didn't, and therefore cloned it into "systemd-shim" instead.
Sure, none of the API alternatives are full replacements since that would require a level of kernel and system integration only systemd provides, so no multi-seat etc. But the latest I read from Gnome's Olav Vitter's was that they would try to support the subset of features that the alternatives could support. So in the future Gnome will support the systemd-API, not the CK API, just like CK2, systemBSD's logind etc does.
The latter of course depend on somebody doing some actual work instead of just complaining or spreading misinformation.
it also solves the problem with fossilized development of subsystems like init and logging,
Not a problem, and also not actually a thing. Several competing init systems which didn't bring baggage with them already existed, but Lennart is a real NIH kind of guy so he didn't start with one of those. Stable init and log daemons are features, not bugs.
Yes, it is a "thing". The problem with the fossilization of the Linux plumbing layer meant that crucial progress was being held back. All the init-systems in use at the time where just "slightly improved SysVinit" style init-systems. They all relied on executable config scripts to manage daemons, and none of them tried to step up an take proper responsibility for the boot and init process. Upstart was a nice pioneering effort, but not a good solution as it were. But there are still other problems; crond fx. Why can't it handle hibernation properly? Probably because it was made when Unix servers where hand grafted out of shell scripts an always on. But there is no "cron" upstream developer group that takes RFE's, and no coordination between the many fragmented crond forks and userland developers, making all new development practically impossible. It would have been freaking nice if crond could have been dragged into the modern world 10-15 years ago, but as of now, we have to use crond+at+whatever instead.
systemd, as init and process manager, actually takes on the coordination responsibility that lacked previously. It is way cool how "namespace" isolation and kernel Capabilities(7) are integrated
You do realize that cgroups is a thing you diddle with very small commandline programs, right?
You are probably thinking of the old cgroups interface, but that is being deprecated in the near future in favor of the "single writer"/"unified hierarchy" that requires a writer that abstract away the kernel cgroup API so userland doesn't use it directly. http://www.linuxfoundation.org...
The point is that system already comes with such an abstraction layer for capabilities, namespaces and cgroups, making it trivially easy for the admin to harness their power without coding, by simply setting the value "ProtectSystem=true" in the service file, or using similar features (see man systemd.exec). Better yet, distro maintainers can lock down the daemon per default, giving "out-of-the-box" security.
There is nothing else that even comes close to the power of systemd when it comes to such security integration. The systemd security framework for these kernel technologies are not only easy for humans to read and understand, but it is machine parsable and scalable too.
To my knowledge nobody in the non-systemd camp is even working on similar ideas, or even on an alternative cgroups single writer implementation.
Not tying it to a specific log daemon is the really important part, though!
Which is _exactly_ what journald _doesn't_! You can use it together with any "syslog(3)" daemon. So if you have a legacy setup, you can use with journald and it will even enhance it by providing logging info syslog normally can't get.
Yes it does. You can't separate logind from systemd (although that would be good software engineering, if they were separable). The systemd-logind API is deeply integrated into systemd. It shouldn't be, but it is.
You are misinformed. CK2 and systemd-shim are alternative implementations of the systemd-logind API (or at least the subset of the API Gnome/KDE actually need). The CK2 developers abandoned the old CK API in favor of the systemd API, simply because the systemd-logind API developed by Lennart Poettering is much nicer
There are actual good technical reasons why systemd is made like it is and why systemd-logind is part of the systemd project. You simply can't get the same features such as multi-seat without such integration.
The problem seems to be that you didn't read any of my posts that I linked to earlier. From what you've written, it doesn't even seem like you understand systemd very well. Yet somehow you are a huge proponent of systemd. I don't know. What do you like about it? That's a serious question.
systemd is a massive security increase compared to any other init-system out there, simple because it integrates Namespace isolation, Cgroups and Capabilities(7).
Daemon service files are in structured text format, instead of spaghetti code in executable files like Sysvinit/OpenRC.
Daemon service management vastly superior to anything else on Linux/Unix.
Non-systemd development is at a standstill, with only a tiny handful part time developers left. No coordination, no conferences, no capital investment, no nothing. Having a toxic community doesn't attract developers.
>* Scope creep (there is no reason Gnome should depend on systemd).
Gnome doesn't depend on systemd as such, but on the systemd-logind API. Until recently (perhaps it still does) it also supported the old ConsolKit API as alternative even though CK had been dead for +1½ year with no upstream bug fixing or security support, and no one bothered to maintain it anyway.
The problem seems to be that the systemd-opponents really don't understand how Open Source software works and being developed, something that requires coordination, and positive contributions with either code, documentation, or money.
Claiming that the systemd developers are incompetent and doesn't understand software development will get you nowhere. You have to employ your superior knowledge into actual competing projects in order to be taken seriously. But that is the problem isn't it? The total lack of effort by the systemd-opponents to actually create something useful.
You could refute that trivially by clearly stating what problem it actually solves. Yet you chose not to do that.
systemd solves many old Linux problems; besides the technical ones like proper service management, it also solves the problem with fossilized development of subsystems like init and logging, and solves the old problem of lack of coordination between userland, kernel space, and the plumbing layer between.
systemd, as init and process manager, actually takes on the coordination responsibility that lacked previously. It is way cool how "namespace" isolation and kernel Capabilities(7) are integrated so system admins can turn on such security features just by adding a Boolean value in a text file. It also means that every iteration of systemd distros become ever more hardened per default, making ever more difficult for the the black hats to gain privilege escalation.
By dismissing every systemd feature and everything systemd does as "bad", systemd-opponents like you paint yourself and all your fellow travelers into an ever smaller corner, where "SysVinit/OpenRC" is the pinnacle of evolution without ever needing more features.
If a startup management subsystem needs its own conference, it is doing too much.
Sure, all progress is bad; Linux should be a 1986 Unix clone, there should be no new code blah blah blah.
There is nothing wrong with open source developers meeting up, talk and code. You probably agree to that, but your irrational emotionally driven hatred to systemd makes you post snarky remarks like the above.
What is really funny though, is that you systemd-opponents never realized how your hurt your own cause by negative campaigning; You are trying to "poison the systemd well", but you end up poisoning your own well too; From now on, the non-systemd developers can't make a conference working for non-systemd init-systems, because according to you, it isn't needed.
You guys are dragging yourself down with all the negative attitudes towards developers making progress.
It highlights an important problem: the Debian project has been making one truly bad decision after another recently.
We all know about Debian's systemd disaster. It was an absolutely stupid move that seriously divided the Debian community, and forced many of its best users over to the BSDs and other OSes.
SPARC support was killed because there where no developers to maintain it. Debian doesn't have fat support contracts that enables the project to hire developers to support legacy architectures. So if a software project/package/architecture isn't supported by developers so that bugs get fixed, it will be killed off.
systemd was widely welcomed by almost all Debian developers and the vast majority of Debian end-users. There was a lot of noise of the Debian mailing lists when the decision was made, but it turned out that the tiny minority of systemd-opponents couldn't even muster 5 Debian Developers to sponsor a GR to overturn that decision.
They also pretty much killed Debian GNU/kFreeBSD near the end of last year.
Again, look at the Debian mailing list. There where practically zero Debian GNU/kFreeBSD developers active, meaning that bugs didn't get fixed, even release blocker bugs. Even Debian GNU/Hurd was a vibrating developer hub compared to kFreeBSD and probably had many more end users too.
If you want something in the open source world, you will have to contribute towards it, either by code, bug reports, translations/documentation or money. Both the SPARC architecture and kFreeBSD failed to receive enough of such support to survive.
Notice that Debian will continue to support SPARC on existing pre-Jessie SPARC releases, just not on future ones.
Your first statement is factually incorrect, as the trend of "sane energy policy equals cheap energy prices" is easily visible in other states. Finland for example has a large installed nuclear capacity in addition to having hydro pretty much everywhere where it's easy enough to install, while having minimal "not yet ready" renewables installation. Energy is cheap.
Compare to Denmark which went full out on wind power and shut down the burner plants. Energy price astronomically high.
Notably, this is also seen in heavy industry. While Germany, realising what Energiewende would do to their heavy industry opted to subsidise heavy industry and let the rest bear the burden. Results were well documented.
Sure, the German industry largely avoid the infrastructure investment tax (energy tax) that the German consumers pay, unlike Denmark. But the fact is that German and Danish consumers are paying up front for the building of renewable energy sources and new transmission networks and other infrastructure. On top of that, Denmark have always had a high energy tax on top of the sales tax, simply because they historically didn't have energy sources like hydro or coal, but had to import everything.
Again, again, again, the EU electricity end prices for consumers heavily depend on the members states tax levels. Eg. If country A has a sales tax of 15% and country B has a sales tax of 25%, then the electricity prices will be higher in country B. And that may be true, even if production cost per megawatt is lower in country B.
The redeeming thing about doing it that way is that the taxpayers doesn't pay for such subsidies like they do in France; if you save on electricity, you save money in both Denmark and Germany. French taxpayers don't get a lesser tax bill on their wages if they save electricity.
This is exactly one of the problems the French government wants to solve; until now French nuclear power plant operators enjoyed a "feed tarif". That meant for every Megawatt produced, they would get money from the french taxpayers. No wonder France exported a lot of energy; the French taxpayers subsidized every megawatt sold. So even if the nuclear plant produced electricity at above market prices, the French taxpayers would make it profitable for the plant operators to export energy.
BTW, the latest Finish nuclear power plant (EPR reactor) is a poster child for what is wrong with nuclear power from an economic angle; The "Olkiluoto 3" plant is almost a decade late since construction started and at least twice the price. And that estimate depends on that Areva/EDF actually for the first time are right that it may come online in 2018. Every other such prediction have failed the last many years.
The good news for the Finish consumers is that it is the French taxpayers who are funding this gigantic money-losing construction nightmare. The Finns have also just recently canceled the "Olkiluoto 4" nuclear power plant. Probably as lucky escape for the French taxpayers they did that.
Rest of your argument is frankly inane to the extreme and could only be argued by someone utterly ignorant of reality of strategic sectors and how they are protected. Energy, food production, water and so on are strategic sectors required for existence of a functioning state. As a result they are heavily regulated and subsidized to ensure their seamless functionality regardless of market forces. Arguing against this on "free market" basis is utterly inane simply because lack of these subsidies and regulation in the said sectors would cause societal collapse, as failures in these sectors would be strategic failures causing failures of state structures.
Your talk about "strategic sectors" is like hearing a industry lobbyist from the seventies; Really, are all US states totally independent energy markets and are self sustaining with food etc., or do they buy stuff across state borders if they need?
Right. Prices of electricity are magical, managed by overlords in their respective capitols. They have nothing to do with actual costs of production.
You are exaggerating what I say, and you still miss my point; You can't look at electricity prices in the EU and say whether they are below or above the production cost, nor can you interfere that production prices are high, just because the consumer prices are high.
To sum up again; French consumer electricity prices have been artificially low for decades, not because nuclear energy is cheap, but because French taxpayers are paying subsidies over their taxes, and because government regulation have kept prices under control. The latter have resulted in that EDF (mostly state owned) have been bleeding billions of Euros every year.
Again, read the Moody's statement.
In other news, did you remember that we live in a real world with limited resources, not one where electricity comes out of the socket?
P.S. Nuclear energy remains the cheapest energy source available to date per produced energy unit. That is why states that don't have to care for psychological bullshit pushed here in the West by people like you on their impressionable and ignorant public are investing heavily in them. Think China. Some of the best and toughest negotiators in the world, and people with some of the greatest power needs in the world. And they're massively investing in nuclear. If you were even close to reality with your "nuclear is expensive" claims, they simply wouldn't be doing it.
Only regimes where market forces plays no role, invest heavily in nuclear power. China and Russia don't care if the consumers are paying above market prices, because a free energy market doesn't exist in either place. They want nuclear power for other reasons than cheap energy, nuclear weapons to mention one thing.
There are no free market driven building of nuclear reactors, and it has been like that for the last last 20 years. All new reactors are heavily subsidized by local states. No private capital are willing to finance new nuclear power-plants unless the local government gives state guarantees for profitability simply because nuclear power is too expensive to generate profit.
It doesn't help that all new EU reactors build the last couple of decades have had extreme budget overruns, and all the promises about standardization and factory modules instead of on location construction have turned out to be false both when it came to realization, quality control and prices. So construction cost have skyrocketed too. In the meantime, competing energy sources have become ever more advanced, efficient and cheap.
If nuclear reactor technology doesn't gain significant technological progress soon, especially on cost, it will become ever more marginalized. That France is winding down its dependency on nuclear power really says it all.
How about no? Costs in Germany and Denmark are high because production is expensive. They have to both use very expensive forms of generation as well as buy foreign electricity (which means both paying for electricity and long range transfer across international exchange) to provide spinning reserve for it.
Germany and Denmark prices were much lower back when they were using cheaper forms of generation, such as nuclear.
And when talking about subsidies, you cannot miss the fact that German subsidies are far higher than anyone in Europe right now. And their price is still far higher than French.
Again, there is no relation between the production prices and consumer prices in the EU.
The German electricity prices are very high because Germany is investing heavily in new energy technology, most importantly the worlds most advanced electricity network so they can shuffle electricity around the country, like cheap wind energy from northern Germany to the south, or export, import or even transit electricity from around the EU.
It is the German electricity consumers who are paying for this investment through higher prices, while in France it is the _taxpayers_ who are funding the subsidization of the nuclear industry.
Take a look a Moody's downgrading of EDF stock (EDF owns most nuclear plants in France):
"The rating downgrade reflects the risks associated with the transition of EDF's French power generation and supply activities from a predominantly regulated cost-reflective tariff model towards an increasing exposure to market power prices. Moody's notes that this transition is happening at a time when market prices are low and below the regulated price for nuclear output." https://www.moodys.com/researc...
As can be seen, Moody's says nuclear power electricity production prices are higher than the market value. It therefore logical that they foresee problems when EDF is also facing a reduction in subsidies.
Nuclear power simply is much more expensive than natural gas, wind and solar power.
The French government have been heavily subsidizing the nuclear industry for decades, but the economic crisis and increasing EU competition makes such subsidies unfeasible in the long run.
That is why the present French government will wind down some of the nuclear industry, and start to invest more in cheaper energy sources like wind and solar. They are also trying to make consumers pay more in line of what the electricity actually cost to produce, and stop the nuclear industry from bleeding to death by accumulating debt like they do now. So even more price hikes are in sight for French consumers.
Are you perchance unaware of the fact that French electricity prices are among the LOWEST in Europe?
If you were even remotely correct with your claim, prices would surely be at least on AVERAGE level?
Please notice that there is a difference between consumer electricity prices and electricity production prices.
The French consumer electricity prices are low, not because the production prices are low, but because the prices are subsidized by taxpayers and because government regulation fixes the prices at an artificially low level.
Also, notice that some countries with high electricity prices, like Germany and Denmark, are putting high taxes on consumer electricity prices. The high prices doesn't reflect high production prices, only high taxation. So looking at consumer prices alone says very little of what electricity production prices are.
The fact is that the French nuclear industry are totally unable to compete on price with other European non-nuclear power, which is why it is so heavily subsidized; it would simply be bankrupted if it had to compete with EU production prices.
In the future there will be less subsidization in France, resulting in several announced double digit price hikes for the next couple of years for consumers.
Slashdot Mirror
There isn't a "revoke privileges" kernel feature either despite years of trying (it is a hard problem).
You can't do it through a capabilities interface, even?
No, it is different from dropping privileges. Here is a short explanation. In this case the user case is being able to use revoke on devices:
https://lwn.net/Articles/54653...
The Linux kernel simply have limitations when it comes to device handling, especially when it comes to security.
That means userspace have to have a sophisticated session manager like logind with kernel integration in order to keep the multi-seat sessions safe.
Why would it need to be married to the init daemon? That's the part that's unclear. cgroups permit management of process groups no matter how, why, or when they were created, or who created them. It doesn't matter if init starts the process, any other daemon could have done that job.
Because cgroups track all processes that are initiated, this is why systemd can track and kill all processes and its subprocesses reliably. It also provides process isolation needed for security (and user sessions).
Cgroups is therefore extremely tightly integrated into the systemd-daemon.
Here is a quote from the mailing list where Poettering explains:
"Well, logind talks to systemd to manage user sessions and user
processes in cgroups. That's why it depends on systemd. And since only systemd implements that, we couldn't even support anything else even if we wanted."
http://lists.freedesktop.org/a...
Things will get even more complicated with the new cgroup API, since that only allows one "writer" on the system, and that writer is supposed to abstract away the low level API so it doesn't expose "kernel knobs" anymore.
There are also the usual reasons for why it really can be limiting to freeze internal API's, and over the time some stuff have moved into "logind" and other stuff out, which wouldn't have been possible if the API had been frozen.
But as said, even if the API was frozen, logind would still require session and cgroups management, and nothing outside systemd really provides that.
systemd really provides a lot of external API's that are frozen and stable, but logind isn't one of them.
Personally I don't see the need either. It has been quite clear for years that the non-systemd distros needed to develop and maintain their own software stack. Both Gnome and KDE developers have repeatedly pleaded for this over the years.
OpenRC already exists, does everything we want it to do and (more importantly) nothing we *don't* want it to do.
Well, it is good to know that OpenRC is "finished" and won't get any new features in the future. Of course parallel boot have been inherently broken on OpenRC for the last 4 years which is why it isn't default and marked "experimental" and still no fix in sight. But who boots their pc anyway, or need service management, or OS containers, or ....
As such our superior knowledge can be spent in direct and vocal opposition to systemd because everything it claims to solve are issues none of its opponents consider to be actual problems.
You are just a tiny minority that have been kicked out of all major Linux distros. In the near future 80-90% of all new Linux installations will be systemd based; from supercomputers, smartphones, IVI and other embedded, to desktops and servers.
Being toxic assholes thread jumping every systemd-thread will at best only get you a shrug from the grown ups that actually make Linux software, while at worst, upstream projects may quickly find a good excuse to dump non-systemd support.
Since the anti-systemd crowd have scared away almost all Linux developers and aren't endearing themselves to upstream projects either, and have been kicked out of all major distros, maybe it is time for a little self reflection on why you lot have lost all the battles and the war too?
Maybe spewing hate against systemd isn't a winning tactic? Maybe it was a bad idea from the start and even worse now that you have to beg for mercy in order to have your non-systemd distros supported from upstream in the future?
You lot have radicalized yourself into an extreme and negative position, so please understand if the rest of the Linux community start to give you the cold shoulder.
restarting process / containers and counting processes as servers but claiming to not reboot is cheating.
If you call a container a server and restart the container process you rebooted it. If you count processes as servers... well... its not.
At no point did they restart any OS containers or even physical servers, only the affected services. That meant all other services where available for their customers the whole time. Even for socket activated services that used SSL, connections where available all the time thanks to systemd buffering request on the socket.
They don't call processes "servers", since they run OS containers, not Google style process containers, so each OS containers have a number of running processes. Yeah, "container" can mean a lot of things.
Wow fanboy, is there anything Lennart can't do? Is there anything he touches that isn't "brilliant?"
I think the point is that he undeniable have a extremely successful Linux developer career and have now designed and implemented three major Linux subsystems of considerably complexity that is used on all major Linux distros. He really tackled extremely difficult problems head on and actually solved them.
The way he enabled systemd to be backwards compatible while still making radical changes in functionality is worth a close study for every developer group that wants their software adopted in Linux. No "flag day" at all.
All in all I would say his ability to design and architect software and being a project leader is way, way above average, and pretty much proven by his track record.
Here is an example you should be able to understand, though. Your response will show whether you blindly worship at the feet of systemd devs, or if you are capable of thinking. As you know, there were some problems with cron, it didn't handle sleep very well, for example. When you have that problem, is the answer to rewrite cron completely, or to fix cron?
You can't fix cron on Linux, this is why its core problems haven't been solved for +10-15 years. The reasons for this fossilization of an important part of the Linux plumbing system are the usual:
1. The lack of upstream: There is no upstream "cron" developer group that fixes bugs or take RFE's.
2. The recursive problem: "cron" is a collection of fragmented projects often almost abandon ware, bound together with some ancient syntax and a little Posix compliance. If you deviate from that, you new cron version won't be backwards compatible so developers/projects won't support it and distros won't use it.
3. The lack of coordination: There is no or very little cooperation between Linux distros. There are no central decision makers in Linux, that can work towards deprecation of obsolete standards and plan new ones. The latter has its upsides too, but it does mean that sometimes things can't be changed in Linux. In this case working towards a modern cron, even if it meant it wasn't completely backwards compatible.
4. Legacy setups: Deviate from classic cron and userland legacy programs and their work flow may break. Paying customers don't like that, and it means userland won't ship with any cron scripts that uses the new features.
Sure, you can make "cron-like" programs like fcron that fixes some of the problems. But first, it isn't cron, only cron-like, so lots of people will reject it. While it works on many distro's, AFAIK, it isn't default on many. In short, fcron and similar solutions will suffer from the 4 points above. No upstream project can ship a daemon with fcron-specfic scripts.
Another thing is that even improvements of cron tends just to be basic improvements of the most glaring errors. Forget for a moment the archaic "crontabs" behavior and similar: Why can't I schedule cron jobs based on inotify detecting a file change? Or when a certain disk is attached, or schedule a program _not_ to run if certain conditions are met like battery level, another program is running, a certain error-message is written in the log, or similar conditional and non-calendar based scheduling?
"cron" is based on certain assumption like calendar/time scheduling. At what point can you extent cron so it adopts new concepts while still being cron? That is the problem, because you really can't; if you fix cron, it won't be cron anymore. "cron" on Linux have for all intents and purposes been fossilized into a state from which it can never really change.
And actually no need for any development, as it is finished and works reliably. Apparently, systemd fanatics do not understand these concepts. But how could they, none of either is to be found in the object of their worship.
I think your attitude is rather typical for a segment of systemd-opponents that takes refuge in denial.
But good for you that you think the non-systemd Linux stack doesn't need any developers, technology progress and new code, because that is exactly what that attitude is getting you.
So have I......so what? When Poettering writes straight code, it's pretty good. I would be happy to have him as a coworker. The problem is when he starts architecting, that's where he lacks skill. He would be wise to read some basic documents on the topic.
You will find he has read all the classic Unix books, and unlike most others actually studied Unix variants and Unix code beside Linux.
All the systemd tools are made with regards to classic Unix philosophy, they only do one thing and they do it it well, they aren't chatty when scripted, doesn't report success (error code 0) as default, aren't interactive, etc. You often see Poettering quoting directly or indirectly from Ken Thomson et al. on the systemd mailing list. systemd closely follows classic Unix tradition where it actually makes sense.
You are severely underestimating his abilities; making a program like Pulseaudio, a middle-ware layer between the kernel/ALSA stack and userspace, was insanely difficult, but an instant success that solved many real world problems that especially DE developers had, and that made it default on all major Linux distros early on.
Yeah, I know some people likes to claim that PA doesn't work on their broken distro, but the fact is that no one has ever even tried to replicate what PA does, even now where all the ALSA/kernel driver bugs have been shaken out.
The fact is that PA was both well done and brilliantly pulled off. And it wasn't a "lets rewrite everything from scratch, including every sound card driver in the kernel" solution, but a solution that maximized existing work and with a smooth transition with no "flag day".
Same with systemd; using Fedora the transition from Upstart to systemd was really smooth; no "flag day" where either only systemd or sysvinit scripts worked, all the usual commands like telinit or "shutdown -h now" still worked, and all the SysVinit scripts worked too.
It really is impressive how smooth the technical transition to systemd went on RHEL, Fedora, Suse, Arch and Debian, despite it replacing several different init-systems and rather different environments.
Then sometimes he makes amusing rookie mistakes. So that's where he is as a programmer: good code, poor design.
systemd is really portable across architectures, which is the important bit for Linux. That you can't easily port it to BSD is totally irrelevant : systemd is GPL/LGPL so it can't be close sourced and therefore it will never be adopted by BSD since close sourcing software is what pays their developers.
Anyway, you can't port BSD system software to directly Linux either; it isn't made that way, neither are official system software from Unices like Solaris. The "Unix wars" are over; Linux and Open source won, the proprietary Unices have been delegated to tiny niche domains. It makes no sense whatsoever to make systemd portable to SCO Unix, or AIX.
I saw an interesting comment from Poettering regarding OpenSSL code pre-Heartbleed; he found it abysmal. And it is exactly "Heartbleed" style bugs they want to avoid, where someone drops a turd of a patch into the repo that circumvent security measures, just so some proprietary close source Unix can avoid upgrading its libraries.
Anyway, I think you are severely underestimating his abilities as software architect; he has at least 3 major projects under his belt that now all are part of every major Linux distro. Two of those projects so inherently hard that many developers had given up trying to solve the problems.
SysVinit style scripts will hang around for at least a decade more.
Enterprise systemd adaptation will probably be slow in the beginning. Still, it is interesting that RHEL 7.2 will be rebased on systemd 219 simply because customers are demanding newer OS container support and systemd networking.
While some shops never upgrade (I once found a MicroSoft Xenix (Unix) server at a customer a decade after it was deprecated), I think systemd's security features and OS container technology will make it dominate every aspect of the future enterprise market.
My advice to you is to stop running with the anti-systemd pack; they won't help pay your bills if getting a new job is difficult because your skills are outdated, and since 100% of all commercial distros are going systemd, that is core skill to master.
I can read code. When systemd writes good code, I'll support it.
Don't give me that crap; the systemd developers are proficient and experienced Linux developers. Poettering has a CS degree and has coded Linux for +10 years now, he really knows his stuff. I have yet to see a single named OSS developer with the proper domain knowledge saying systemd is badly coded. What the systemd developers are doing is seriously hardcore too, from OS containers to session management. Btw, if you are looking for code documentation, don't just stare at the code, read the man pages too (like man sd_notify) and the systemd homepage too; it also contains developer information.
As I said, I have seen many people commit professional suicide before, refusing to learn new stuff. I guess people burn out and wants to stop the world.
Not studying systemd is simply professional suicide when it comes to Linux. Sure there will be SysVinit/Upstart gigs for years to come, but the choices will be fewer, the pay lower for every year, and suddenly you are out of work and have no experience with modern Linux management or development. Good luck telling the prospective employer at a job interview, that you "refuse to learn systemd, because you don't like the coding style/Once read a blog post claiming it wasn't designed the Unix way etc."
ok, so now I'm interested. You are clearly a strong proponent of systemd (some might even say 'fanboy'). What is it about systemd that you like so much? What are the features that really help you? What inspires your advocacy?
Not really a fan boy. Actually I don't care at all what other people use as init-system. I am cool with Slackware going their own way, and I respect P. Volkerding's Linux vision, even though it isn't the same as mine.
The main reasons why I am going into the systemd debate was that I frankly was tired of all the stupid misinformation spread about it. Some of it deliberate lies, but most often it is misinformation copied from some swivel-eyed loony and then repeated again and again until people take it as truth.
My favorite example on this was the often repeated claim that Gnome had "hard dependencies on systemd" and these where "pushed/forced" into Gnome by Poettering. Just because Gnome support systemd for session management, doesn't mean it can't support an alternative too.
And in fact, Gnome did exactly that, despite that ConsolKit was dead and unsupported upstreams, they still supported it years afterwards, while pleading on various blogs and mailing lists (including Debian's) that some should either maintain CK or make an alternative. Nobody did that and the non-systemd camp can only blame themselves for that.
Perhaps one of the reasons why nobody started to make an alternative could be that so many people claimed that Gnome had hard dependencies on systemd, making it look like Gnome only cared for systemd support, so why bother. A self fulfilling prophecy.
I have been a Linux user since Slackware came on 40 floppies. I like Linux, I like the technical progress it has experienced since, and I actually remember technical discussions before year 2000 on the problems with SysVinit, and syslog and the lack of coordination of the Linux plumbing layer.
To me systemd was an answer to my prayers with what I didn't like with Linux: SysVinit (it is only simple when doing simple things, and it is only simple because it outsources complexities into daemons etc, the complexities are still there.), service management; new and inconsistent tools among each distro, and lets not forget the time wasted on grafting some service management system on top. Logging too. I had high hopes for Rsyslog when they started in 2005, and while I really respect their work, they didn't solve several of the problems they set out to solve (perhaps not incidentally many of the same problems systemd have actually solved). The reason wasn't lack of will, but total lack of coordination in Linux between userland, the OS layer (where Rsyslog belongs) and kernel.
I have always played with new tech, including ones I didn't have a need for at the moment. So when systemd came out, I actually sat down one afternoon and just started to read, and read the documentation. I then started to play around with it. It really convinced me how good systemd was, and how much potential it has.
systemd is different, and it really does require some serious studying in order to use it. You just can't wing it, even if you have loads SysVinit/Upstart experience.
There are several technical things I like about systemd and I find superior to similar solutions, especially security. But perhaps what I really like about _using_ systemd is how much the developers care for the end users. It is in the small details like awesome bash-completion, sane defaults, how everything us documented in the man-pages, there is even a manpage containing a list of all the systemd man-pages (man systemd.index ) and a reverse list of every file, config option, CLI option etc (man systemd.directives) and overview pages like "man bootup" that shows and explain the boot process. And the way they abstract away all the difficult bits into simple declarative statements that goes into structured text files. And tools like "systemd-delta" that instantly gives an overview of changed service files.
On the other hand, I keep hearing that systems administrators who use cloud services and are thus "administering" umpty-hojillions of "machines" enjoy systemd because reasons, but I never see a citation for that, either.
"Spotify", the music streaming service directly voiced their support for systemd on the Debian mailing list when they discussed switching to systemd.
https://lists.debian.org/debia...
Spotify have doubled the number of paying customers to 20 million (75 million users in total) since then.
Pantheon were running 500.000 systemd units in 2013:
https://pantheon.io/blog/panth...
Here is how they used systemd to patch Heartbleed without rebooting (they were running 5000 nginx instances on one box):
https://pantheon.io/blog/how-w...
And for people who don't follow every distribution's MLs, systemd sort of snuck up on us. We didn't imagine that debian would convert to systemd, for fuck's sake. Statistically nobody even imagined that until it was happening. Who would have ever thought that the one time Debian moved quickly on something, it would be something contentious?
Debian was an early systemd adopter, it just wasn't the default init-system.
I think it was pretty clear that SysVinit was dead years ago (last I looked they haven't released for 5 years, probably because the developers doesn't even have a build and test system, so only way to test a patch is to boot with it. RH and later Debian had been defacto Upstream for SysVinit for years).
Upstart was never going to be an option for Debian as long as Canonical insisted on the CLA. This left systemd as the only serious and mature init-system and Debian developers had long worked towards it being the new default init-system when some people suddenly started to make noise about it, which lead to the CTTE decision, which lead to the GR that showed how overwhelming the systemd support was among Debian Developers.
The point is that Debian had long been on its way to become a systemd distro, what the Debian Developers decided on the GR was to keep status quo and continue to work towards systemd. It was never a sudden decision, it had been years in the making.
I wonder which Berlin is in November? I've never been there myself.
Berlin is always worth a visit. Late November in German cities are nice, since you will find small booths selling "Glühwein" and various food (like sausages) everywhere.
While Berlin is nice in the summer with its biergartens, trees and sailing on the Spree, they have top notch museums too, like everything in the "museumsinsel/ Museum Island".
You simply can't get the same features such as multi-seat without such integration.
There was multi-seat X before there was systemd. How can it be that you can't have multi-seat without such integration?
multi-seat X haven't worked securely for decades. The main problem is actual in the Linux kernel, especially the way it handles devices in a multi-user environment. That is the same reason that while it has been possible to run root-less X on Linux for many years, it wasn't safe in a multi-user environment until systemd made it possible.
There isn't a "revoke privileges" kernel feature either despite years of trying (it is a hard problem).
That means userspace have to have a sophisticated session manager like logind with kernel integration in order to keep the multi-seat sessions safe.
There are no good technical reasons. Having a window manager depend on a particular startup manager is poor design, there's no way around that.
The DE's really do depend on the OS layers below, there is no way around that. And systemd is exactly such an OS layer, or plumbing system if you like. It is exactly meant to provide service to userland programs like Gnome/KDE/LXQt. And having multi-seat capabilites and proper session management really require deep OS integration like cgroups.
It is poor design _not_ to provide such a unified and coherent OS layer for userland.
I discuss that here. If you think I am misinformed, I will look into it more deeply.
You are. Check out CK2, or the history of Ubuntu's shim. It was originally Canonical who was handed over the CK project, but they apparently thought the same as the CK2 maintainer, that the CK API sucked and Poettering's logind API didn't, and therefore cloned it into "systemd-shim" instead.
Sure, none of the API alternatives are full replacements since that would require a level of kernel and system integration only systemd provides, so no multi-seat etc. But the latest I read from Gnome's Olav Vitter's was that they would try to support the subset of features that the alternatives could support.
So in the future Gnome will support the systemd-API, not the CK API, just like CK2, systemBSD's logind etc does.
The latter of course depend on somebody doing some actual work instead of just complaining or spreading misinformation.
it also solves the problem with fossilized development of subsystems like init and logging,
Not a problem, and also not actually a thing. Several competing init systems which didn't bring baggage with them already existed, but Lennart is a real NIH kind of guy so he didn't start with one of those. Stable init and log daemons are features, not bugs.
Yes, it is a "thing". The problem with the fossilization of the Linux plumbing layer meant that crucial progress was being held back. All the init-systems in use at the time where just "slightly improved SysVinit" style init-systems. They all relied on executable config scripts to manage daemons, and none of them tried to step up an take proper responsibility for the boot and init process.
Upstart was a nice pioneering effort, but not a good solution as it were. But there are still other problems; crond fx. Why can't it handle hibernation properly? Probably because it was made when Unix servers where hand grafted out of shell scripts an always on. But there is no "cron" upstream developer group that takes RFE's, and no coordination between the many fragmented crond forks and userland developers, making all new development practically impossible. It would have been freaking nice if crond could have been dragged into the modern world 10-15 years ago, but as of now, we have to use crond+at+whatever instead.
systemd, as init and process manager, actually takes on the coordination responsibility that lacked previously. It is way cool how "namespace" isolation and kernel Capabilities(7) are integrated
You do realize that cgroups is a thing you diddle with very small commandline programs, right?
You are probably thinking of the old cgroups interface, but that is being deprecated in the near future in favor of the "single writer"/"unified hierarchy" that requires a writer that abstract away the kernel cgroup API so userland doesn't use it directly.
http://www.linuxfoundation.org...
The point is that system already comes with such an abstraction layer for capabilities, namespaces and cgroups, making it trivially easy for the admin to harness their power without coding, by simply setting the value "ProtectSystem=true" in the service file, or using similar features (see man systemd.exec). Better yet, distro maintainers can lock down the daemon per default, giving "out-of-the-box" security.
There is nothing else that even comes close to the power of systemd when it comes to such security integration. The systemd security framework for these kernel technologies are not only easy for humans to read and understand, but it is machine parsable and scalable too.
To my knowledge nobody in the non-systemd camp is even working on similar ideas, or even on an alternative cgroups single writer implementation.
Not tying it to a specific log daemon is the really important part, though!
Which is _exactly_ what journald _doesn't_! You can use it together with any "syslog(3)" daemon. So if you have a legacy setup, you can use with journald and it will even enhance it by providing logging info syslog normally can't get.
Yes it does. You can't separate logind from systemd (although that would be good software engineering, if they were separable). The systemd-logind API is deeply integrated into systemd. It shouldn't be, but it is.
You are misinformed. CK2 and systemd-shim are alternative implementations of the systemd-logind API (or at least the subset of the API Gnome/KDE actually need). The CK2 developers abandoned the old CK API in favor of the systemd API, simply because the systemd-logind API developed by Lennart Poettering is much nicer
There are actual good technical reasons why systemd is made like it is and why systemd-logind is part of the systemd project. You simply can't get the same features such as multi-seat without such integration.
The problem seems to be that you didn't read any of my posts that I linked to earlier. From what you've written, it doesn't even seem like you understand systemd very well. Yet somehow you are a huge proponent of systemd. I don't know. What do you like about it? That's a serious question.
systemd is a massive security increase compared to any other init-system out there, simple because it integrates Namespace isolation, Cgroups and Capabilities(7).
Daemon service files are in structured text format, instead of spaghetti code in executable files like Sysvinit/OpenRC.
Daemon service management vastly superior to anything else on Linux/Unix.
Non-systemd development is at a standstill, with only a tiny handful part time developers left. No coordination, no conferences, no capital investment, no nothing.
Having a toxic community doesn't attract developers.
>* Scope creep (there is no reason Gnome should depend on systemd).
Gnome doesn't depend on systemd as such, but on the systemd-logind API. Until recently (perhaps it still does) it also supported the old ConsolKit API as alternative even though CK had been dead for +1½ year with no upstream bug fixing or security support, and no one bothered to maintain it anyway.
The problem seems to be that the systemd-opponents really don't understand how Open Source software works and being developed, something that requires coordination, and positive contributions with either code, documentation, or money.
Claiming that the systemd developers are incompetent and doesn't understand software development will get you nowhere. You have to employ your superior knowledge into actual competing projects in order to be taken seriously. But that is the problem isn't it? The total lack of effort by the systemd-opponents to actually create something useful.
You could refute that trivially by clearly stating what problem it actually solves. Yet you chose not to do that.
systemd solves many old Linux problems; besides the technical ones like proper service management, it also solves the problem with fossilized development of subsystems like init and logging, and solves the old problem of lack of coordination between userland, kernel space, and the plumbing layer between.
systemd, as init and process manager, actually takes on the coordination responsibility that lacked previously. It is way cool how "namespace" isolation and kernel Capabilities(7) are integrated so system admins can turn on such security features just by adding a Boolean value in a text file. It also means that every iteration of systemd distros become ever more hardened per default, making ever more difficult for the the black hats to gain privilege escalation.
By dismissing every systemd feature and everything systemd does as "bad", systemd-opponents like you paint yourself and all your fellow travelers into an ever smaller corner, where "SysVinit/OpenRC" is the pinnacle of evolution without ever needing more features.
Good luck with that.
Berlin is way cool; music, culture, food, drink, world class museums, world history; Berlin has it all.
If a startup management subsystem needs its own conference, it is doing too much.
Sure, all progress is bad; Linux should be a 1986 Unix clone, there should be no new code blah blah blah.
There is nothing wrong with open source developers meeting up, talk and code. You probably agree to that, but your irrational emotionally driven hatred to systemd makes you post snarky remarks like the above.
What is really funny though, is that you systemd-opponents never realized how your hurt your own cause by negative campaigning; You are trying to "poison the systemd well", but you end up poisoning your own well too; From now on, the non-systemd developers can't make a conference working for non-systemd init-systems, because according to you, it isn't needed.
You guys are dragging yourself down with all the negative attitudes towards developers making progress.
It highlights an important problem: the Debian project has been making one truly bad decision after another recently.
We all know about Debian's systemd disaster. It was an absolutely stupid move that seriously divided the Debian community, and forced many of its best users over to the BSDs and other OSes.
SPARC support was killed because there where no developers to maintain it. Debian doesn't have fat support contracts that enables the project to hire developers to support legacy architectures. So if a software project/package/architecture isn't supported by developers so that bugs get fixed, it will be killed off.
systemd was widely welcomed by almost all Debian developers and the vast majority of Debian end-users. There was a lot of noise of the Debian mailing lists when the decision was made, but it turned out that the tiny minority of systemd-opponents couldn't even muster 5 Debian Developers to sponsor a GR to overturn that decision.
They also pretty much killed Debian GNU/kFreeBSD near the end of last year.
Again, look at the Debian mailing list. There where practically zero Debian GNU/kFreeBSD developers active, meaning that bugs didn't get fixed, even release blocker bugs. Even Debian GNU/Hurd was a vibrating developer hub compared to kFreeBSD and probably had many more end users too.
If you want something in the open source world, you will have to contribute towards it, either by code, bug reports, translations/documentation or money. Both the SPARC architecture and kFreeBSD failed to receive enough of such support to survive.
Notice that Debian will continue to support SPARC on existing pre-Jessie SPARC releases, just not on future ones.
Your first statement is factually incorrect, as the trend of "sane energy policy equals cheap energy prices" is easily visible in other states. Finland for example has a large installed nuclear capacity in addition to having hydro pretty much everywhere where it's easy enough to install, while having minimal "not yet ready" renewables installation. Energy is cheap.
Compare to Denmark which went full out on wind power and shut down the burner plants. Energy price astronomically high.
Notably, this is also seen in heavy industry. While Germany, realising what Energiewende would do to their heavy industry opted to subsidise heavy industry and let the rest bear the burden. Results were well documented.
Sure, the German industry largely avoid the infrastructure investment tax (energy tax) that the German consumers pay, unlike Denmark. But the fact is that German and Danish consumers are paying up front for the building of renewable energy sources and new transmission networks and other infrastructure. On top of that, Denmark have always had a high energy tax on top of the sales tax, simply because they historically didn't have energy sources like hydro or coal, but had to import everything.
Again, again, again, the EU electricity end prices for consumers heavily depend on the members states tax levels. Eg. If country A has a sales tax of 15% and country B has a sales tax of 25%, then the electricity prices will be higher in country B. And that may be true, even if production cost per megawatt is lower in country B.
The redeeming thing about doing it that way is that the taxpayers doesn't pay for such subsidies like they do in France; if you save on electricity, you save money in both Denmark and Germany. French taxpayers don't get a lesser tax bill on their wages if they save electricity.
This is exactly one of the problems the French government wants to solve; until now French nuclear power plant operators enjoyed a "feed tarif". That meant for every Megawatt produced, they would get money from the french taxpayers. No wonder France exported a lot of energy; the French taxpayers subsidized every megawatt sold.
So even if the nuclear plant produced electricity at above market prices, the French taxpayers would make it profitable for the plant operators to export energy.
BTW, the latest Finish nuclear power plant (EPR reactor) is a poster child for what is wrong with nuclear power from an economic angle; The "Olkiluoto 3" plant is almost a decade late since construction started and at least twice the price. And that estimate depends on that Areva/EDF actually for the first time are right that it may come online in 2018. Every other such prediction have failed the last many years.
The good news for the Finish consumers is that it is the French taxpayers who are funding this gigantic money-losing construction nightmare.
The Finns have also just recently canceled the "Olkiluoto 4" nuclear power plant. Probably as lucky escape for the French taxpayers they did that.
Rest of your argument is frankly inane to the extreme and could only be argued by someone utterly ignorant of reality of strategic sectors and how they are protected. Energy, food production, water and so on are strategic sectors required for existence of a functioning state. As a result they are heavily regulated and subsidized to ensure their seamless functionality regardless of market forces. Arguing against this on "free market" basis is utterly inane simply because lack of these subsidies and regulation in the said sectors would cause societal collapse, as failures in these sectors would be strategic failures causing failures of state structures.
Your talk about "strategic sectors" is like hearing a industry lobbyist from the seventies; Really, are all US states totally independent energy markets and are self sustaining with food etc., or do they buy stuff across state borders if they need?
The fact have been for decades now, that if
Right. Prices of electricity are magical, managed by overlords in their respective capitols. They have nothing to do with actual costs of production.
You are exaggerating what I say, and you still miss my point; You can't look at electricity prices in the EU and say whether they are below or above the production cost, nor can you interfere that production prices are high, just because the consumer prices are high.
To sum up again; French consumer electricity prices have been artificially low for decades, not because nuclear energy is cheap, but because French taxpayers are paying subsidies over their taxes, and because government regulation have kept prices under control. The latter have resulted in that EDF (mostly state owned) have been bleeding billions of Euros every year.
Again, read the Moody's statement.
In other news, did you remember that we live in a real world with limited resources, not one where electricity comes out of the socket?
P.S. Nuclear energy remains the cheapest energy source available to date per produced energy unit. That is why states that don't have to care for psychological bullshit pushed here in the West by people like you on their impressionable and ignorant public are investing heavily in them. Think China. Some of the best and toughest negotiators in the world, and people with some of the greatest power needs in the world. And they're massively investing in nuclear. If you were even close to reality with your "nuclear is expensive" claims, they simply wouldn't be doing it.
Only regimes where market forces plays no role, invest heavily in nuclear power. China and Russia don't care if the consumers are paying above market prices, because a free energy market doesn't exist in either place. They want nuclear power for other reasons than cheap energy, nuclear weapons to mention one thing.
There are no free market driven building of nuclear reactors, and it has been like that for the last last 20 years. All new reactors are heavily subsidized by local states.
No private capital are willing to finance new nuclear power-plants unless the local government gives state guarantees for profitability simply because nuclear power is too expensive to generate profit.
It doesn't help that all new EU reactors build the last couple of decades have had extreme budget overruns, and all the promises about standardization and factory modules instead of on location construction have turned out to be false both when it came to realization, quality control and prices. So construction cost have skyrocketed too. In the meantime, competing energy sources have become ever more advanced, efficient and cheap.
If nuclear reactor technology doesn't gain significant technological progress soon, especially on cost, it will become ever more marginalized. That France is winding down its dependency on nuclear power really says it all.
How about no? Costs in Germany and Denmark are high because production is expensive. They have to both use very expensive forms of generation as well as buy foreign electricity (which means both paying for electricity and long range transfer across international exchange) to provide spinning reserve for it.
Germany and Denmark prices were much lower back when they were using cheaper forms of generation, such as nuclear.
And when talking about subsidies, you cannot miss the fact that German subsidies are far higher than anyone in Europe right now. And their price is still far higher than French.
Again, there is no relation between the production prices and consumer prices in the EU.
The German electricity prices are very high because Germany is investing heavily in new energy technology, most importantly the worlds most advanced electricity network so they can shuffle electricity around the country, like cheap wind energy from northern Germany to the south, or export, import or even transit electricity from around the EU.
It is the German electricity consumers who are paying for this investment through higher prices, while in France it is the _taxpayers_ who are funding the subsidization of the nuclear industry.
Take a look a Moody's downgrading of EDF stock (EDF owns most nuclear plants in France):
"The rating downgrade reflects the risks associated with the transition of EDF's French power generation and supply activities from a predominantly regulated cost-reflective tariff model towards an increasing exposure to market power prices. Moody's notes that this transition is happening at a time when market prices are low and below the regulated price for nuclear output."
https://www.moodys.com/researc...
As can be seen, Moody's says nuclear power electricity production prices are higher than the market value. It therefore logical that they foresee problems when EDF is also facing a reduction in subsidies.
Nuclear power simply is much more expensive than natural gas, wind and solar power.
The French government have been heavily subsidizing the nuclear industry for decades, but the economic crisis and increasing EU competition makes such subsidies unfeasible in the long run.
That is why the present French government will wind down some of the nuclear industry, and start to invest more in cheaper energy sources like wind and solar. They are also trying to make consumers pay more in line of what the electricity actually cost to produce, and stop the nuclear industry from bleeding to death by accumulating debt like they do now.
So even more price hikes are in sight for French consumers.
Are you perchance unaware of the fact that French electricity prices are among the LOWEST in Europe?
If you were even remotely correct with your claim, prices would surely be at least on AVERAGE level?
Please notice that there is a difference between consumer electricity prices and electricity production prices.
The French consumer electricity prices are low, not because the production prices are low, but because the prices are subsidized by taxpayers and because government regulation fixes the prices at an artificially low level.
Also, notice that some countries with high electricity prices, like Germany and Denmark, are putting high taxes on consumer electricity prices. The high prices doesn't reflect high production prices, only high taxation. So looking at consumer prices alone says very little of what electricity production prices are.
The fact is that the French nuclear industry are totally unable to compete on price with other European non-nuclear power, which is why it is so heavily subsidized; it would simply be bankrupted if it had to compete with EU production prices.
In the future there will be less subsidization in France, resulting in several announced double digit price hikes for the next couple of years for consumers.