Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror

Comment Re:IPv6 SLAAC without EUI-64 (Score 1) 112

dhcpcd (which also works on BSD) has had support for this (RFC7217) for almost a year now, but it's now news when NetworkManager (Linux only) get's it?

RFC7217 has been in NM for some time. The news regarding this is that it now is upstream default for IPv6 connections when using NM 1.2.

The other feature, that is the real news, is a kind of MAC randomization feature that uses the real HW MAC for connection, but "fake" MAC's for scanning for AP's. This is also default now.

NM can also randomize and spoof MAC's like the decade old GNU MAC Changer, but it isn't default since that may give problems with connecting to certain devices and services.

Comment Re:What main benefit? (Score 1) 785

Forgive me for asking but, what is systemd's main benefit? If i don't mind that my system boots up slower and in a sequential order, how does that affect the systemd's benefits for other users?

The primary benefit of systemd is that it is init done right. That means you no longer need to use executable shell scripts in order to run daemons, but can use simple text config files. SysVinit shell scripts are hard to parse for both humans and machines, while systemd .service text config files are easy to parse for both machines and people.

Integrated service management: Want to restart and important service if it crashed, but only if it crash with an abnormal exit code and hasn't been re-started the last 5 minutes. That stuff is trivial to do in systemd with only changing a simple config line in a text file. With OpenRC/SysVinite etc. , it requires endless hacking to make something similar work.

Reliable killing a process and all its sub-processes. systemd can do that because it tracks every process with cgroups, non-systemd distros can't.

Security: If SysVinit had stepped up and taken responsibility for handing out low port numbers to services so they didn't need privilege dropping code like systemd does, we could have avoided two decades of remote exploits of Linux because of wrong use of setuid in daemons. It is better to have one secure implementation of privilege dropping code made by security experts instead of letting each and every daemon try to do it.

Security: systemd can "jail"/"contain" all running services since it provides an easy to use "API" for several low level kernel security features like "Capabilities" and "Namespaces".
So the service developers, the distro-maintainers, or even the system administrator can add "NoNewPrivileges" to a service config file. That means, that even if the service is exploited, the attacker can't get escalate privileges by then exploiting another service (A typical pattern).

Extremely easy resource management like limiting a service to only X amount of memory, or CPU resources, or bandwith etc. It can do that because of cgroups integration. A single; "MemoryLimit=1G" or similar added to the service file will make things work.

There are even more good reasons. I recommend the systemd homepage, especially the "The systemd for Administrators Blog Series" for and end users perspective.

http://www.freedesktop.org/wik...

In short, for me systemd is the best thing that have happened to Linux since package management. I really like it, Good stuff that makes Linux more secure and easier to use, for both newbies and experienced admins. It also has the best man page documentation and CLI tools I have seen for many, many years. Take fx. "man systemd.index" ; that will give you an overview of each and every "man-page" related to systemd. Very nice.

Comment Re:OpenRC forever! (Score 1) 785

I don't understand this. If systemd is so backwards compatible with the traditional way of doing stuff, why don't distros enable that? Half the systemd hate would probably dissappear just like that.

Because almost all systemd haters don't have any actual systemd experience, nor have they even read a couple of systemd man pages. And perhaps not so few aren't actual Linux users either.

This is the modern world where some hearsay on a blog becomes a "truth" by endless repeating. I can't think of a single enterprise distro like RH/CentOS/Suse that doesn't have text-logs as default.

Outside the tiny 0.00001% of Linux users who can actually use regex, I fail to see the attraction of text logs after having been spoiled by actually using the systemd journal.

Comment Re:It depends on somebody doing the actual work (Score 1) 785

What are the "non-systemd distros" that are crumbling?

I hoped the context could have clarified what I meant about "crumbling".
But let me sum up; there is a whole lot of software that the non-systemd distros need to maintain in order not to lose features. They have basically all ignored this fact for years, despite upstream projects like KDE and Gnome have pleaded for this to happen.

Now years of neglect is catching up with non-systemd distros. And it will gets worse in the future. OS containers, Wayland, the new cgroups API; how does the non-systemd think any of this new technology will work on their distros if they aren't actively working on them? I mean, the entire OS container industry are now getting behind systemd.

I'm not sure it will be actually possible because, you see, I'm facing the reality, that systemd alternative right now is another systemd. Hence today topic.

Lets ignore that the technical whine behind that story was wrong. Your point still stands. My point is, that that reality is solely caused by the non-systemd distros failing to keep up with development.

I had hopes that Devuan could be enough. Now, after one year, I'm suspecting it could not. Not because of the "non-systemd distros" people, as you name it. But because if the game is rigged. "In many cases [systemd] allows us to throw away large amounts of code whilst at the same time providing a better user experience. Adding it [systemd] as an optional extra defeats the main benefit": it says it all. Thrown away code, no benefit if optional. It is pretty clear what it implies.

Isn't that quote just the usual Devuan rhetoric where they try to hide the hypocrisy about first bleating about "init-freedom" and "choice in init", and then later remove any trace of init-freedom?

They lied about being "Veteran Unix Admins" too, so what do you expect of a bunch of rather shady unemployed Italians trying to use GPL software as a bait for their constantly outreached begging bowl? Looking at their cash withdraws from the collected Devuan money they seem to already have their snouts in the money trough.

Comment Re:It depends on somebody doing the actual work (Score 1) 785

I think you missed out on why code is fixed. 25 years ago and today, only code that is useful and therefore can attract developers can survive in the FOSS world.

The lack of development among the non-systemd distros are caused by the fact that they are a tiny minority and that almost all developers have left their ever decreasing circle.
Without developers, no code. It is as simple as that.

The systemd-opponents should probably have reflected over what they did wrong a couple of years ago.

Comment Re:Duh (Score 1) 785

>I had a quick look at the ConsoleKit2's git repo. I guess by "years" you mean 5 months.

Nope. CK is still dead and has been for almost 4 years. While CK2 is a fork, it has dropped the old CK API (and code) in favor of the systemd-login API, just like systemBSD. That means you can't use CK2 as a direct replacement for CK. The old upstream code in the DE's simply don't work.

While CK was dead, there where of course still lots of development going in the DE's, but since only systemd-login was actually maintained, they could only add support for that in the new code.

And the KDE and Gnome developers never got any help for the hard work they are doing with supporting basically un-supportable distros that ignore each and every request they have. Not even a "thank you" are they getting. Instead they are getting shit kicked in their faces by fanatic systemd-haters.

Comment Re:Duh (Score 2, Interesting) 785

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.

Comment Re:It depends on somebody doing the actual work (Score 1) 785

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.

Comment Re:Duh (Score 1) 785

>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.

Comment It depends on somebody doing the actual work (Score 2, Insightful) 785

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.

Comment Re:If we're going systemd, we should go full throt (Score 1) 785

>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:
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.

Comment Re:Biased summary (Score 1) 121

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.

Slashdot Top Deals

"Remember, extremism in the nondefense of moderation is not a virtue." -- Peter Neumann, about usenet

Working...