There were until recently, apparently. Powerdevil and pm-utils. Apparently KDE preferred the systemd way, for whatever reason.
Probably because almost nobody is working on non-systemd distros. Their entire OS plumbing layer from ConsoleKit to power-management has been bit-rotting for years with the non-systemd distros totally ignoring the pleading from upstream projects.
It is hard for upstream projects to support the non-systemd distros when they ignore or outright refuse to do any work.
I think there is roughly one non-systemd developer (the CK2 maintainer) that submit patches to KDE so KDE can have basic functionality on non-systemd distros.
But sure, just blame systemd for the non-systemd distros total apathy for maintaining their own software.
Funny thing is the question is not about getting new stuff, that stuff. Just keeping running what is there up.
No, the old KDE stuff works just fine with CK. So if you dare to run abandonware like CK with no security fixes or bug fixes, just keep on doing that. It is the new stuff, like KDE 5 that are giving problems because the non-systemd distros have ignored all necessary work to be able to support KDE 5.
We are talking 4 years of total neglect where the non-systemd distros have done nothing whatsoever. Now realities are starting to bite the non-systemd distros in the ass. Yet, people like you are still in total denial that software actually needs to be maintained, just like you and so many other non-systemd users, have totally ignored it when upstreams project like KDE and Gnome have pleaded for years that the non-systemd distros did even some minimal work so they could still be supported.
Instead of facing realities and start working on solving stuff, the non-systemd users whine and bitch about systemd while making elaborate conspiracy explanations for why things suddenly no longer works as expected.
Sure, self-victimization is easy, just accuse the bad systemd developers for everything and absolve yourself for having any share in why stuff is bit-rotting. Such reactions is probably the main reason why the non-systemd distros are crumbling.
So what. It is hardly a problem that Linux developers financed by Linux money develops Linux software. BSD/Solaris/AIX does exactly the same.
In this case BSD and non-systemd distros will have to make their own tiny contributions to upstream projects like KDE on order make things work. Sure, they would like the systemd-developers to work for free for them, but that won't happen. The BSD alternative to the systemd software stack called "systemBSD" is of course totally incompatible with Linux.
Basically the non-systemd distros and BSD are getting a full DE for free. All they have to do is to provide the rather minimal infrastructure and OS services that the DE's require, just like the systemd-distros does.
The problem the non-systemd distros are facing with running a modern desktop are entirely their own fault. Gnome and KDE developers pleaded for years that non-systemd distros or anybody else should start to maintain ConsoleKit which now have been abandonware for almost 4 years.
The non-systemd distros ought to realize that it is entirely up to them to maintain their own alternative software stack, and even help out upstreams projects like KDE to support them. At the moment only a single guy is maintaining CK2 and sending patches to KDE so KDE will work with CK2.
People whine about "Linux is all about choice", but when it comes to maintain those choices they all shy away with a "I am not a programmer", "No time", "No money" etc.
So if you want to run a modern desktop in 2016 on a non-systemd distro, you better start contributing towards it.
The same thing goes for OS containers, the new cgroups API and what not. If you want that stuff, don't expect it to magically being made by benevolent pixies nor developers from systemd-distros.
Not really. But what would be the point in that? If you want unindexed text logs just direct journald to forward all log-messages to syslog, and turn off the binary journald logs. All that it requires is a trivial change in journald.conf
The problems with journald outputting text logs are several: The most important thing is that it is more or less impossible to do right during early boot where journald is receiving messages from both/dev/ksmg (kernel) and/dev/log. That is why the kernel stores all its early boot logs in binary form in the kernel ring-buffer that are then later extracted by special tools like dmesg.
Another problem is Linux kernel limitations on handling devices. Only one program at a time can read from/dev/log, or messages will lost and randomly misdirected. That means that journald that collects logs from/dev/log before rootfs is mounted and Rsyslog running, can't later hand over control of/dev/log to Rsyslog without losing log messages.
The rather ingenious thing about journald is that it can collect and collate/dev/log info from earliest boot and in initrd, to after the rootfs has been unmounted. You can also have full logging available in initrd which is rather nice if you have to debug from there.
If you want "metal-to-metal" logging something designed like journald is a good idea: If you made journald to be a super-syslog client with text output, you would prevent end-users in choosing between Rsyslog or Syslog-NG or whatever they can use with journald now. Same if they cooperated with the Rsyslog team so Rsyslog could collect from early boot and pivot back and forth from initrd like journald can. Then you couldn't use syslog-ng etc.
As systemd's journald is designed you can choose any syslog(3) compatible logger to work with journald. You can freely choose between either binary or text logs for e.g. legacy scripts to work.
I am a US citizen as frustrated about unauthorized domestic surveillance as anyone. But this summary goes too far. Finding, keeping and using vulnerabilities is exactly what the NSA is supposed to do, and there is nothing questionable about that behavior. If the submitter wants the government to have a group that finds and discloses vulnerabilities as part of its remit, then make a case for creating such a group. Don't saddle the NSA with the job.
Well, you are wrong in thinking that it isn't the job of NSA to disclose at least certain vulnerabilities.
NSA's job description also include counter intelligence. That means it should also do its best to protect US government servers, including the US military and potentially too, civilian US military contractors, who may have highly valuable knowledge on their servers.
So certain vulnerabilities affecting software that the US government uses, are circulated back into the software community, it is simply in the interest of NSA as a counter intelligence agency to do so.
ATM's, industrial and medical appliances etc. No personal experience with embedded OS/2, but apparently it was very attractive to use for making GUI's with often critical data input, combined with running on x86 and PPC boards that made it easy to develop for. The underlining OS technology, like the kernel was without doubt the best and most stable running on x86 for quite some time.
OS/2 is relegated to neckbeard's still maintaining their Amigas and C/64 machines playing block/character graphics games.
I really don't think so. The commercial interest in OS/2 isn't in desktop use or retro computing, but embedded and industrial appliances where OS/2 thrived years after the general public had forgotten it.
This new release is about protecting investments in such OS/2 based equipment.
The release is probably mostly for embedded use where OS/2 had quite some use since it was so much better and stable than contemporary MS Windows.
I quite liked OS/2 in its time and found it very superior to contemporary Windows versions.
Re:Why do you like KDE?
on
KDE Turns 19
·
· Score: 1
I have it the exact opposite way. I find KDE apps superior to any other alternatives in most respects.
Krusader and Dolphin for file-management are better than anything else I know. Superb integration like packing or unpacking files or encrypt them or enque them in Amarok etc.
Kmail, and the entire PIM suite with calendars and contact management is better than anything else I have tried.
Konqueror isn't bad at all, and much faster and lightweight than Firefox. The absolute main reason why I use Firefox as my main browser is because of the many great add-ons. For many other things like file-management, bookmarks and passwords, Konqueror is actually better.
System wide password management with kwallet is much, much better than each and every program implementing similar systems.
DigiKam for photos and Okular for pdf's, Kid3 for audio-tagging, K3b for disc-burning and ripping, KRename for advanced mass renaming, Kstars for astronomy, are better than anything else I have tried.
Konsole, Kate (editor), Okteta (hex editor), Amarok (music player) are also favorites of mine.
In short, KDE, including Plasma really works well for me and my work-flow. Personally I don't really like XFCE; almost no desktop integration and no apps, inferior file-management and a UI metaphor that reminds me too much of Win 3.11. IMHO Plasma beats in every aspect when it comes to virtual desktops, shifting between programs, program services and app integration.
There is no comparison to the British Boer War concentration camps and the Nazi camp system, that including industrial murder machines like Auschwitz and Majdanek.
The British Boer War concentration camps were bad and thousands of women and children died in them. But unlike the Nazi camps, there was never a deliberate policy of starving or working the inmates to death.
So there was not only a huge difference in the number of dead (many millions vs around 26.000), but also a crucial difference in _why_ the inmates died; in the Nazi camps they where deliberately target for destruction through starvation and gassing, while the British Camps where merely badly and incompetently run, so the inmates died of epidemics and neglect.
Another crucial difference is that when the British politicians (both ruling party and the opposition) discovered what was going on, they intervened and brought the camps (and their mortality rates) in order again.
The thing is, you don't need a 4K display to work on variable DPI support, you just need to make sure that the apps you have responsibility for DO IT!
Sure, you don't need a 4K display to work on HiDPI support, but it would probably help with the motivation though. Remember, KDE is mainly coded by volunteers that have full time jobs doing other things, and mostly their work queue is extremely long.
Personally I am quite pleased with KDE 5/Plasma 5. As usual the KDE developers delivers a lot of new stuff between each point release. KDE 5 (Apps, Plasma 5) is already in much better shape than KDE 4 was at a similar point back in 2008/2009.
Sure, they work better now than they did 6 month ago, but HiDPI is still a work of progress on Gnome and Unity (and KDE too).
As I said, every iteration of those Gnome/KDE brings better HiDPI support. But the devil is in the details and certain apps have hardcoded assumptions on font sizes and DPI that doesn't work in HiDPI. It will take quite some time to shake out all the visual bugs.
Things move somewhat slowly simply because there are so few developers working on it and even fewer of these DE developers own 4K displays.
There used to be the understanding that releasing soon made for pending features. Bugs, on the other hand, have always been a matter of the quality and seriousness of the developers involved.
New features=new bugs. The quality of FOSS software like KDE have really improved over the decade. I used to expect application crashes and even DE crashes as a matter of fact, these days such crashes are much rarer. Gone are the usual huge memory leaks too. Everything from documentation to stability have improved much over the decades.
What people are complaining about these days are mostly subtle bugs or missing features like "widget X" no longer work like it used to do.
I find it sadly typical of the times that each and every Linux DE discussion on Slashdot quickly are degenerating into rants on how bad the DE is because {insert trivial thing} isn't working like expected. Usually the rants are from ex-users too. Why they feel a pressing need to discuss and rant about a DE they don't even use is something of a puzzle to me.
Something in peoples attitude have changed in the Linux "community"; these days it is all about negative rants, bug-whining and trash-talking of FOSS projects and its developers.
The British never had a policy of extermination. There was never British Death camps like Majdanek or Sobibor, nor British units like the Nazi Waffen-SS 1. Brigade or the Einsatzgruppen, that toured eastern Europa systematically killing off whole villages by forcing the victims to dig graves and then shoot them in groups so their bodies was layered as "packed sardines"; shooting the men first, then the women and children. There was never a British "Babi Yar" "https://en.wikipedia.org/wiki/Babi_Yar massacre.
The British colonial rule may have been misguided, paternalistic and sometimes brutal, they never committed mass murder on populations for being the wrong race, nor did they have any policies that willfully would kill off civilians through mass starvation.
Really, thinking that British colonial rule is even remotely comparable to the murderous Nazi regime shows a sad lack of understanding how gruesome and genocidal the Third Reich was in both thinking and deed.
There has also never been anything in both scale and intentions that have ever matched the Nazi regime when it came to Genocide, not even Stalin's USSR.
While the Armenian Genocide was horrible, it was dwarfed by the Nazi Genocide by at least a factor of ten. The German occupation killed at something 14 million civilian Russians alone.
Ubuntu's desktop releases are hardly "bleeding edge."
Well, if they wanted a stable KDE release they should have chosen KDE 4. KDE 5 (KF, Apps etc) are still a work in progress.
But people (including me) wants new and shiny, so most distros tend to ship the newest Linux DE instead of the old boring stable one.
Face it. The KDE team screwed up. All software teams do, sooner or later. They post a broken "release", and it gets shipped.
I disagree and I don't think you really understand how FOSS DE and software development work; all the major DE versions starts with feature regression, rough edges and lots of bugs, and then later start to stabilize as users report bugs and developers catch up. Gnome 3 happens to be further into the stabilizing phase since it is older, but it certainly was released with both bugs and features missing. Both Gnome 1, 2, 3, and KDE 1, 2, 3, 4, 5 followed the above pattern without exception.
This is not because KDE or Gnome developers "screws up", but because this is how FOSS DE software with basically no funding has to be developed; release early and release often, have the users report bugs and supply RFE's and general feedback for what is important to fix.
If people rage-quit instead of reporting bugs Linux development will suffer.
Besides, it's not like there aren't a bazillion desktops out there waiting to replace one that's been screwed up.
Really? As I see it there are only two DE's out there with any kind of application development going on and that is Gnome and KDE (and a few Qt apps).
If KDE disappeared then there would only be Gnome and GTK apps left for Linux. (Qt would probably disappear too since they would no longer have any economic incentive to support Linux anymore).
I don't any FOSS DE have fully working HiDPI/high resolution display support yet. They are getting better for each release however.
Again the point is that few people are working on Linux DE's since nobody earns money on desktop Linux and desktop Linux users generally are misers when it comes to donate money to DE work. I think many board games or small computer games raises more capital on Kickstarter than all Linux DE's together gets in user donations.
Yeah, interesting that people want bleeding edge and then complain about bugs and missing features. KDE 4 works fine (and is upstream LTS now).
I don't know if it is a good or bad sign that people expect FOSS DE's to be mature and finished before they are released, just like commercial DE's like MS Windows.
There used to be an understanding that FOSS software projects needs to release early and often, and that this sometimes meant releases with missing features and bugs.
Anyway, people should remember how few developers actually working full time on Linux DE's (the number is probably lower than the number of Baristas employed by Microsoft).
It never really ceases to amaze me how good the KDE desktop and its applications are compared to products from multi-billion dollar companies.
So? The Nazi Germany didn't do anything that other countries, including Britain, France, Netherlands, Belgium, etc., had not also done. The only difference is that Hitler did it to white people.
More people were killed in forced labor on rubber plantations, than in all the Nazi death camps combined.
That is misleading; those figures for Congo are "depopulation" losses, not people killed. No other comparison points implied, but several western countries these days are being "depopulated" due to falling birth numbers, that doesn't mean there are secret massacres going on. "Depopulation" also includes population losses from people deciding to only have 1-2 kids instead of 3-4 kids needed to sustain the population.
Sure, there were huge atrocities going on in Congo, but the numbers you are quoting aren't only about people being killed as forced labor on rubber plantation as you claim. According to your cited source, the majority died of "sleeping sickness", still a killer disease in Congo these days.
The Death camps however where targeted killing machines, murdering people sometimes minutes after they had arrived by train. They also killed millions of people in a very short time, basically a couple of years, while the Congo depopulation took 40 years. The Nazi war on the eastern front killed +27 million people in 3-4 years in comparison.
Also of interest is that the (at least) 6 millions Jews killed was just the warm-up, since Mischlinge (half/quarter/etc Jewish descent) was next, and with the "General Plan Ost", the Nazi regime basically intended to exterminate all Slavic people from Poland to the Ural mountains except for a small amount that was to be kept as slaves.
Saying that Hitler and the Nazi regime only did what the British, Belgians etc, had done previously is just plain out wrong. There has never been anything remotely like the Nazi Death camps before.
There has also never been anything in both scale and intentions that have ever matched the Nazi regime when it came to Genocide, not even Stalin's USSR.
Most of it is just the usual LKML noise when something important is merged
No, it isn't.
Yes it is. Seen it so many times over the decades, even Alan Cox said on G+ that it was just business as usual, with kdbus standing a good chance of being merged when the raised criticism was dealt with.
First, you must remember that several of the "noise makers" aren't kernel developers at all. Everyone can write to the LKML, though that doesn't mean they are taking seriously.
Secondly, new important things are often put through the grinder; that is how it works on LKML. But it doesn't mean that all raised criticism is valid either; much depend on the defense of the existing code too.
Until now the kdbus developers have either incorporated actionable criticism into code/design/documentation changes, or defended their stance very well. Kdbus have clearly benefited from this process and is now being "beta tested" by end-users too. So when it finally gets merged, it will "land running" so to speak, with more than usual real world testing and userland code.
You are misinformed. The cgroups change has nothing to do with either dbus or kdbus, nor systemd.
That's Lennart speaking there. Claim everyone is misinformed when a raw nerve is touched. Lennart has clearly stated that he sees systemd as the one way of configuring cgroups in userspace and kdbus is the way that will effectively be locked in as the interface between kernel and userspace. Can't possibly have competing ways of doing this.
It seems you haven't understood the basics of this. Let me clarify: 1. On systemd-distros it is systemd that will be the sole cgroups writer, and the sole owner of the shared bus as setup on kdbus. Poettering are only stating the obvious about this, because realistically that is the only working option.
2. Non-systemd distros can make their own cgroups writer or mechanism for controlling kdbus. They are free to do so, and the API's they use will be stable kernel API's. systemd doesn't in any way prevent them for making their own software for controlling cgroups and kdbus.
This is the way it is supposed to be; everyone makes their own stack. This is what gives competition, not the rather strange assertion that systemd developers somehow should make a independent cgroups writer that works on all Linux distros.
As I said, cgroups and to a lesser extent kdbus, are tremendous opportunities for the non-systemd distros to make their own stack (I am thinking containers mostly) that might even attract both capital and paid developers.
You will find that the change is backed by all kernel developers who thinks exactly the same as Tejun.
Bollocks. I find a lot of kernel developers who have issues with it though. See, easy this isn't it?
Really, I challenge you to find even single kernel developer who thinks the old cgroups API is secure, and who doesn't agree on Tejun's proposal as the only way forward. AFAIK, both Al Viro and Andy Lutomirski discussed this recently on LKML.
kdbus is great technology, especially for the non-systemd distros.
Kernel developers who have attempted to review the code have stated otherwise, and kdbus is simply not going to be merged until those concerns are addressed. What happens is things go silent, a patch is pushed to Linus with no changes and the mailing list thread kicks off again with the response "But it does this in userspace, so this is how it has to be and of course, putting it into the kernel will automatically make it go faster, because, you know, KERNEL!". There are a litany of huge issues with it too numerous to discuss here.
Most of it is just the usual LKML noise when something important is merged, people want to test even the basic assertions of everything. Don't take it too seriously if eg. Al Viro says that some code is bad. His standard is that at best, all code sucks badly, with most codes being even worse than that.
It looks like the usual Linux kernel process works fine, with kdbus being improved really well from every round of patches on LKML, especially the two first rounds. You will find that all actionable kdbus criticism is being dealt with, Greg KH is a seriously experienced kernel developer who doesn't shy away from technical problems.
Anyway, the point is that having a shared bus kernel IPC is a good thing that non-systemd distros could benefit from. Instead they try to trash talk it, pretending it isn't good and doesn't solve any problems. In short, repeating the same total failure tactic as they used against systemd and PulseAudio. So kdbus seems to be yet another technology that are "taboo" for the anti-systemd crowd. Their loss really.
Using the Spinal Tap line of "But it goes all the way up to eleven" to any argument is all the systemd proponents have. It's quite sad that we're going to spend a great number of years of pai
It is the cgroups maintainer Heo Tejun that wanted the change. Systemd has nothing to with it. Sure, systemd developer are working on a user side implementation of the new API, but that is it.
Alas, the net effect of it is that the single interface to it is through systemd and dbus, and Lennart claims in that passive aggressive way, as you do, that it is the 'cgroup maintainer' who wants this. However, this 'change' has been bandied around for at least a couple of years now largely because it looks as though they thought kdbus would get a free pass into the kernel. We all know that's what this means.
You are misinformed. The cgroups change has nothing to do with either dbus or kdbus, nor systemd. You will find that the change is backed by all kernel developers who thinks exactly the same as Tejun.
Nor is systemd the "single interface" to the new cgroups API. Anybody can make their own cgroups "writer" since it is a kernel feature. Just because systemd takes advantage of kernel features doesn't mean anybody else can't.
Seriously, you guys who for some reason don't like systemd (I don't care why) should stop spreading misinformation that really hurt your own cause.
Perhaps it feels good to tell a narrative how systemd usurps everything and makes all other development impossible and that in the future only systemd will be able to use the new cgroups API, but this will only discourage any non-systemd development.
The systemd-opponents seems too busy in burning all bridges, both behind and in front, dismissing technology just because systemd happens to use it; cgroups, dbus, kdbus , Capabilities(7), dynamic device handling (udev), service management, declarative text config files etc. is all bad because systemd uses them.
It really leaves very little room for non-systemd developers, and basically means that non-systemd distros will completely stagnate with obsolete technology.
kdbus is great technology, especially for the non-systemd distros. If you think otherwise you haven't studied the project. Same with the new cgroups interface. There are some really good opportunities there too for the non-systemd distros to make something interesting with that, that could attract commercial developers.
The negative campaign against systemd have been an utter failure from the start. You guys should have concentrated on positive contributions in alternative development years ago. And you should have the cool, dispassionate look on systemd that would enable you to steal and copy every good idea from that project.
Is there anything you don't like about systemd, or is all you can do defend it? Are you blinded into thinking that everything about it is good?
Most of it is in the details, like systemctl having the action command as the first thing instead of the last like this:
"systemctl/stop/ example.service"
The reason is probably globbing so you can expand a lot of service files one after another, but still, using Bash the workflow isn't perfect since I used to recall the previous command from the stack with ctrl+r and then edited the action command. I haven't found an easy workaround yet. "^start^status" kind of work but is cumbersome and can't be recalled, only the expanded command.
It is also hard to keep track of systemd progress since things are developed with quite some speed.
From a more philosophical standpoint, I wished that systemd actually had something that even remotely looked like competition. It is really good for software projects to have competition; it enables projects to "steal" good ideas from each other and not sag behind in features. Not having competition may lead to complacency and stagnation.
But I was completely wrong in my assertion that such a competition would arise from the non-systemd distros. I even fear for those distros ability to even maintain existing stuff when the commercial distros stops maintaining their non-systemd software stacks.
All the init-systems in use at the time where just "slightly improved SysVinit" style init-systems.
You're missing the point, deliberately I hope because the alternative is too pathetic to contemplate. Those init systems were in use at the time because you could swap between them freely. Systemd deliberately breaks that state of affairs and that is what is primarily wrong with it.
It is trivially easy for upstream projects to make their daemon support both systemd and SysVinit, in fact, if they don't change anything then everything is as before, with distros providing both scripts or service files. The whole point with systemd is exactly it is backwards compatible with SysVinit, even though it is quite different.
You could never easily switch between between SysVinit and other similar inits, simply because there never existed init-agnostic scripts nor distro-agnostic scripts. You simply can't use OpenRC scripts on SysVinit.
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.
Proper responsibility? No, you have that wrong. They did everything they had to do.
I strongly disagree. SysVinits "simplicity" was exactly because it left all complexity to others to fix. I won't dwell with PID problems, daemonizations or other classic criticisms of SysVinit, some dating 30 years back, but show one example:
As you know, daemons need special (root) privileges in order to access port-numbers below 1024. This is for security reasons. The backside of this is that the daemon then needs high privileges to run. Enter setuid and similar Posix syscalls; they have basically been demonstrated to be impossible to use in a safe manner, and have provided decades of remote exploits of Linux for the same reason. Then came Capabilities which meant setuid root programs could be ditched for that, but Capabilites still means the Daemon can freely talk through low port numbers, so spammers have for years exploited this to install spamming smtp servers on exploited hosts or serve malware from port 80.
systemd on the other hand, can give the daemon a low port-number through a socket so that all such low port-number privileges can be completely dropped; even if the daemon is exploited, it can't send spam through a low port number. Much more secure, and it even makes things much less complicated for the daemon writers. With SysVinit, all the daemons had to implement code dropping privileges, which meant 1000's of different, bug-filled and often insecure code implementations. With systemd, the daemons can let systemd take care of all that. I think that is the right approach; daemon writers want to make awesome programs that does things that interest them, not fiddle with hard to understand low-level system programming. In any case, it is bound to make things much more secure.
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.
Oh great, more influence of systemd shitting up my Linux. Just want I wanted to hear about. So instead of a simple, working interface to cgroups, they want to make it harder to use. Why would you do that? Just to make systemd look more useful? You make it harder to do what they do in a script so that people like me can't say "but a script could do that"?
It is the cgroups maintainer Heo Tejun that wanted the change. Systemd has nothing to with it. Sure, systemd developer are working on a user side implementation of the new API, but that is it.
The main problems are security and bugs in allowing multiple controllers/writers. It just didn't work since there are too many ways to get in
Slashdot Mirror
There were until recently, apparently. Powerdevil and pm-utils. Apparently KDE preferred the systemd way, for whatever reason.
Probably because almost nobody is working on non-systemd distros. Their entire OS plumbing layer from ConsoleKit to power-management has been bit-rotting for years with the non-systemd distros totally ignoring the pleading from upstream projects.
It is hard for upstream projects to support the non-systemd distros when they ignore or outright refuse to do any work.
I think there is roughly one non-systemd developer (the CK2 maintainer) that submit patches to KDE so KDE can have basic functionality on non-systemd distros.
But sure, just blame systemd for the non-systemd distros total apathy for maintaining their own software.
Funny thing is the question is not about getting new stuff, that stuff. Just keeping running what is there up.
No, the old KDE stuff works just fine with CK. So if you dare to run abandonware like CK with no security fixes or bug fixes, just keep on doing that. It is the new stuff, like KDE 5 that are giving problems because the non-systemd distros have ignored all necessary work to be able to support KDE 5.
We are talking 4 years of total neglect where the non-systemd distros have done nothing whatsoever. Now realities are starting to bite the non-systemd distros in the ass. Yet, people like you are still in total denial that software actually needs to be maintained, just like you and so many other non-systemd users, have totally ignored it when upstreams project like KDE and Gnome have pleaded for years that the non-systemd distros did even some minimal work so they could still be supported.
Instead of facing realities and start working on solving stuff, the non-systemd users whine and bitch about systemd while making elaborate conspiracy explanations for why things suddenly no longer works as expected.
Sure, self-victimization is easy, just accuse the bad systemd developers for everything and absolve yourself for having any share in why stuff is bit-rotting. Such reactions is probably the main reason why the non-systemd distros are crumbling.
>More specifically, systemd is Linux-only.
So what. It is hardly a problem that Linux developers financed by Linux money develops Linux software. BSD/Solaris/AIX does exactly the same.
In this case BSD and non-systemd distros will have to make their own tiny contributions to upstream projects like KDE on order make things work. Sure, they would like the systemd-developers to work for free for them, but that won't happen.
The BSD alternative to the systemd software stack called "systemBSD" is of course totally incompatible with Linux.
Basically the non-systemd distros and BSD are getting a full DE for free. All they have to do is to provide the rather minimal infrastructure and OS services that the DE's require, just like the systemd-distros does.
The problem the non-systemd distros are facing with running a modern desktop are entirely their own fault. Gnome and KDE developers pleaded for years that non-systemd distros or anybody else should start to maintain ConsoleKit which now have been abandonware for almost 4 years.
The non-systemd distros ought to realize that it is entirely up to them to maintain their own alternative software stack, and even help out upstreams projects like KDE to support them.
At the moment only a single guy is maintaining CK2 and sending patches to KDE so KDE will work with CK2.
People whine about "Linux is all about choice", but when it comes to maintain those choices they all shy away with a "I am not a programmer", "No time", "No money" etc.
So if you want to run a modern desktop in 2016 on a non-systemd distro, you better start contributing towards it.
The same thing goes for OS containers, the new cgroups API and what not. If you want that stuff, don't expect it to magically being made by benevolent pixies nor developers from systemd-distros.
>Couldn't journald be modified to output text?
Not really. But what would be the point in that? If you want unindexed text logs just direct journald to forward all log-messages to syslog, and turn off the binary journald logs. All that it requires is a trivial change in journald.conf
The problems with journald outputting text logs are several: /dev/ksmg (kernel) and /dev/log. That is why the kernel stores all its early boot logs in binary form in the kernel ring-buffer that are then later extracted by special tools like dmesg.
The most important thing is that it is more or less impossible to do right during early boot where journald is receiving messages from both
Another problem is Linux kernel limitations on handling devices. Only one program at a time can read from /dev/log, or messages will lost and randomly misdirected. That means that journald that collects logs from /dev/log before rootfs is mounted and Rsyslog running, can't later hand over control of /dev/log to Rsyslog without losing log messages.
The rather ingenious thing about journald is that it can collect and collate /dev/log info from earliest boot and in initrd, to after the rootfs has been unmounted. You can also have full logging available in initrd which is rather nice if you have to debug from there.
If you want "metal-to-metal" logging something designed like journald is a good idea: If you made journald to be a super-syslog client with text output, you would prevent end-users in choosing between Rsyslog or Syslog-NG or whatever they can use with journald now. Same if they cooperated with the Rsyslog team so Rsyslog could collect from early boot and pivot back and forth from initrd like journald can. Then you couldn't use syslog-ng etc.
As systemd's journald is designed you can choose any syslog(3) compatible logger to work with journald. You can freely choose between either binary or text logs for e.g. legacy scripts to work.
I am a US citizen as frustrated about unauthorized domestic surveillance as anyone. But this summary goes too far. Finding, keeping and using vulnerabilities is exactly what the NSA is supposed to do, and there is nothing questionable about that behavior.
If the submitter wants the government to have a group that finds and discloses vulnerabilities as part of its remit, then make a case for creating such a group. Don't saddle the NSA with the job.
Well, you are wrong in thinking that it isn't the job of NSA to disclose at least certain vulnerabilities.
NSA's job description also include counter intelligence. That means it should also do its best to protect US government servers, including the US military and potentially too, civilian US military contractors, who may have highly valuable knowledge on their servers.
So certain vulnerabilities affecting software that the US government uses, are circulated back into the software community, it is simply in the interest of NSA as a counter intelligence agency to do so.
ATM's, industrial and medical appliances etc. No personal experience with embedded OS/2, but apparently it was very attractive to use for making GUI's with often critical data input, combined with running on x86 and PPC boards that made it easy to develop for. The underlining OS technology, like the kernel was without doubt the best and most stable running on x86 for quite some time.
OS/2 is relegated to neckbeard's still maintaining their Amigas and C/64 machines playing block/character graphics games.
I really don't think so. The commercial interest in OS/2 isn't in desktop use or retro computing, but embedded and industrial appliances where OS/2 thrived years after the general public had forgotten it.
This new release is about protecting investments in such OS/2 based equipment.
The release is probably mostly for embedded use where OS/2 had quite some use since it was so much better and stable than contemporary MS Windows.
I quite liked OS/2 in its time and found it very superior to contemporary Windows versions.
I have it the exact opposite way. I find KDE apps superior to any other alternatives in most respects.
Krusader and Dolphin for file-management are better than anything else I know. Superb integration like packing or unpacking files or encrypt them or enque them in Amarok etc.
Kmail, and the entire PIM suite with calendars and contact management is better than anything else I have tried.
Konqueror isn't bad at all, and much faster and lightweight than Firefox. The absolute main reason why I use Firefox as my main browser is because of the many great add-ons. For many other things like file-management, bookmarks and passwords, Konqueror is actually better.
System wide password management with kwallet is much, much better than each and every program implementing similar systems.
DigiKam for photos and Okular for pdf's, Kid3 for audio-tagging, K3b for disc-burning and ripping, KRename for advanced mass renaming, Kstars for astronomy, are better than anything else I have tried.
Konsole, Kate (editor), Okteta (hex editor), Amarok (music player) are also favorites of mine.
In short, KDE, including Plasma really works well for me and my work-flow. Personally I don't really like XFCE; almost no desktop integration and no apps, inferior file-management and a UI metaphor that reminds me too much of Win 3.11. IMHO Plasma beats in every aspect when it comes to virtual desktops, shifting between programs, program services and app integration.
The British were the "inventors" of the concentration camps that also targeted women and children https://en.wikipedia.org/wiki/...
There is no comparison to the British Boer War concentration camps and the Nazi camp system, that including industrial murder machines like Auschwitz and Majdanek.
The British Boer War concentration camps were bad and thousands of women and children died in them. But unlike the Nazi camps, there was never a deliberate policy of starving or working the inmates to death.
So there was not only a huge difference in the number of dead (many millions vs around 26.000), but also a crucial difference in _why_ the inmates died; in the Nazi camps they where deliberately target for destruction through starvation and gassing, while the British Camps where merely badly and incompetently run, so the inmates died of epidemics and neglect.
Another crucial difference is that when the British politicians (both ruling party and the opposition) discovered what was going on, they intervened and brought the camps (and their mortality rates) in order again.
The thing is, you don't need a 4K display to work on variable DPI support, you just need to make sure that the apps you have responsibility for DO IT!
Sure, you don't need a 4K display to work on HiDPI support, but it would probably help with the motivation though. Remember, KDE is mainly coded by volunteers that have full time jobs doing other things, and mostly their work queue is extremely long.
Personally I am quite pleased with KDE 5/Plasma 5. As usual the KDE developers delivers a lot of new stuff between each point release. KDE 5 (Apps, Plasma 5) is already in much better shape than KDE 4 was at a similar point back in 2008/2009.
Sure, they work better now than they did 6 month ago, but HiDPI is still a work of progress on Gnome and Unity (and KDE too).
As I said, every iteration of those Gnome/KDE brings better HiDPI support. But the devil is in the details and certain apps have hardcoded assumptions on font sizes and DPI that doesn't work in HiDPI. It will take quite some time to shake out all the visual bugs.
Things move somewhat slowly simply because there are so few developers working on it and even fewer of these DE developers own 4K displays.
There used to be the understanding that releasing soon made for pending features. Bugs, on the other hand, have always been a matter of the quality and seriousness of the developers involved.
New features=new bugs.
The quality of FOSS software like KDE have really improved over the decade. I used to expect application crashes and even DE crashes as a matter of fact, these days such crashes are much rarer. Gone are the usual huge memory leaks too. Everything from documentation to stability have improved much over the decades.
What people are complaining about these days are mostly subtle bugs or missing features like "widget X" no longer work like it used to do.
I find it sadly typical of the times that each and every Linux DE discussion on Slashdot quickly are degenerating into rants on how bad the DE is because {insert trivial thing} isn't working like expected. Usually the rants are from ex-users too. Why they feel a pressing need to discuss and rant about a DE they don't even use is something of a puzzle to me.
Something in peoples attitude have changed in the Linux "community"; these days it is all about negative rants, bug-whining and trash-talking of FOSS projects and its developers.
Except the British in Kenya? On in India?
The British never had a policy of extermination. There was never British Death camps like Majdanek or Sobibor, nor British units like the Nazi Waffen-SS 1. Brigade or the Einsatzgruppen, that toured eastern Europa systematically killing off whole villages by forcing the victims to dig graves and then shoot them in groups so their bodies was layered as "packed sardines"; shooting the men first, then the women and children. There was never a British "Babi Yar"
"https://en.wikipedia.org/wiki/Babi_Yar massacre.
The British colonial rule may have been misguided, paternalistic and sometimes brutal, they never committed mass murder on populations for being the wrong race, nor did they have any policies that willfully would kill off civilians through mass starvation.
Really, thinking that British colonial rule is even remotely comparable to the murderous Nazi regime shows a sad lack of understanding how gruesome and genocidal the Third Reich was in both thinking and deed.
There has also never been anything in both scale and intentions that have ever matched the Nazi regime when it came to Genocide, not even Stalin's USSR.
Armenian Genocide
While the Armenian Genocide was horrible, it was dwarfed by the Nazi Genocide by at least a factor of ten. The German occupation killed at something 14 million civilian Russians alone.
Ubuntu's desktop releases are hardly "bleeding edge."
Well, if they wanted a stable KDE release they should have chosen KDE 4. KDE 5 (KF, Apps etc) are still a work in progress.
But people (including me) wants new and shiny, so most distros tend to ship the newest Linux DE instead of the old boring stable one.
Face it. The KDE team screwed up. All software teams do, sooner or later. They post a broken "release", and it gets shipped.
I disagree and I don't think you really understand how FOSS DE and software development work; all the major DE versions starts with feature regression, rough edges and lots of bugs, and then later start to stabilize as users report bugs and developers catch up. Gnome 3 happens to be further into the stabilizing phase since it is older, but it certainly was released with both bugs and features missing.
Both Gnome 1, 2, 3, and KDE 1, 2, 3, 4, 5 followed the above pattern without exception.
This is not because KDE or Gnome developers "screws up", but because this is how FOSS DE software with basically no funding has to be developed; release early and release often, have the users report bugs and supply RFE's and general feedback for what is important to fix.
If people rage-quit instead of reporting bugs Linux development will suffer.
Besides, it's not like there aren't a bazillion desktops out there waiting to replace one that's been screwed up.
Really? As I see it there are only two DE's out there with any kind of application development going on and that is Gnome and KDE (and a few Qt apps).
If KDE disappeared then there would only be Gnome and GTK apps left for Linux. (Qt would probably disappear too since they would no longer have any economic incentive to support Linux anymore).
But hey, there is always CDE.
I don't any FOSS DE have fully working HiDPI /high resolution display support yet.
They are getting better for each release however.
Again the point is that few people are working on Linux DE's since nobody earns money on desktop Linux and desktop Linux users generally are misers when it comes to donate money to DE work. I think many board games or small computer games raises more capital on Kickstarter than all Linux DE's together gets in user donations.
Yeah, interesting that people want bleeding edge and then complain about bugs and missing features. KDE 4 works fine (and is upstream LTS now).
I don't know if it is a good or bad sign that people expect FOSS DE's to be mature and finished before they are released, just like commercial DE's like MS Windows.
There used to be an understanding that FOSS software projects needs to release early and often, and that this sometimes meant releases with missing features and bugs.
Anyway, people should remember how few developers actually working full time on Linux DE's (the number is probably lower than the number of Baristas employed by Microsoft).
It never really ceases to amaze me how good the KDE desktop and its applications are compared to products from multi-billion dollar companies.
So? The Nazi Germany didn't do anything that other countries, including Britain, France, Netherlands, Belgium, etc., had not also done. The only difference is that Hitler did it to white people.
More people were killed in forced labor on rubber plantations, than in all the Nazi death camps combined.
That is misleading; those figures for Congo are "depopulation" losses, not people killed. No other comparison points implied, but several western countries these days are being "depopulated" due to falling birth numbers, that doesn't mean there are secret massacres going on. "Depopulation" also includes population losses from people deciding to only have 1-2 kids instead of 3-4 kids needed to sustain the population.
Sure, there were huge atrocities going on in Congo, but the numbers you are quoting aren't only about people being killed as forced labor on rubber plantation as you claim. According to your cited source, the majority died of "sleeping sickness", still a killer disease in Congo these days.
The Death camps however where targeted killing machines, murdering people sometimes minutes after they had arrived by train. They also killed millions of people in a very short time, basically a couple of years, while the Congo depopulation took 40 years. The Nazi war on the eastern front killed +27 million people in 3-4 years in comparison.
Also of interest is that the (at least) 6 millions Jews killed was just the warm-up, since Mischlinge (half/quarter/etc Jewish descent) was next, and with the "General Plan Ost", the Nazi regime basically intended to exterminate all Slavic people from Poland to the Ural mountains except for a small amount that was to be kept as slaves.
Saying that Hitler and the Nazi regime only did what the British, Belgians etc, had done previously is just plain out wrong. There has never been anything remotely like the Nazi Death camps before.
There has also never been anything in both scale and intentions that have ever matched the Nazi regime when it came to Genocide, not even Stalin's USSR.
Most of it is just the usual LKML noise when something important is merged
No, it isn't.
Yes it is. Seen it so many times over the decades, even Alan Cox said on G+ that it was just business as usual, with kdbus standing a good chance of being merged when the raised criticism was dealt with.
First, you must remember that several of the "noise makers" aren't kernel developers at all. Everyone can write to the LKML, though that doesn't mean they are taking seriously.
Secondly, new important things are often put through the grinder; that is how it works on LKML. But it doesn't mean that all raised criticism is valid either; much depend on the defense of the existing code too.
Until now the kdbus developers have either incorporated actionable criticism into code/design/documentation changes, or defended their stance very well. Kdbus have clearly benefited from this process and is now being "beta tested" by end-users too. So when it finally gets merged, it will "land running" so to speak, with more than usual real world testing and userland code.
You are misinformed. The cgroups change has nothing to do with either dbus or kdbus, nor systemd.
That's Lennart speaking there. Claim everyone is misinformed when a raw nerve is touched. Lennart has clearly stated that he sees systemd as the one way of configuring cgroups in userspace and kdbus is the way that will effectively be locked in as the interface between kernel and userspace. Can't possibly have competing ways of doing this.
It seems you haven't understood the basics of this. Let me clarify:
1. On systemd-distros it is systemd that will be the sole cgroups writer, and the sole owner of the shared bus as setup on kdbus. Poettering are only stating the obvious about this, because realistically that is the only working option.
2. Non-systemd distros can make their own cgroups writer or mechanism for controlling kdbus. They are free to do so, and the API's they use will be stable kernel API's. systemd doesn't in any way prevent them for making their own software for controlling cgroups and kdbus.
This is the way it is supposed to be; everyone makes their own stack. This is what gives competition, not the rather strange assertion that systemd developers somehow should make a independent cgroups writer that works on all Linux distros.
As I said, cgroups and to a lesser extent kdbus, are tremendous opportunities for the non-systemd distros to make their own stack (I am thinking containers mostly) that might even attract both capital and paid developers.
You will find that the change is backed by all kernel developers who thinks exactly the same as Tejun.
Bollocks. I find a lot of kernel developers who have issues with it though. See, easy this isn't it?
Really, I challenge you to find even single kernel developer who thinks the old cgroups API is secure, and who doesn't agree on Tejun's proposal as the only way forward. AFAIK, both Al Viro and Andy Lutomirski discussed this recently on LKML.
kdbus is great technology, especially for the non-systemd distros.
Kernel developers who have attempted to review the code have stated otherwise, and kdbus is simply not going to be merged until those concerns are addressed. What happens is things go silent, a patch is pushed to Linus with no changes and the mailing list thread kicks off again with the response "But it does this in userspace, so this is how it has to be and of course, putting it into the kernel will automatically make it go faster, because, you know, KERNEL!". There are a litany of huge issues with it too numerous to discuss here.
Most of it is just the usual LKML noise when something important is merged, people want to test even the basic assertions of everything. Don't take it too seriously if eg. Al Viro says that some code is bad. His standard is that at best, all code sucks badly, with most codes being even worse than that.
It looks like the usual Linux kernel process works fine, with kdbus being improved really well from every round of patches on LKML, especially the two first rounds.
You will find that all actionable kdbus criticism is being dealt with, Greg KH is a seriously experienced kernel developer who doesn't shy away from technical problems.
Anyway, the point is that having a shared bus kernel IPC is a good thing that non-systemd distros could benefit from. Instead they try to trash talk it, pretending it isn't good and doesn't solve any problems. In short, repeating the same total failure tactic as they used against systemd and PulseAudio.
So kdbus seems to be yet another technology that are "taboo" for the anti-systemd crowd. Their loss really.
Using the Spinal Tap line of "But it goes all the way up to eleven" to any argument is all the systemd proponents have. It's quite sad that we're going to spend a great number of years of pai
It is the cgroups maintainer Heo Tejun that wanted the change. Systemd has nothing to with it. Sure, systemd developer are working on a user side implementation of the new API, but that is it.
Alas, the net effect of it is that the single interface to it is through systemd and dbus, and Lennart claims in that passive aggressive way, as you do, that it is the 'cgroup maintainer' who wants this. However, this 'change' has been bandied around for at least a couple of years now largely because it looks as though they thought kdbus would get a free pass into the kernel. We all know that's what this means.
You are misinformed. The cgroups change has nothing to do with either dbus or kdbus, nor systemd. You will find that the change is backed by all kernel developers who thinks exactly the same as Tejun.
Nor is systemd the "single interface" to the new cgroups API. Anybody can make their own cgroups "writer" since it is a kernel feature. Just because systemd takes advantage of kernel features doesn't mean anybody else can't.
Seriously, you guys who for some reason don't like systemd (I don't care why) should stop spreading misinformation that really hurt your own cause.
Perhaps it feels good to tell a narrative how systemd usurps everything and makes all other development impossible and that in the future only systemd will be able to use the new cgroups API, but this will only discourage any non-systemd development.
The systemd-opponents seems too busy in burning all bridges, both behind and in front, dismissing technology just because systemd happens to use it; cgroups, dbus, kdbus , Capabilities(7), dynamic device handling (udev), service management, declarative text config files etc. is all bad because systemd uses them.
It really leaves very little room for non-systemd developers, and basically means that non-systemd distros will completely stagnate with obsolete technology.
kdbus is great technology, especially for the non-systemd distros. If you think otherwise you haven't studied the project. Same with the new cgroups interface. There are some really good opportunities there too for the non-systemd distros to make something interesting with that, that could attract commercial developers.
The negative campaign against systemd have been an utter failure from the start. You guys should have concentrated on positive contributions in alternative development years ago. And you should have the cool, dispassionate look on systemd that would enable you to steal and copy every good idea from that project.
I see.
Is there anything you don't like about systemd, or is all you can do defend it? Are you blinded into thinking that everything about it is good?
Most of it is in the details, like systemctl having the action command as the first thing instead of the last like this:
"systemctl /stop/ example.service"
The reason is probably globbing so you can expand a lot of service files one after another, but still, using Bash the workflow isn't perfect since I used to recall the previous command from the stack with ctrl+r and then edited the action command. I haven't found an easy workaround yet. "^start^status" kind of work but is cumbersome and can't be recalled, only the expanded command.
It is also hard to keep track of systemd progress since things are developed with quite some speed.
From a more philosophical standpoint, I wished that systemd actually had something that even remotely looked like competition. It is really good for software projects to have competition; it enables projects to "steal" good ideas from each other and not sag behind in features.
Not having competition may lead to complacency and stagnation.
But I was completely wrong in my assertion that such a competition would arise from the non-systemd distros. I even fear for those distros ability to even maintain existing stuff when the commercial distros stops maintaining their non-systemd software stacks.
All the init-systems in use at the time where just "slightly improved SysVinit" style init-systems.
You're missing the point, deliberately I hope because the alternative is too pathetic to contemplate. Those init systems were in use at the time because you could swap between them freely. Systemd deliberately breaks that state of affairs and that is what is primarily wrong with it.
It is trivially easy for upstream projects to make their daemon support both systemd and SysVinit, in fact, if they don't change anything then everything is as before, with distros providing both scripts or service files. The whole point with systemd is exactly it is backwards compatible with SysVinit, even though it is quite different.
You could never easily switch between between SysVinit and other similar inits, simply because there never existed init-agnostic scripts nor distro-agnostic scripts. You simply can't use OpenRC scripts on SysVinit.
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.
Proper responsibility? No, you have that wrong. They did everything they had to do.
I strongly disagree. SysVinits "simplicity" was exactly because it left all complexity to others to fix. I won't dwell with PID problems, daemonizations or other classic criticisms of SysVinit, some dating 30 years back, but show one example:
As you know, daemons need special (root) privileges in order to access port-numbers below 1024. This is for security reasons. The backside of this is that the daemon then needs high privileges to run. Enter setuid and similar Posix syscalls; they have basically been demonstrated to be impossible to use in a safe manner, and have provided decades of remote exploits of Linux for the same reason.
Then came Capabilities which meant setuid root programs could be ditched for that, but Capabilites still means the Daemon can freely talk through low port numbers, so spammers have for years exploited this to install spamming smtp servers on exploited hosts or serve malware from port 80.
systemd on the other hand, can give the daemon a low port-number through a socket so that all such low port-number privileges can be completely dropped; even if the daemon is exploited, it can't send spam through a low port number.
Much more secure, and it even makes things much less complicated for the daemon writers.
With SysVinit, all the daemons had to implement code dropping privileges, which meant 1000's of different, bug-filled and often insecure code implementations. With systemd, the daemons can let systemd take care of all that. I think that is the right approach; daemon writers want to make awesome programs that does things that interest them, not fiddle with hard to understand low-level system programming. In any case, it is bound to make things much more secure.
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.
Oh great, more influence of systemd shitting up my Linux. Just want I wanted to hear about. So instead of a simple, working interface to cgroups, they want to make it harder to use. Why would you do that? Just to make systemd look more useful? You make it harder to do what they do in a script so that people like me can't say "but a script could do that"?
It is the cgroups maintainer Heo Tejun that wanted the change. Systemd has nothing to with it. Sure, systemd developer are working on a user side implementation of the new API, but that is it.
The main problems are security and bugs in allowing multiple controllers/writers. It just didn't work since there are too many ways to get in