So you like having useless software always running on your machines, that you cannot get rid of, or absolutely turn off? It also still violates do one thing and do it well because it tries to do many things, and seems to do them poorly.
"journald" isn't useless, even if you don't use binary logging, but forward everything directly to syslog. "journald" works as a syslog helper that enhances syslog by collating all logfiles into a single file (instead of around +5 logfiles, some of them binary like "utmp"), and by collecting logging info from early boot, since journald can log from before even the root file system is mounted. When kdbus is mainlined, it will be able to collect "metal-to-metal" logging info, that means before rootfs is mounted, and after it is dismounted. Try that with syslog.
It also provide per-damon rate limiting and notification when syslog drops messages (syslog silently drops messages).
All in all, it would be stupid to turn of journald, even if forced to rely on flat file text logs.
Here, I think there's some mendacity as well on the part of Red Hat. Systemd absorbed several RedHat-run open source projects that should be stand alone (D-Bus and udev, for example) and not require a dependency on systemd. That's classic Microsoft-style "embrace and extend" behavior.
There is exactly one project that joined systemd, and that was the basically one-man project "udev". The udev inventor is also the co-inventor of systemd, and that project started way before Red Hat had even started to say "no" to using systemd (they later said "yes"; read the interview). So it is demonstrably wrong to claim that RH could have forced Kay Sievers/udev into the systemd project.
Dbus isn't a single project, but a standard just like tcp/ip with several different implementations. systemd makes heavy use of dbus, and even have some dbus helper libs, but the point is that systemd works with the "standard" dbus specification, regardless of implementation. That is the whole point of using a standard.
All the talk about RH/systemd "subsuming" other projects are simply plain wrong.
System is broken by design and totally violates the UNIX philosophy
Systemd isn't broken by design, it is in fact a brilliantly designed init-system which is why all major Linux distros are converting to it.
"UNIX philosophy" seems to be a codeword for "I have no real technical arguments against systemd".
But tell me this, if the most popular certified UNIX platforms are using init systems very similar to systemd, like SMF and launchd, aren't you really claiming that certified UNIX'es aren't UNIX?
Even non-certified UNIX clones like FreeBSD are talking about the necessity of having a init-system just like systemd/SMF/launchd. It is only a matter of time before all *BSD's have a modern init-system, and of course, they will clone every systemd feature possible.
Systemd does startup, it does logging, it does ntpd, it manages processes.. What do you think it does that is just one thing?
The point is that this is all done by different daemons and tools. So each systemd tool basically just do one thing. It is documented in the man pages if your are interested in facts.
Oh and by the way, systemd doesn't do "ntpd". Claiming that is a sure sign that you haven't studied the systemd documentation. systemd comes with an optional sNTP client that is meant for use in OS containers, which have special timekeeping needs because of timedrift between host and container when sleeping etc.
The only real fault I could give it is that in my experience, if you're so tightly wired into external things that you become an essential part of them, that's probably not the optimal system design.
That really isn't the case with systemd; it basically depends on glibc and util-linux for "mount" etc. just like most other init-systems, but everything else is optional.
That upstream projects actually make use of systemd features like systemd-logind can hardly be a problem either; all the non-systemd platforms are free to provide their own similar services that upstream projects can use, so there are no problems there either.
I DO have a lot against the binary logging for very good reasons. I've worked with a lot of products that did their logging in proprietary binary formats over the years, and even when the internal data formats are well-published, the mere fact that intermediary services are required to access and format them has made their respective products harder to work with.
Some facts first; systemd's journal isn't proprietary. It is a well documented standard with a stable API and language bindings: http://www.freedesktop.org/wik... There are several independent journal readers already. I can't think of any non-contrived user case where it is a problem that the logs are binary.
In fact, I can't think of any non-contrived user case where old style flat text file logging is better than systemd's journal; it scales better in every direction and allows for powerful filtering in a much better way than using humongous regex lines, is much more secure, allows for a single collated system log and much better debugging, etc. etc. Not forgetting that it is now possible to have reliable, robust logwatch scripts and even make a log viewing GUI that isn't just a glorifed "less" with windows decorations.
Just like you I have been bitten by (proprietary) binary log files (and much worse; binary config files). And just like you I was really, really skeptical about systemd's binary log format. But the more I used it, and the more documentation I read, the more I became really glad about it: systemd's journal just solves so many problems I have had over the years with syslog files. It is a really well thought out and well designed logging system.
I don't understand why 90% of the crap systemd's trying to suck in (like networking). Yet the systemd guys continue to glom everything in there.
If you don't understand it, it is probably because you don't use OS containers. Almost all new features and development on systemd the last couple of years have been OS container related; the sNTP client, networking, dhcp etc., are all meant for massive scale OS container deployment, and for the special need for OS container regarding keeping time (their environment can start-stop/freeze without notice, so time drift between host and container is a problem).
Google launches 2 billion OS containers a week, that is 3300 OS containers every second. The speed of "booting" a single OS container is therefore crucial for such massive deployments.
In fact, OS containers are rapidly becoming a central part of all new Linux deployment, and systemd is a central part of that.
I tend to grit my teeth when people say "If it ain't broke, don't fix it" about IT. IT tends to erode from the outside in, if no other way.
On the other hand, if you do "fix it", don't break things that people like and rely on.
So nothing on Linux must ever change, because there is always some reactionary, lazy admin somewhere who can't be bothered to learn something new and change his work-flow.
I have seen so many examples of such "IT-fossilization" during the last three decades. Some people scream and moan about how "new way" is bad and "old way" is much better. The end result is always the same; they get ejected out of the IT business when their old and obsolete skills are no longer needed.
If you work in tech, you just better have to learn to adapt to new and better technology like systemd. The first step in this is to be factually informed about how the new technology works.
And don't have the hubris to tell people that they're wrong/misguided/old-fashioned when they complain. That's the sin that both gnome3 and systemd committed.
Don't tell me you rely on hearsay from some swivel eyed systemd-hater to know the technical facts about Gnome and systemd?
It is a plain view fact that Gnome 3 runs on non-systemd platforms like BSD. So where is the problem? Is the problem that Gnome developers for years have pleaded for someone to step up and actually maintain crucial infrastructure needed by Gnome in order to work on non-systemd systems?
look, either journald is part of systemd or it isn't. If it is, then systemd does multiple things, and should be broken up into more parts. If it isn't, then your argument is nonsense.
If you want "metal-to-metal" logging and collating all logging info into a single file, and remain 100% compatible with syslog, you have no other choice than to design a logging system like systemd's "journald". It can't be split off because of how the Linux kernel is designed and handles/dev/log.
journald can start logging before even the root filesystem is mounted because systemd becomes active already in initramfs and then jumps to the rootfs when it is mounted.
It is a really good solution to a hard to solve problem.
If the cartoonish interpretation of "Unix philosophy" and "modularity" had any real substance, serious people would have forked systemd and split it into "modules". (The core of systemd is; systemd (daemon), udev, and journald; everything is optional). But they don't. The reason is simply that systemd have really, really good technical reasons for being designed like it is.
The rest is fully achievable using ConsoleKit2. You realize you don't understand it, which is good;-)
Link please. AFAIK, it isn't possible to run Xorg as non-root in a safe manner using either CK or ConsoleKit2.
And BTW, the difficulty in running xorg as non-root in a safe manner is caused by the way the Linux kernel handles devices, not Xorg. That is why you need user session management from systemd-logind in order to secure that attached devices can't be abused to compromise security.
I had the impression your post had an agenda, and then I read, at the end, you confirmed it:
When FreeBSD changes to a modern init-system (they will probably clone systemd)
Sure, my agenda is to show that supporting multiple init systems is very difficult.
That FreeBSD (and other BSD's) will change to a systemd-like init system is a given thing too. Even the founder of FreeBSD has publicly said it is in the future for FreeBSD.
The fact is that the way people uses computers have changed dramatically the last decade; virtualization, OS containers, instantiated services, mobile devices etc. SysVinit and similar legacy style script based init systems simply aren't up to working with all this.
So when FreebSD change their init system (and they will), they won't support a free choice between the new init system and old legacy script based init systems either.
And this is a clear systemd bias (and GNOME attitude).
If systemd says it is not a bug, then it is not. And if something doesn't work - well, somebody opened a ticket about something NOT working - then something does NOT work. And if the systemd refused to fix it - who's going to?
Not every bug filed is an actual bug, even though the submitter feels it is. Saying no to bad patches and closing non-bugs with a "not-a-bug" is the daily grind of developers and package maintainers.
The "Heartbleed" bug is a prime example on how bad things can go when you accept patches that circumvent security measures in order to support obscure user cases.
Really, systemd developers accept a huge amount of patches from hundreds of different non-systemd developers each year, suggesting that they won't accept patches is simply contrary to reality. I have yet to see a reasonable patch being rejected on the systemd-mailing list.
The whole position of systemd implementors in Debian was and probably still is: we change how the whole system works, but we are totally not responsible if something breaks, because it is, duh, mainline systemd.
I really don't see the Debian systemd maintainers that way at all. They seem to be hard working and serious to me. I have yet to see a example of them accepting breakage because mainline systemd. As I said, there are Debian developers with commit access to the systemd git tree, so they obviously have a lot of influence on systemd as a upstream project.
Tollef Fog Heen was pretty clear that he is not going to do anything special for Debian. (He is (or was at the time) a Fedora user already anyway.)
I have seen no examples or evidence of this. Really, what specific non-trivial patches could Debian need that couldn't go into mainline systemd? Can't think of any, nor have I ever seen it on the mailing list.
Huh?
If you can't tell what the hell the trivial commit does, then you are obviously not a software developer.
It is trivial, but it is Debian distro specific and in upstream systemd. There are a lot more examples in the git tree, and also of Debian influence in the general design of systemd. You assertion that systemd developers doesn't care or won't accommodate the Debian distro is therefore unfounded.
That systemd actually accepts trivial distro specific patches, shows that they are accommodating their users. Since it is trivial, it could have been carried by the distro maintainer.
That was a great PR move on part of the systemd developers: to flood the mail lists with the buzz words. Users have no idea what they mean - but they sure sound cool - so systemd must be cool too.
Really, trying to pass off systemd as a "fad" that Debian accepted because of "buzzwords" on a mailing list is outright pathetic; systemd is real improvement over SysVinit in every aspect, and the Debian CTTE choose it because of its technical merit. That the Debian developers agree with this, was demonstrated at the latest Debian GR.
Hey wait a minute! the scammers are also on slashdot!!
quick quick, close your wallet!
Well, I am right ain't I. You funnel the donated Devuan money into dyne org, and as CEO/Chairman of that small org with self elected people, with no public oversight of the money, you also pull money out of dyne org into your own pocket to "pay for taxes". Dress it all up as a non-profit org too.
Make Devuan a proper org that directly receive the donated money you are begging for all the time, and have a proper elected committee with public oversight over the donated money and what they are spend on, and then maybe the smell of scam will evaporate.
I was just quoting the (ex-)maintainer of the systemd, from his e-mails from the CTTE discussion.
Without source or citation. I think your representation of what was said is rather biased.
Debian feedback would be submitted to mainline - but if it is rejected, he wouldn't even carry a custom Debian patch for it, because he doesn't want to deviate from the mainline. And he, as the maintainer of the systemd, would not consider it a bug. As such somebody else would have to fix somewhere else.
If it isn't a bug, why patch it? Sure, some people have tried to drop some turd patches into systemd, eg. ripping out security features in order to support some obscure glibc variant. The right thing of course is to patch the glibc variant to support the proper security functions, not patching systemd.
No package maintainer wants to support non-trivial, non-mainline patches without very good reasons. The whole point of open source software, that as many people as possible can share and enjoy improvements, so patches should go upstream as fast as possible. Maintaining non-trivial, non-upstream patches can also be a real problem when backporting security fixes, and may introduce patch specific bugs too.
If you are willing to grep through the 1K emails - you would definitely find that being repeated several time.
I have actually read most of them at the time, and I still think you are misrepresenting the systemd maintainers.
It is very obviously a distro specific part of systemd: Debian was added to the list where Fedora and Arch were already present.
Huh? The main point is that systemd mainline accepts Debian (and distro) specific patches if it is unavoidable. Despite the many claims to the contrary, the systemd developers do care about feedback and have many different distro developers with commit access. If you got a good user case, chances are good that a distro specific patch will be accepted. And having the patch going into the upstream repo is much better than carrying it as a separate distro patch.
In short, Debian developers where taking part in creating systemd long before Debian discussed making systemd the default init system. So they knew what they where doing when selecting systemd over Upstart (the CLA was enough to discount it), and the latest GR have confirmed that the vast majority of Debian developers firmly backs systemd as the default init-system.
.... The systemd devs and maintainers committed to literally to nothing, basically saying "if it is good for Fedora is should do the job for Debian too; no Debian specific patches are going to be accepted even into the Debian systemd package".
That is simply wrong. Please notice that several long time systemd developers with commit access to the systemd git tree, are in fact Debian Developers. So there is a lot of "Debianism's" in where files placed etc.
Sure, the main branch of systemd wants to have as few distro specific patches as possible, but they do accept them if there is no other solution.
The problem with Debian is that for whatever reason they ignored the power of linux, choice. At least in Debian 8, it is still trivial to make it use sysvinitrc instead of system. Why not let people choose, instead of forcing it upon new upgrades, and worse insult yet, make current systems upgrade to systemd by default?
Every choice has a cost and a consequences. In this case, supporting multiple init-systems dramatically increase the maintenance complexity. Every Debian Developer would need to run both a stable and unstable/testing version of both init systems, and some packages would have to be maintained in two different versions (talk about dependency hell).
But that isn't even the most problematic part; that is the fact that all non-systemd development have more or less collapsed the last couple of years; "ConsoleKit" bit-rotted for years, meaning DE developers couldn't justify developing against it, "SysVinit" is hopelessly understaffed (don't even have a build test) and haven't made a release for 5 years (RH/SUSE was the defacto maintainers), there is no development taking place on real alternatives to systemd's "udev" (the "eudev" is mainly a shadow fork by AFAIK, one person), "cgroups" development like "CGManager" will cease when systemd provides functionality to support LXC, and so on.
In short, there is a huge stack of development needed now and in the future in order to run a non-systemd Linux distro, and fewer and fewer developers to do the job.
When FreeBSD changes to a modern init-system (they will probably clone systemd), they won't support old legacy style init-scripts daemons permanently either. It is simply too much work with too little gain.
It covers a wide range of topics: the 4.5k€ of donations received so far, moving distro infrastructure from GitHub to GitLab, progress on LoginKit (which replaces systemd's logind), fraud accusations, logo discussions, and few more important points.
Was someone trying to sneak that one through in the middle of a dull-news sandwich?
The problem is that all money donated to Devuan doesn't go directly into Devuan, but into a rather dubious organization, with no public oversight and no accountability. Here is a link to the org and their pre-Devuan Linux distro: http://www.dynebolic.org/ Take a look around, and notice how a "donate" button never is far way from any project or web page.
The foundation has a chairman called Denis Roio, AKA "Jaromil", and according to themselves, the foundation "helps them pay taxes", in other words, they pay themselves from the org whatever they like.
There is a certain smell of "scam" around the Devuan project, not so much its contributors as a whole, but about the small group of shady figures centered around the "dyne org".
However, merely drinking doesn't spark any good creative ideas unless you have spend considerable time thinking about the subject before. Also, the magic doesn't happen unless you have somebody to discuss the ideas with.
I don't think it is a proper term, but in this case I refer to music with large and very sudden variations between "quit" and "loud" passages. The real musical term "dynamics" is between eg. piano/forte, but I am more referring to an instruments individual attack (hitting the strings/drums/keys real hard). IMHO, this i something that neither mp3 or vorbis handles so well; they seem to take the edge of the attacks.
Just because some audiophiles are rich boys that spend too much money on bling hardware doesn't mean that all sound-systems sound the same. There actually is a sound difference between a pair of $1 headphones and a $100 pair of Sennheiser HD-558.
It doesn't cost much to get decent sound these days, and it really improves the joy of listening to music.
ABX testing shows otherwise. Even when done with professional audio engineers.
Sure. I probably can't tell the difference either just by listening to a random segment of random music in an ABX test. I do can tell the difference when listening to the same well known album in FLAC and mp3. The FLAC files just are more dynamic; more punch and attack, while even HQ mp3's sounds slightly "dull" or muted. The more dynamic and "noisy" the music is, and the louder it is played, the larger the difference is.
Nope, I use high quality VBR MP3 for my music because a) it sounds great, b) it's supported on everything and c) it takes a lot less storage space. FLAC is for idiots who think they have superhuman hearing.
VBR mp3's are very good, but it isn't FLAC. You don't need superhuman hearing to hear the difference, especially very dynamic music sounds better in FLAC. Hearing the difference becomes easier the better your audio equipment is.
Not having FLAC and mkv support for a media player is simply insane. Those who cares at all for sound quality uses FLAC, even my tiny mp3 player support FLAC.
That MS "boycotted" FLAC for years because it doesn't support DRM and isn't a MS-patent trap, just hurt their desire to control all media consumption on MS-platforms; they forgot a "boycott" works both ways, and that people just used software like VLC that actually supported what people wanted.
Citation needed, by all appearances EDF was still turning a profit in 2013. It looks like some of their foreign holdings outside of Europe are problematic for them, but that just goes to show their core business of selling nuclear power to Europeans is profitable enough to offset losses from other investments. Hardly a condemnation of the economics of nuclear power.
As the press release indicate, they have both a large debt and a negative cash flow something they want to improve in the 2014-2018 period (by massive price hikes).
Basically EDF are producing electricity above market prices and is selling below cost to consumers. In order not to collapse, they will have to rise prices:
On top of that, the aging fleet of EDF nuclear reactors will soon have to be either replaced or rejuvenated, which will mean a huge need for cash, and is highly likely to mean even further price increases for consumers.
As for 'free market solutions' I hadn't realized that when we discussed emissions reductions that a solution must be rejected because it is or is not capitalist enough in nature.
Well, that was the premise for the Google engineers article. They wanted to make renewable energy at prices competitive with gas/coal, and found out it wasn't possible. That nuclear power can't compete on price is also why the free market have rejected it.
Personally I think it is a market failure that cheap but CO2 polluting fossil fuels are allowed to be used, and that a national energy plan must have it as priority to drastically reduce CO2 output.
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.
They didn't address the "what if everything changed in an instant" case in their article.
Yes they did. It is the core of their argument. to quote:
"While this energy revolution is taking place, another field needs to progress as well. As Hansen has shown, if all power plants and industrial facilities switch over to zero-carbon energy sources right now, we’ll still be left with a ruinous amount of CO2 in the atmosphere. It would take centuries for atmospheric levels to return to normal, which means centuries of warming and instability...."
Basically we have reached a point where even removing all CO2 produced by the energy sector isn't enough to stop the man made global warming and climate change. Decades of doing nothing and being in denial will cost tax payers huge sums in the future.
Yes it is; the article says that basically nothing can compete with cheap fossil fuels like coal or natural gas at the moment.
Nuclear power certainly can't compete in a free energy market. It is a mature technology with massive research and funding going on the last 60 years, while wind and solar power have been neglected for decades as a serious research area. Danish wind turbines have increase their load efficiency by 50% since 2008 by tweaking hub height and blade length but without changing the generator or increase generator capacity. And there are more such efficiency and price gains to be made within the next decade, and unlike nuclear power plants, wind turbines is a nimble technology that can quickly be implemented in the field.
The bottom line is that wind and solar power are getting better and cheaper for every year, while nuclear power technology in the field have been stagnating for decades.
Slashdot Mirror
So you like having useless software always running on your machines, that you cannot get rid of, or absolutely turn off? It also still violates do one thing and do it well because it tries to do many things, and seems to do them poorly.
"journald" isn't useless, even if you don't use binary logging, but forward everything directly to syslog.
"journald" works as a syslog helper that enhances syslog by collating all logfiles into a single file (instead of around +5 logfiles, some of them binary like "utmp"), and by collecting logging info from early boot, since journald can log from before even the root file system is mounted. When kdbus is mainlined, it will be able to collect "metal-to-metal" logging info, that means before rootfs is mounted, and after it is dismounted. Try that with syslog.
It also provide per-damon rate limiting and notification when syslog drops messages (syslog silently drops messages).
All in all, it would be stupid to turn of journald, even if forced to rely on flat file text logs.
Here, I think there's some mendacity as well on the part of Red Hat. Systemd absorbed several RedHat-run open source projects that should be stand alone (D-Bus and udev, for example) and not require a dependency on systemd. That's classic Microsoft-style "embrace and extend" behavior.
There is exactly one project that joined systemd, and that was the basically one-man project "udev". The udev inventor is also the co-inventor of systemd, and that project started way before Red Hat had even started to say "no" to using systemd (they later said "yes"; read the interview). So it is demonstrably wrong to claim that RH could have forced Kay Sievers/udev into the systemd project.
Dbus isn't a single project, but a standard just like tcp/ip with several different implementations. systemd makes heavy use of dbus, and even have some dbus helper libs, but the point is that systemd works with the "standard" dbus specification, regardless of implementation. That is the whole point of using a standard.
All the talk about RH/systemd "subsuming" other projects are simply plain wrong.
System is broken by design and totally violates the UNIX philosophy
Systemd isn't broken by design, it is in fact a brilliantly designed init-system which is why all major Linux distros are converting to it.
"UNIX philosophy" seems to be a codeword for "I have no real technical arguments against systemd".
But tell me this, if the most popular certified UNIX platforms are using init systems very similar to systemd, like SMF and launchd, aren't you really claiming that certified UNIX'es aren't UNIX?
Even non-certified UNIX clones like FreeBSD are talking about the necessity of having a init-system just like systemd/SMF/launchd. It is only a matter of time before all *BSD's have a modern init-system, and of course, they will clone every systemd feature possible.
Systemd does startup, it does logging, it does ntpd, it manages processes.. What do you think it does that is just one thing?
The point is that this is all done by different daemons and tools. So each systemd tool basically just do one thing. It is documented in the man pages if your are interested in facts.
Oh and by the way, systemd doesn't do "ntpd". Claiming that is a sure sign that you haven't studied the systemd documentation. systemd comes with an optional sNTP client that is meant for use in OS containers, which have special timekeeping needs because of timedrift between host and container when sleeping etc.
The only real fault I could give it is that in my experience, if you're so tightly wired into external things that you become an essential part of them, that's probably not the optimal system design.
That really isn't the case with systemd; it basically depends on glibc and util-linux for "mount" etc. just like most other init-systems, but everything else is optional.
That upstream projects actually make use of systemd features like systemd-logind can hardly be a problem either; all the non-systemd platforms are free to provide their own similar services that upstream projects can use, so there are no problems there either.
I DO have a lot against the binary logging for very good reasons. I've worked with a lot of products that did their logging in proprietary binary formats over the years, and even when the internal data formats are well-published, the mere fact that intermediary services are required to access and format them has made their respective products harder to work with.
Some facts first; systemd's journal isn't proprietary. It is a well documented standard with a stable API and language bindings:
http://www.freedesktop.org/wik...
There are several independent journal readers already. I can't think of any non-contrived user case where it is a problem that the logs are binary.
In fact, I can't think of any non-contrived user case where old style flat text file logging is better than systemd's journal; it scales better in every direction and allows for powerful filtering in a much better way than using humongous regex lines, is much more secure, allows for a single collated system log and much better debugging, etc. etc.
Not forgetting that it is now possible to have reliable, robust logwatch scripts and even make a log viewing GUI that isn't just a glorifed "less" with windows decorations.
Just like you I have been bitten by (proprietary) binary log files (and much worse; binary config files). And just like you I was really, really skeptical about systemd's binary log format. But the more I used it, and the more documentation I read, the more I became really glad about it: systemd's journal just solves so many problems I have had over the years with syslog files. It is a really well thought out and well designed logging system.
I don't understand why 90% of the crap systemd's trying to suck in (like networking). Yet the systemd guys continue to glom everything in there.
If you don't understand it, it is probably because you don't use OS containers. Almost all new features and development on systemd the last couple of years have been OS container related; the sNTP client, networking, dhcp etc., are all meant for massive scale OS container deployment, and for the special need for OS container regarding keeping time (their environment can start-stop/freeze without notice, so time drift between host and container is a problem).
Google launches 2 billion OS containers a week, that is 3300 OS containers every second. The speed of "booting" a single OS container is therefore crucial for such massive deployments.
In fact, OS containers are rapidly becoming a central part of all new Linux deployment, and systemd is a central part of that.
I tend to grit my teeth when people say "If it ain't broke, don't fix it" about IT. IT tends to erode from the outside in, if no other way.
On the other hand, if you do "fix it", don't break things that people like and rely on.
So nothing on Linux must ever change, because there is always some reactionary, lazy admin somewhere who can't be bothered to learn something new and change his work-flow.
I have seen so many examples of such "IT-fossilization" during the last three decades. Some people scream and moan about how "new way" is bad and "old way" is much better. The end result is always the same; they get ejected out of the IT business when their old and obsolete skills are no longer needed.
If you work in tech, you just better have to learn to adapt to new and better technology like systemd. The first step in this is to be factually informed about how the new technology works.
And don't have the hubris to tell people that they're wrong/misguided/old-fashioned when they complain. That's the sin that both gnome3 and systemd committed.
Don't tell me you rely on hearsay from some swivel eyed systemd-hater to know the technical facts about Gnome and systemd?
It is a plain view fact that Gnome 3 runs on non-systemd platforms like BSD. So where is the problem?
Is the problem that Gnome developers for years have pleaded for someone to step up and actually maintain crucial infrastructure needed by Gnome in order to work on non-systemd systems?
look, either journald is part of systemd or it isn't. If it is, then systemd does multiple things, and should be broken up into more parts. If it isn't, then your argument is nonsense.
If you want "metal-to-metal" logging and collating all logging info into a single file, and remain 100% compatible with syslog, you have no other choice than to design a logging system like systemd's "journald". It can't be split off because of how the Linux kernel is designed and handles /dev/log.
journald can start logging before even the root filesystem is mounted because systemd becomes active already in initramfs and then jumps to the rootfs when it is mounted.
It is a really good solution to a hard to solve problem.
If the cartoonish interpretation of "Unix philosophy" and "modularity" had any real substance, serious people would have forked systemd and split it into "modules". (The core of systemd is; systemd (daemon), udev, and journald; everything is optional). But they don't. The reason is simply that systemd have really, really good technical reasons for being designed like it is.
The rest is fully achievable using ConsoleKit2. You realize you don't understand it, which is good ;-)
Link please. AFAIK, it isn't possible to run Xorg as non-root in a safe manner using either CK or ConsoleKit2.
And BTW, the difficulty in running xorg as non-root in a safe manner is caused by the way the Linux kernel handles devices, not Xorg. That is why you need user session management from systemd-logind in order to secure that attached devices can't be abused to compromise security.
I had the impression your post had an agenda, and then I read, at the end, you confirmed it:
When FreeBSD changes to a modern init-system (they will probably clone systemd)
Sure, my agenda is to show that supporting multiple init systems is very difficult.
That FreeBSD (and other BSD's) will change to a systemd-like init system is a given thing too. Even the founder of FreeBSD has publicly said it is in the future for FreeBSD.
The fact is that the way people uses computers have changed dramatically the last decade; virtualization, OS containers, instantiated services, mobile devices etc. SysVinit and similar legacy style script based init systems simply aren't up to working with all this.
So when FreebSD change their init system (and they will), they won't support a free choice between the new init system and old legacy script based init systems either.
If it isn't a bug, why patch it?
And this is a clear systemd bias (and GNOME attitude).
If systemd says it is not a bug, then it is not. And if something doesn't work - well, somebody opened a ticket about something NOT working - then something does NOT work. And if the systemd refused to fix it - who's going to?
Not every bug filed is an actual bug, even though the submitter feels it is. Saying no to bad patches and closing non-bugs with a "not-a-bug" is the daily grind of developers and package maintainers.
The "Heartbleed" bug is a prime example on how bad things can go when you accept patches that circumvent security measures in order to support obscure user cases.
Really, systemd developers accept a huge amount of patches from hundreds of different non-systemd developers each year, suggesting that they won't accept patches is simply contrary to reality. I have yet to see a reasonable patch being rejected on the systemd-mailing list.
The whole position of systemd implementors in Debian was and probably still is: we change how the whole system works, but we are totally not responsible if something breaks, because it is, duh, mainline systemd.
I really don't see the Debian systemd maintainers that way at all. They seem to be hard working and serious to me. I have yet to see a example of them accepting breakage because mainline systemd. As I said, there are Debian developers with commit access to the systemd git tree, so they obviously have a lot of influence on systemd as a upstream project.
Tollef Fog Heen was pretty clear that he is not going to do anything special for Debian. (He is (or was at the time) a Fedora user already anyway.)
I have seen no examples or evidence of this. Really, what specific non-trivial patches could Debian need that couldn't go into mainline systemd? Can't think of any, nor have I ever seen it on the mailing list.
Huh?
If you can't tell what the hell the trivial commit does, then you are obviously not a software developer.
It is trivial, but it is Debian distro specific and in upstream systemd. There are a lot more examples in the git tree, and also of Debian influence in the general design of systemd. You assertion that systemd developers doesn't care or won't accommodate the Debian distro is therefore unfounded.
That systemd actually accepts trivial distro specific patches, shows that they are accommodating their users. Since it is trivial, it could have been carried by the distro maintainer.
That was a great PR move on part of the systemd developers: to flood the mail lists with the buzz words. Users have no idea what they mean - but they sure sound cool - so systemd must be cool too.
Really, trying to pass off systemd as a "fad" that Debian accepted because of "buzzwords" on a mailing list is outright pathetic; systemd is real improvement over SysVinit in every aspect, and the Debian CTTE choose it because of its technical merit. That the Debian developers agree with this, was demonstrated at the latest Debian GR.
Thanks Peter! you are so kind!
Hey wait a minute! the scammers are also on slashdot!!
quick quick, close your wallet!
Well, I am right ain't I. You funnel the donated Devuan money into dyne org, and as CEO/Chairman of that small org with self elected people, with no public oversight of the money, you also pull money out of dyne org into your own pocket to "pay for taxes". Dress it all up as a non-profit org too.
Make Devuan a proper org that directly receive the donated money you are begging for all the time, and have a proper elected committee with public oversight over the donated money and what they are spend on, and then maybe the smell of scam will evaporate.
I was just quoting the (ex-)maintainer of the systemd, from his e-mails from the CTTE discussion.
Without source or citation. I think your representation of what was said is rather biased.
Debian feedback would be submitted to mainline - but if it is rejected, he wouldn't even carry a custom Debian patch for it, because he doesn't want to deviate from the mainline. And he, as the maintainer of the systemd, would not consider it a bug. As such somebody else would have to fix somewhere else.
If it isn't a bug, why patch it? Sure, some people have tried to drop some turd patches into systemd, eg. ripping out security features in order to support some obscure glibc variant. The right thing of course is to patch the glibc variant to support the proper security functions, not patching systemd.
No package maintainer wants to support non-trivial, non-mainline patches without very good reasons. The whole point of open source software, that as many people as possible can share and enjoy improvements, so patches should go upstream as fast as possible. Maintaining non-trivial, non-upstream patches can also be a real problem when backporting security fixes, and may introduce patch specific bugs too.
If you are willing to grep through the 1K emails - you would definitely find that being repeated several time.
I have actually read most of them at the time, and I still think you are misrepresenting the systemd maintainers.
Here is a Debian specific patch that predates Debians adoption of systemd as default init-system:
http://cgit.freedesktop.org/sy...
It's obviously not Debian specific.
It is very obviously a distro specific part of systemd: Debian was added to the list where Fedora and Arch were already present.
Huh? The main point is that systemd mainline accepts Debian (and distro) specific patches if it is unavoidable. Despite the many claims to the contrary, the systemd developers do care about feedback and have many different distro developers with commit access. If you got a good user case, chances are good that a distro specific patch will be accepted. And having the patch going into the upstream repo is much better than carrying it as a separate distro patch.
In short, Debian developers where taking part in creating systemd long before Debian discussed making systemd the default init system. So they knew what they where doing when selecting systemd over Upstart (the CLA was enough to discount it), and the latest GR have confirmed that the vast majority of Debian developers firmly backs systemd as the default init-system.
.... The systemd devs and maintainers committed to literally to nothing, basically saying "if it is good for Fedora is should do the job for Debian too; no Debian specific patches are going to be accepted even into the Debian systemd package".
That is simply wrong. Please notice that several long time systemd developers with commit access to the systemd git tree, are in fact Debian Developers. So there is a lot of "Debianism's" in where files placed etc.
Sure, the main branch of systemd wants to have as few distro specific patches as possible, but they do accept them if there is no other solution.
Here is a Debian specific patch that predates Debians adoption of systemd as default init-system:
http://cgit.freedesktop.org/sy...
The problem with Debian is that for whatever reason they ignored the power of linux, choice. At least in Debian 8, it is still trivial to make it use sysvinitrc instead of system. Why not let people choose, instead of forcing it upon new upgrades, and worse insult yet, make current systems upgrade to systemd by default?
Every choice has a cost and a consequences. In this case, supporting multiple init-systems dramatically increase the maintenance complexity. Every Debian Developer would need to run both a stable and unstable/testing version of both init systems, and some packages would have to be maintained in two different versions (talk about dependency hell).
But that isn't even the most problematic part; that is the fact that all non-systemd development have more or less collapsed the last couple of years; "ConsoleKit" bit-rotted for years, meaning DE developers couldn't justify developing against it, "SysVinit" is hopelessly understaffed (don't even have a build test) and haven't made a release for 5 years (RH/SUSE was the defacto maintainers), there is no development taking place on real alternatives to systemd's "udev" (the "eudev" is mainly a shadow fork by AFAIK, one person), "cgroups" development like "CGManager" will cease when systemd provides functionality to support LXC, and so on.
In short, there is a huge stack of development needed now and in the future in order to run a non-systemd Linux distro, and fewer and fewer developers to do the job.
When FreeBSD changes to a modern init-system (they will probably clone systemd), they won't support old legacy style init-scripts daemons permanently either. It is simply too much work with too little gain.
It covers a wide range of topics: the 4.5k€ of donations received so far, moving distro infrastructure from GitHub to GitLab, progress on LoginKit (which replaces systemd's logind), fraud accusations, logo discussions, and few more important points.
Was someone trying to sneak that one through in the middle of a dull-news sandwich?
The problem is that all money donated to Devuan doesn't go directly into Devuan, but into a rather dubious organization, with no public oversight and no accountability.
Here is a link to the org and their pre-Devuan Linux distro:
http://www.dynebolic.org/
Take a look around, and notice how a "donate" button never is far way from any project or web page.
The foundation has a chairman called Denis Roio, AKA "Jaromil", and according to themselves, the foundation "helps them pay taxes", in other words, they pay themselves from the org whatever they like.
There is a certain smell of "scam" around the Devuan project, not so much its contributors as a whole, but about the small group of shady figures centered around the "dyne org".
Beers for ideas, Coffee for working.
So true.
However, merely drinking doesn't spark any good creative ideas unless you have spend considerable time thinking about the subject before. Also, the magic doesn't happen unless you have somebody to discuss the ideas with.
Genuine question, what is "dynamic" music?
I don't think it is a proper term, but in this case I refer to music with large and very sudden variations between "quit" and "loud" passages. The real musical term "dynamics" is between eg. piano/forte, but I am more referring to an instruments individual attack (hitting the strings/drums/keys real hard). IMHO, this i something that neither mp3 or vorbis handles so well; they seem to take the edge of the attacks.
Audiophiles are hilarious.
Just because some audiophiles are rich boys that spend too much money on bling hardware doesn't mean that all sound-systems sound the same. There actually is a sound difference between a pair of $1 headphones and a $100 pair of Sennheiser HD-558.
It doesn't cost much to get decent sound these days, and it really improves the joy of listening to music.
ABX testing shows otherwise. Even when done with professional audio engineers.
Sure. I probably can't tell the difference either just by listening to a random segment of random music in an ABX test. I do can tell the difference when listening to the same well known album in FLAC and mp3. The FLAC files just are more dynamic; more punch and attack, while even HQ mp3's sounds slightly "dull" or muted. The more dynamic and "noisy" the music is, and the louder it is played, the larger the difference is.
Just downloaded a ABX test from here:
http://lacinato.com/cm/softwar...
If I can get it to work I will try to see if I can tell a difference with any confidence.
Nope, I use high quality VBR MP3 for my music because a) it sounds great, b) it's supported on everything and c) it takes a lot less storage space. FLAC is for idiots who think they have superhuman hearing.
VBR mp3's are very good, but it isn't FLAC. You don't need superhuman hearing to hear the difference, especially very dynamic music sounds better in FLAC. Hearing the difference becomes easier the better your audio equipment is.
Not having FLAC and mkv support for a media player is simply insane. Those who cares at all for sound quality uses FLAC, even my tiny mp3 player support FLAC.
That MS "boycotted" FLAC for years because it doesn't support DRM and isn't a MS-patent trap, just hurt their desire to control all media consumption on MS-platforms; they forgot a "boycott" works both ways, and that people just used software like VLC that actually supported what people wanted.
Citation needed, by all appearances EDF was still turning a profit in 2013. It looks like some of their foreign holdings outside of Europe are problematic for them, but that just goes to show their core business of selling nuclear power to Europeans is profitable enough to offset losses from other investments. Hardly a condemnation of the economics of nuclear power.
As the press release indicate, they have both a large debt and a negative cash flow something they want to improve in the 2014-2018 period (by massive price hikes).
Basically EDF are producing electricity above market prices and is selling below cost to consumers. In order not to collapse, they will have to rise prices:
http://www.thelocal.fr/2013070...
Here is their debt stated as 39bn Euros in 2013 and that the company is in trouble:
http://www.telegraph.co.uk/fin...
On top of that, the aging fleet of EDF nuclear reactors will soon have to be either replaced or rejuvenated, which will mean a huge need for cash, and is highly likely to mean even further price increases for consumers.
As for 'free market solutions' I hadn't realized that when we discussed emissions reductions that a solution must be rejected because it is or is not capitalist enough in nature.
Well, that was the premise for the Google engineers article. They wanted to make renewable energy at prices competitive with gas/coal, and found out it wasn't possible.
That nuclear power can't compete on price is also why the free market have rejected it.
Personally I think it is a market failure that cheap but CO2 polluting fossil fuels are allowed to be used, and that a national energy plan must have it as priority to drastically reduce CO2 output.
But they don't say anything like this:
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.
They didn't address the "what if everything changed in an instant" case in their article.
Yes they did. It is the core of their argument. to quote:
"While this energy revolution is taking place, another field needs to progress as well. As Hansen has shown, if all power plants and industrial facilities switch over to zero-carbon energy sources right now, we’ll still be left with a ruinous amount of CO2 in the atmosphere. It would take centuries for atmospheric levels to return to normal, which means centuries of warming and instability. ..."
Basically we have reached a point where even removing all CO2 produced by the energy sector isn't enough to stop the man made global warming and climate change.
Decades of doing nothing and being in denial will cost tax payers huge sums in the future.
Yes it is; the article says that basically nothing can compete with cheap fossil fuels like coal or natural gas at the moment.
Nuclear power certainly can't compete in a free energy market. It is a mature technology with massive research and funding going on the last 60 years, while wind and solar power have been neglected for decades as a serious research area. Danish wind turbines have increase their load efficiency by 50% since 2008 by tweaking hub height and blade length but without changing the generator or increase generator capacity. And there are more such efficiency and price gains to be made within the next decade, and unlike nuclear power plants, wind turbines is a nimble technology that can quickly be implemented in the field.
The bottom line is that wind and solar power are getting better and cheaper for every year, while nuclear power technology in the field have been stagnating for decades.