SoylentNews is people
SoylentNews
Earlier this week, KDE developer David Edmundson described in his blog how KDE would be tied to logind and timedated but not systemd itself, at least according to his claim that "The init system is one part of systemd that doesn't affect us at all, and any other could be used.".
Later, in the blog comments, he clarifies that starting with plasma 5.5, in 6 months, they'll drop "legacy" support, according to a decision taken in the plasma sprint.
Even if one can only guess why there is no formal announcement, it seems clear - unless somehow there is a shim or emulator, not only for logind but also for timedated, in 6 months KDE will be unusable unless you are running systemd. And the blog entry makes it clear that the plan is to remove more and more functionality from KDE and use systemd instead.
(Score: 2) by Gaaark on Friday February 20 2015, @01:27PM
Sorry... just rtfa....
[gives head a shake]
Still seems odd...
--- Please remind me if I haven't been civil to you: I'm channeling MDC. ---Gaaark 2.0 ---
(Score: 4, Insightful) by Nerdfest on Friday February 20 2015, @02:31PM
It's really too bad., I tried out the alpha of the upcoming Xubuntu release and I think it's hands-down the prettiest desktop environment I've ever seen. I'll probably stick with it, but I know others won't because of systemd. People really don't seem to understand about proper component decoupling (again, assuming a shim layer is not being implemented that will convert time and date API calls to the underlying implementations). What the hell is going on these days? Like open protocols, loosely coupled designs are one of the big reasons things can move forward so fast when improving things.
(Score: 3, Funny) by GeminiDomino on Friday February 20 2015, @03:30PM
Has XFCE moved to require the systemd suite too, or is it just the underlying Ubuntu system?
"We've been attacked by the intelligent, educated segment of our culture"
(Score: 5, Informative) by arashi no garou on Friday February 20 2015, @03:49PM
Just Ubuntu; Xfce hasn't had a major release in three years so I doubt it will be adopting anything systemd related any time soon. And the subject of the article and summary suggests that either Slackware will be forced to adopt systemd to keep KDE, or else Pat will be forced to abandon KDE (I believe he still uses it daily). A lot of Slackware users use KDE, so this stands to affect the entire distro, its maintainers, and its users.
This fucking sucks, and I don't even use KDE myself.
(Score: 4, Insightful) by melikamp on Friday February 20 2015, @04:47PM
Slackware does not use the bleeding edge KDE, so it will be years before PV's hand is forced. During these years the cool heads may well prevail and hack KDE back into interoperability. Do not panic, keep calm and carry on, etc. etc. etc.
(Score: 2) by nightsky30 on Friday February 20 2015, @05:36PM
Can we fork KDE and call it FKDE? The "F" can stand for Fork whatever you think is appropriate.
(Score: -1, Troll) by Anonymous Coward on Friday February 20 2015, @06:52PM
Call it "F**k you". Where the two stars stand for "or", of course. ;-)
(Score: 0) by Anonymous Coward on Friday February 20 2015, @11:35PM
Maybe just rename KDE, SDDE (Systemd Desktop Environment) since they decided to allow him to do the forking.
(Score: 4, Interesting) by arashi no garou on Friday February 20 2015, @05:41PM
During these years the cool heads may well prevail and hack KDE back into interoperability.
The same thing was said about systemd not long before it was forced on the vast majority of GNU/Linux users. I'm not giving up on Slackware, I'm just acknowledging that Pat and the team will likely have a huge burden on their hands soon enough, no matter which way it goes (dumping KDE altogether, heavily patching it to work around systemd, or caving and accepting systemd and all that that entails).
And while Slackware releases don't track the bleeding edge, often -current does. I just don't want to see Pat suddenly stop development on the OS as a whole because a hugely important project gets infected with a malaise he's otherwise been able to avoid. He shouldn't have to commit already limited resources to fixing a problem that wasn't broken to start with. Why a DE of all things needs systemd hooks boggles the mind. It makes me glad I use a pretty bare WM in Slackware.
(Score: 5, Insightful) by melikamp on Friday February 20 2015, @07:27PM
Forced by whom? I am neither a systemd supporter nor an LP or KS sympathizer, but the nature of the debate forces me to take their side on some occasions. For what you are saying, the distributions are at fault. The "cabal" cannot twist anyone's hand outside of the Red Hat universe. Debian users in particular are stuck with systemd because of decisions made by their own committee. No one was forcing anyone to adapt systemd, let alone adapt it so soon. As Slackware users, me and you know full well that nothing of practical significance depends on it as of yet.
I agree with some of this, but not all. I agree there is a risk that Slackware will suffer as a result of this shuffle. While I don't use KWin, I understand that losing it is unacceptable for great many users. I also agree that replacing the current init by systemd may be too taxing for the Slackware development team.
But I strongly disagree with "infected" and the rest of the value-laden BS that flies thick in all of these discussions. From the technical standpoint, there is nothing seriously wrong with systemd, meaning that whatever faults it has today can be fixed tomorrow. (For example, binary logs are stupid, but there is nothing preventing admins from keeping text logs as well.) In fact, I see nothing of value in the boilerplate bash code used in Slackware init, so IMHO here's something systemd got right. The "cabal"'s attitude may be rotten at times, which makes fixing bugs harder than it needs to be, but again, this is not a show-stopper as long as the software is free. At the end of the day, users do not care how their machine boots, as long as it does.
So once again I'd like to point the finger at the real offenders: KDE team in this case. They are free to decide whether they want to be portable, and to what extent, and if they limit themselves to Linux+systemd, well, whose fault is that? It's not an "infection", it's just one of the half-a-dozen DEs going non-portable. Sad, but you know what? Fuck it. We'll just keep using our openboxes and what not, while some of us will design and build yet more portable DEs.
(Score: 5, Insightful) by arashi no garou on Friday February 20 2015, @07:51PM
From the technical standpoint, there is nothing seriously wrong with systemd
I said as much in another comment; the biggest problem in my mind with systemd is a philosophical one, not a technical one. It's about power and control, more specifically about a few people taking the Linux community in a direction the community doesn't necessarily want to go. I say it was forced on us because quite simply, it was; when Debian adopted systemd against the will of many of its users and members (several Debian committee members asked for more time to debate the switch and were ignored), much of the GNU/Linux community had no choice but to follow, as Ubuntu and Mint, the two distros with the largest userbase, are Debian based. The whole Debian debacle was when I started really paying attention to systemd and Poettering's motives, and I saw the same tactics used in corporate takeovers (lies, backroom deals, bullying) being used in what is supposed to be the opposite of the corporate world.
Maybe, in the end, systemd will be the technically superior way to do desktop Linux. If so, I'm fine with that. What disgusts me and makes me want to avoid it is all the political bullshit and power plays behind it. That kind of thing doesn't belong in the Free software world, and it most certainly doesn't belong on my systems.
(Score: 2, Interesting) by anti-NAT on Saturday February 21 2015, @05:15AM
The joke of the outrage is that SystemD has been in Fedora since version 15, released in May 2011. As there have been 6 releases since, all including SystemD, clearly the problems the ragers think is going to happen won't. It would have been abandoned by Fedora, or Fedora's users would have abandoned Fedora, if SystemD is as bad as people are making it out to be.
As most people who criticise SystemD repeatedly state falsehoods about it, because they don't actually know what they're talking about (and have no interest in finding out about it), it really says that they're not complaining about SystemD, they're really complaining about change. Technology is always changing, if you can't handle change, go back to pens and pencils.
If the supposed worst happens with SystemD, (a) it can be forked and (b) its API calls are clearly available to be reimplemented.
Nobody is forcing other distributions or software to adopt SystemD or its components - they're doing it because they can see benefits in comparison to their existing methods.
Nobody is forcing you to stay using those distributions if you don't like the direction they're heading either. I've changed distributions plenty of times since 1993 - I've used Slackware, Redhat, Debian, Ubunto, ArchLinux and now use Fedora. It's not hard, and interesting to find out the different ways the same problems are solved.
(Score: 0) by Anonymous Coward on Sunday February 22 2015, @08:40AM
Fedora won't abandon it, because RH needs it for its security wankery sales pits to the MIC.
Fedora seems to always be on the forefront of adopting something "security" related, and/or pushing stuff that is related to same.
Lately there have been a whole lot of RH people screaming, under the guise of Gnome or Wayland devs, "X11 IS NOT SECURE!!!".
Fedora was also on the forefront of adopting SELinux, and it was a massive pain...
And one would suspect that if one traced the lineage of Polkit etc it would lead back to someone on the RH payroll.
But at the same time the Systemd guys manage to add a DNS "client" that is susceptible to cache poisoning. A issue as old as DNS caching, and has known techniques for avoiding...
In essence Fedora is sticking with it because it is "their" project.
Others on the other hand is likely adopting it, or adopted it, back when it was simply a init replacement. These days however it is so much "more". And has a stated goal of reworking the Linux "distro" (more like making them all march in lock step) from the ground up (cramming everything into /usr etc).
(Score: 2) by urza9814 on Monday February 23 2015, @07:31PM
I've had to add a bunch of systemctl commands to my .xinitrc because I couldn't figure out how the hell to get them to start in a predictable order. Network works fine one day, then I upgrade my system and suddenly the services start up in a different order and the network fails on boot...then I update again and it goes back the way it used to be...so now as soon as the system is up I just immediately reboot all the related services in the correct order since SystemD apparently can't figure that out...
(Score: 4, Interesting) by Anonymous Coward on Friday February 20 2015, @09:28PM
No one was forcing anyone to adapt systemd, let alone adapt it so soon.
That's like saying "I'm not forcing you to stop driving a car, I'm just removing all gas stations in a 100 km radius around where you live. You can still drive if you want to. You can even get gas and refill your car to keep driving. It's your choice." True each application can choose to adopt or not adopt to it, but given how tightly integrated it is with certain applications if you have any dependency on one of those applications you are stuck with the "choice" of either not adopting it and manually working around it (driving 100km each time you want to get a patch), or adopting it (stop driving your car). Nominally you have a choice, but only in a superficial sense.
From the technical standpoint, there is nothing seriously wrong with systemd, meaning that whatever faults it has today can be fixed tomorrow. (For example, binary logs are stupid, but there is nothing preventing admins from keeping text logs as well.)
Unless you happen to disagree with the design philosophy of system (i.e. "having it do everything" with the commensurate loss of control and increased system fragility). That can't be "fixed" as such. And in the meantime, you are still using unproven software which may have security holes, stability issues, maintenance issues, or whatever else.
It's not an "infection", it's just one of the half-a-dozen DEs going non-portable.
Calling KDE "just one of the half-a-dozen DEs" grossly under-represents how big and important it is. And the word "infection" is a perfect term given the network effects of dependencies across software packages.
(Score: 2, Disagree) by melikamp on Friday February 20 2015, @09:43PM
The parent post is a perfect example of the unadulterated value-laden cow dung I was talking about, complete with "design philosophy" nonsense. It fails to address the single point I was stressing: distributions independent of Red Hat are adopting systemd by choice, and userland applications create hard dependencies on systemd not only by choice, but also because they, apparently, intend to be unportable just for lulz. Good riddance. There is no doom coming, systemd is just another init, and not the worst one, and while some upheaval will force some users to seek new pastures, what we observe is business as usual.
(Score: 5, Insightful) by Hairyfeet on Friday February 20 2015, @10:24PM
And I think YOU sir have missed the point of many here, which is that the users have said by a pretty damned large margin "We do NOT want this" and the devs have turned top their own users and said "Fuck you, we do not care what you want"...yes this attitude is very disturbing, and when you see distros that are supposedly "stability over all" like Debian jump on the bandwagon and start throwing up appeals to emotion instead of technical arguments?
Well as I have said in other posts everybody can call me a tinfoil hatter (just as they did everybody who said our calls were monitored before Manning) but the combination of timing, coming so soon after Snowden let loose the TLAs best tricks and many are pushing Linux as a platform for secure communication, mixed with the frankly bizarre posting made by devs defending Poettering....I mean for fucks sake LP in one of his own posts said along the lines of "Can't get systemd working on ARM, fuck it shipping anyway" and devs not only didn't condemn him for treating a critical subsystem like systemd like its a fricking videogame patch and busted his ass for sending it out broken but they rushed to DEFEND such Mickey Mouse behavior? I'm sorry but the top tier Linux guys have NEVER been tolerant of the "fuck it, ship it and we'll patych later" kind of cowboy bullshit, they condemn that kind of shit on the Windows side all the time!
I'm sorry but something is rotten in Denmark, the entire dev community is just too quick and too easy and too busy acting like every day is opposite day for me to believe this is a natural or organic change in the landscape. Whether this is the TLAs that pretty much own Red Hat making sure there is a nice easily exploitable back door so that all these "secure communication distros" are just so much warm fuzzy BS, or Red Hat trying to become the big boss? I have no idea. All I do know is I have been keeping an eye on Linux since around 2003 and I can honestly say I have NEVER seen Linux distro devs behave in such a strange and anti-user fashion before, never.
ACs are never seen so don't bother. Always ready to show SJWs for the racists they are.
(Score: 1, Troll) by melikamp on Friday February 20 2015, @10:41PM
This has absolutely nothing to do with either systemd or the "cabal" or anything at all in the sense that it's a completely generic problem, and can only be described as "business as usual". This is exactly how developers relate to users during a software development cycle; this is true for the free software, and 3 times as true for the proprietary spyware. Exceptions are rare and precious. And if you or any of the systemd doomsayers were actually interested in solving THIS problem, you wouldn't make it about your personal hatred of the "cabal" and everything they stand for, would you? You would talk about the community culture at large, problems in communication, structural inefficiencies, etc.
Both GNU and Linux are maturing and growing, and it makes sense that each new change in the ecosystem brings a bigger upheaval, that's all. We transitioned from an ecosystem where many users were also contributors to the one where almost all users are pure users. And pure users are NEVER happy with change, and when there are 100 times more of them, they are 100 times more vocal about it.
(Score: 0) by Anonymous Coward on Sunday February 22 2015, @08:48AM
Not sure how many are adopting them by choice, or by seeing the 800 pound gorilla throwing its weight around and not wanting to be in the way. Systemd is adopting more and more "container" functionality. CoreOS recently used this to launch a rival to Docker, and recent Systemd releases has gained the ability to import Docker containers. RH event stated that the cloud would be a big focus of theirs moving forward. In essence, if you want to be in the server game going forward you better follow RH's lead.
(Score: 5, Insightful) by Arik on Friday February 20 2015, @09:49PM
You're wrong. The design aim of 'throw everything in PID1' is wrong, wrong, wrong. The problems with systemd are inherent in the design philosophy and cannot be fixed without fundamentally altering the nature of the project.
Your binary logs example is actually a good example - against your thesis. In fact, although you can relatively easily get systemd to produce a second set of logs, in text, and this *appears* at first glance to moot the objection, in fact it is completely unsatisfactory. In case of system crash or failure to boot - the very cases where the logs are most needed and it's most important that they be in text - this setting fails as well.
The distinction you make between 'technical' and 'philosophical' objections is also a mirage. In fact, the 'philosophical' objections are actually technical. We do not oppose overloading the init system with all sorts of other functions because it offends our esthetic sensibilities - we oppose that because we know it is the opposite of good engineering and will inevitably result in bugs and bad behavior.
After you stomp bugs for a decade or two maybe you think to quit leaving out so much food for them.
If laughter is the best medicine, who are the best doctors?
(Score: 2) by melikamp on Friday February 20 2015, @10:11PM
I am not an OS designer and my personal opinion about the technical merits of systemd is pretty worthless. I can see, however, that major distributions are adopting systemd one after another, motivated in large part by what THEY perceive as technical advantages, and the doom is failing to materialize. I also read the criticism of systemd by people who are qualified to judge it on technical issues, and they seem to agree on the fact that it's not perfect, but basically works. I also knew you have no idea what you are talking about when you mentioned the "design philosophy". Would that be the "UNIX design philosophy", by any chance? "Do one thing" and blah blah blah? Because Linux (just 1 example!) spat all over that, but I don't hear you complaining.
If what you are saying is true, then the bug can be summarized as follows: when boot fails, logs are unavailable, period. What does it have to do with logs being binary or text? I am not saying systemd is bug-free, I am just saying YOUR objections to it make no fucking sense to me.
Even I can tell you don't seem to understand (or may be don't even care to try to understand) how systemd is designed. No, you don't have any technical objections, because if you had one, you'd let us know what it is, and then we would see that like all the other inits, systemd has its pros and cons.
(Score: 5, Insightful) by hash14 on Saturday February 21 2015, @04:36AM
I can see, however, that major distributions are adopting systemd one after another, motivated in large part by what THEY perceive as technical advantages, and the doom is failing to materialize.
The doom will most likely materialize in the same form as Shellshock or Heartbleed or any other of the many other high profile vulnerabilities we just saw last year. But LP would eat his shoe before admitting he's wrong so nothing will get done about it, plus the way they see any attempt to fix their disaster as WONTFIX NOTABUG just shows how adamant they are about taking over the whole Linux ecosystem and tanking it.
But I will be far far away on either Gentoo, BSD, or some other alternative when this disaster strikes, so I can't wait to see the shit hit the fan.
I also read the criticism of systemd by people who are qualified to judge it on technical issues, and they seem to agree on the fact that it's not perfect, but basically works.
Sounds a lot like Windows, which seems to have yet another critical vulnerability every other patch cycle. Why was Debian the most successful project because it was taken over by Red Hat? Because they strove to make it perfect. There is a point to the pain in the labour - because otherwise, you just have a crappy platform that's full of holes, and which nobody understands which is a hacker's dream. Just wait and see - eventually, Red Hat will be reduced to an open source clone of Windows. That's great if all you care about is money and market share, but when it comes to getting shit done, those who want real assurance of stability, security and productivity will be doing something completely different.
(Score: 0) by Anonymous Coward on Saturday February 21 2015, @06:36PM
THIS.
It is the new blossoming openSSL project catastrophe ripe for the inevitable DOSing of the entirety of Linux at some point in the future.
Speaking of openSSL, SystemD might want to add that to the load of crap it handles, or at least contact the openSSL team and let them know SystemD needs to be one of their dependencies, because FUCK KNOWS WHY.
(Score: 4, Informative) by Arik on Saturday February 21 2015, @05:14AM
There are no technical advantages of any consequence, and if you think technical advantages are driving adoption you have not been paying attention. Politics is driving adoption and that is plain as day.
Disagree? Name one.
"If what you are saying is true, then the bug can be summarized as follows: when boot fails, logs are unavailable, period. What does it have to do with logs being binary or text?"
It has everything to do with binary logs vs text logs. When a system crashes with a text file open, the result is human recoverable and readable. When a system crashes with a binary file open, the same is not true.
The right way to do this, assuming there was someone with a compelling need for the binary logs in the first place (which may or may not be true,) would be to do the text log as primary, then mirror it to a binary log.
"I am not saying systemd is bug-free, I am just saying YOUR objections to it make no fucking sense to me."
You may need more experience before you will understand them. The design guarantees bugs, I dont need to wait around for 10 years for the bulk of them to be found to know that they are inevitable (or to anticipate that the cabal will WONTFIX the bulk of them.)
If laughter is the best medicine, who are the best doctors?
(Score: 0) by Anonymous Coward on Sunday February 22 2015, @08:42AM
Could it be that Slack ends up adopting Trinity rather than follow KDE forward?
http://trinitydesktop.org/index.php [trinitydesktop.org]
(Score: 2, Insightful) by Anonymous Coward on Friday February 20 2015, @04:59PM
>suggests that either Slackware will be forced to adopt systemd to keep KDE, or else Pat will be forced to abandon KDE
No need of either; there are enough skilled people in Slackware community to work around any such contrived dependencies.
Just the same as Skype's requiring PulseAudio absolutely had not resulted in us "adopting" the beastly thing. Instead, in mere days, we have developed workarounds, and have no problem since.
(Score: 2) by Nerdfest on Friday February 20 2015, @07:39PM
Sorry, I meant Kubuntu. All use both KDE and Xfce and am too used to typing both.
(Score: 0) by Anonymous Coward on Sunday February 22 2015, @12:57PM
One XFCE dev actually forked the consolekit code, and has done some effort towards putting in support for logind dbus calls etc.
https://erickoegel.wordpress.com/2014/10/20/consolekit2/ [wordpress.com]
(Score: 3, Insightful) by frojack on Friday February 20 2015, @09:46PM
assuming a shim layer is not being implemented that will convert time and date API calls
I really can't understand why that approach isn't being taken.
Write it once, and done, no combing through your code to change every instance of an ever increasing number of functions that are handled by multiple different init systems.
This has been the prevailing method of dealing with changes in underlying structures, libraries, compilers, etc since before the systemd tyrants were born, since before linux was born. These shims are tiny, usually argument re-arranging, a jmp and a ret, and very little else. Only occasionally is any significant code or data structures needed.
No, you are mistaken. I've always had this sig.
(Score: 0) by Anonymous Coward on Sunday February 22 2015, @08:53AM
How deep does the rabbit hole go? Will we end up implementing systemd to avoid using systemd?
(Score: -1, Flamebait) by Anonymous Coward on Friday February 20 2015, @07:22PM
Did you learn from your experience and turn down your anti-systemd hyperbole level, or are you just going to keep blundering ahead with lies, even after falling on your face?
One thing becomes more and more clear as more software takes these decisions: The people in the "loud pundit" class have different views of systemd than the people actually in the positions to make technical decisions. And members of the "loud pundit" social category value each others pejoratives more highly than the technical points of the people actually in possession of knowledge of the details. What really blows the doors off is that they defend SysV init as some sort of holy cow. Uhm, yeah. If they're not embarrassed the first time they say it, they're probably never going to go into the technical details far enough to even understand the decisions.