Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
What's the story with these ads on Slashdot? Check out our new blog post to find out. ×

Comment Re:Confessed? (Score 1) 244

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.

Comment Re:Too late (Score 1) 68

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.

Comment Re:Too late (Score 1) 68

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.

Comment Re:Too late (Score 2) 68

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.

Comment Re:Confessed? (Score 1) 244

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.

Comment Re:Confessed? (Score 1) 244

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.

Comment Re:Too late (Score 3, Insightful) 68

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.

Comment Re:Too late (Score 1) 68

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.

Comment Re:Too late (Score 4, Insightful) 68

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.

Comment Re:Confessed? (Score 4, Informative) 244

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.

Comment Re:Startup management subsystem (Score 1) 416

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.

Comment Re:Startup management subsystem (Score 1) 416

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 pain over this thing until it has to be dumped. Just wait until the security holes start getting found as well (you can drive a coach and horses through docker), but that's a whole other can of worms.

systemd won't be dumped. You are fooling yourself in thinking so. It is pretty mature at its core giving developers/users plenty of opportunity to find fundamental problems if they existed.
systemd really works very well and has been in wide scale deployment for years now.

Regarding security: systemd has done really well in that area too. It even has external code audits done by professional security experts.
It probably helps they have been developing after good security guidelines since the beginning and use static code checkers too. Also, the developer community is quite large with lots of people scouring over different code sections.

But just as important, systemd have really improved _daemon_ security making overall systemd security far better than on non-systemd distros. Look at the service file for Apache and how it is locked down per default. And remember, the options are inherited by program forked from this, so even if a black hat exploits another program after exploiting Apache, that program will inherit all the Apache limitations too, so eg. /home can't be read, even if the second exploited program normally have privileges to do so. See man systemd.exec for explanation of what "NoNewPrivileges=" etc. means:


[Unit]
Description=Apache Webserver
After=network.service systemd-networkd.service network-online.target
mysqld.service

[Service]
Type=simple
EnvironmentFile=-/etc/sysconfig/httpd
Environment="PATH=/usr/bin:/usr/sbin"
ExecStart=/usr/sbin/httpd $OPTIONS -D FOREGROUND
ExecReload=/usr/sbin/httpd $OPTIONS -k graceful
Restart=always
RestartSec=1
UMask=006

PrivateTmp=yes
PrivateDevices=yes
NoNewPrivileges=yes
CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK CAP_NET_BIND_SERVICE
CAP_SETGID CAP_SETUID
RestrictAddressFamilies=~AF_APPLETALK AF_ATMPVC AF_AX25 AF_IPX
AF_NETLINK AF_PACKET AF_X25
SystemCallArchitectures=x86-64

ReadOnlyDirectories=/etc
ReadOnlyDirectories=/usr
ReadOnlyDirectories=/var/lib
ReadWriteDirectories=-/var/lib/smokeping

InaccessibleDirectories=-/boot
InaccessibleDirectories=-/home
InaccessibleDirectories=-/media
InaccessibleDirectories=-/root
InaccessibleDirectories=-/etc/dbus-1
InaccessibleDirectories=-/etc/modprobe.d
InaccessibleDirectories=-/etc/modules-load.d
InaccessibleDirectories=-/etc/postfix
InaccessibleDirectories=-/etc/ssh
InaccessibleDirectories=-/etc/sysctl.d
InaccessibleDirectories=-/run/console
InaccessibleDirectories=-/run/dbus
InaccessibleDirectories=-/run/lock
InaccessibleDirectories=-/run/mount
InaccessibleDirectories=-/run/systemd/generator
InaccessibleDirectories=-/run/systemd/system
InaccessibleDirectories=-/run/systemd/users
InaccessibleDirectories=-/run/udev
InaccessibleDirectories=-/run/user
InaccessibleDirectories=-/usr/lib64/dbus-1
InaccessibleDirectories=-/usr/lib64/xtables
InaccessibleDirectories=-/usr/lib/dracut
InaccessibleDirectories=-/usr/libexec/iptables
InaccessibleDirectories=-/usr/libexec/openssh
InaccessibleDirectories=-/usr/libexec/postfix
InaccessibleDirectories=-/usr/lib/grub
InaccessibleDirectories=-/usr/lib/kernel
InaccessibleDirectories=-/usr/lib/modprobe.d
InaccessibleDirectories=-/usr/lib/modules
InaccessibleDirectories=-/usr/lib/modules-load.d
InaccessibleDirectories=-/usr/lib/rpm
InaccessibleDirectories=-/usr/lib/sysctl.d
InaccessibleDirectories=-/usr/lib/udev
InaccessibleDirectories=-/usr/local/scripts
InaccessibleDirectories=-/var/db
InaccessibleDirectories=-/var/lib/dbus
InaccessibleDirectories=-/var/lib/dnf
InaccessibleDirectories=-/var/lib/rpm
InaccessibleDirectories=-/var/lib/systemd
InaccessibleDirectories=-/var/lib/yum
InaccessibleDirectories=-/var/spool

[Install]
WantedBy=multi-user.target

The bottom line is that systemd distros will be hardened ever more per default for every iteration they go through, making them much more secure than present non-systemd distros.
Combine the systemd lock-down of daemons with MAC's like SELinux, and we are suddenly getting serious defense in depth security in Linux. Sure, more process containerization would be nice, but people are working on that too.

Comment Re:Startup management subsystem (Score 1) 416

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.

Comment Re:Free speech zone (Score 1) 416

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.

Comment Re:Startup management subsystem (Score 1) 416

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 into trouble. Another problem was that userspace directly had access to the low level API and various kernel knobs; again, a security problem, but it also meant that nothing could be changed without breaking userspace.

To my knowledge nobody in the non-systemd camp is even working on similar ideas, or even on an alternative cgroups single writer implementation.

What the fuck does "writer" mean here?

Basically the single entity that are allowed to directly interface with cgroups and the kernel knobs exposed that way. Userspace is meant to use the high level API provided by this writer. There can only be one such writer on a system in the future, on systemd distros this writer will be systemd since it already handles cgroups.

"Don't think; let the machine do it for you!" -- E. C. Berkeley

Working...