Slashdot Mirror

The main initiative being a call for women only program spaces (to save their delicate sensibilities from rude male criticism) and discrediting male developers at conferences. This is when they're not emailing round the 'community' to try and get developers fired. I don't know of any male developer who organized an email campaign against a female developer in retaliation for a post on a blog. That would be Valerie 'nutjob' Aurora, good fucking riddance is all I say.
 
.. women often face harassment both online and in person. Hundreds of women took GitHub and Ada Initiative up on the offer and have made hundreds of commits, showing that women in open source see the value of a chance to learn in a supportive private environment before joining the wider community."

The dark side of open source conferences

There isn't a "revoke privileges" kernel feature either despite years of trying (it is a hard problem).

You can't do it through a capabilities interface, even?

No, it is different from dropping privileges. Here is a short explanation. In this case the user case is being able to use revoke on devices:
https://lwn.net/Articles/54653...

The Linux kernel simply have limitations when it comes to device handling, especially when it comes to security.

That means userspace have to have a sophisticated session manager like logind with kernel integration in order to keep the multi-seat sessions safe.

Why would it need to be married to the init daemon? That's the part that's unclear. cgroups permit management of process groups no matter how, why, or when they were created, or who created them. It doesn't matter if init starts the process, any other daemon could have done that job.

Because cgroups track all processes that are initiated, this is why systemd can track and kill all processes and its subprocesses reliably. It also provides process isolation needed for security (and user sessions).
Cgroups is therefore extremely tightly integrated into the systemd-daemon.

Here is a quote from the mailing list where Poettering explains:

"Well, logind talks to systemd to manage user sessions and user
processes in cgroups. That's why it depends on systemd. And since only systemd implements that, we couldn't even support anything else even if we wanted."
http://lists.freedesktop.org/a...

Things will get even more complicated with the new cgroup API, since that only allows one "writer" on the system, and that writer is supposed to abstract away the low level API so it doesn't expose "kernel knobs" anymore.

There are also the usual reasons for why it really can be limiting to freeze internal API's, and over the time some stuff have moved into "logind" and other stuff out, which wouldn't have been possible if the API had been frozen.

But as said, even if the API was frozen, logind would still require session and cgroups management, and nothing outside systemd really provides that.

systemd really provides a lot of external API's that are frozen and stable, but logind isn't one of them.

Personally I don't see the need either. It has been quite clear for years that the non-systemd distros needed to develop and maintain their own software stack. Both Gnome and KDE developers have repeatedly pleaded for this over the years.

A few years ago, when I was compiling all software for my personal workstation myself (LFS) as a learning experience, I actually did that. C++ was too big a hassle for too litle gain.
After a while during a reinstall I disabled g++ and only installed programs written in C or other languages. It was no big deal actually, opensource C++ projects feel huge and sloppy compared to the rest.

Was it really only "a few years" or are you forgetting how long it has been (easy to do)? was this machine a fully functional workstation (including stuff like web browsers and if so which web browser)? or was it just a toy/special purpose box?

A few years ago gcc itself switched from C to C++ https://lwn.net/Articles/54245... . Both of the two main web rendering engines (geko and webkit) are C++. One of the two main desktop widget sets is C++.

I agree C++ has it's problems, templates look good in microbenchmarks but can easilly blow up code size. Memory requirements for linking large C++ projects can be horrific but the fact remains C++ is far more widely used and supported than any other object-orientated native-compiled language. It's position may not be quite as important as C but it's not far off.

HP did have Linux desktops and laptops you could buy.

Nobody bought them. So HP stopped selling them.

It's easier for HP to just have systems that they test with Linux and if large customers want a Linux laptop HP can tailor it to suit that customer.

One of the most bizarre things I've noticed with Linux users is that they tend to reject any system being sold with Linux on it and rather go out and buy a Apple product that runs Linux like shit, a Thinkpad because of the bragging rights, or the Windows version of the Linux laptop because a few options are not available for the Linux version (invariably because they don't work well with Linux) or that the Windows version is slightly cheaper.

There is simply no reason for OEMs to market Linux systems when even existing Linux users won't be their customers.

https://lwn.net/Articles/53543...

This might help: the splitting Inheritance into its core aspects, and how those core aspects are implemented in Go and Rust: https://lwn.net/Articles/54856...

It's a fact that the fix for corrupt logs, which systemd will often corrupt if you power-cycle your system, is to delete them and throw them away. https://lwn.net/Articles/621453/ https://lists.fedoraproject.org/pipermail/devel/2013-July/185702.html

No, it's not a fact. If the log file is corrupt journald rotates it. It doesn't "delete it and throw it away".

It's a fact that the fix for corrupt logs, which systemd will often corrupt if you power-cycle your system, is to delete them and throw them away. https://lwn.net/Articles/621453/ https://lists.fedoraproject.org/pipermail/devel/2013-July/185702.html It's a fact that systemd will only sometimes recover any part of its bullshit binary logs, and only any part after any error. So if journald truncates a file because it shits itself, which it has been known to do, then you lose the whole log.

Your facts are plain lies, any sysadmin can see that. systemd does not corrupt logs when you power-cycle your system either, the fact of power cycling your system is actually what corrupts your file-system, and that's not even always the case.
Stop using "data=writeback" on your ext4 FS, take the performance hit and start using "data=ordered" instead of spreading lies, perhaps your FS will leave you alone then.
Up to this morning, I used the journal to debug an embedded system (raspberry pi) that would not boot, for which I don't have a console nor ssh access. I just shut it down electrically, then get the SD card, then read the journal file from another system. Guess what: the entire file is readable every single time (I've done it a lot to debug boot problems) with journalctl, with even the kernel boot messages as thanks to systemd, I get really everything in the log.

It's a fact that the fix for corrupt logs, which systemd will often corrupt if you power-cycle your system, is to delete them and throw them away. https://lwn.net/Articles/621453/ https://lists.fedoraproject.org/pipermail/devel/2013-July/185702.html It's a fact that systemd will only sometimes recover any part of its bullshit binary logs, and only any part after any error. So if journald truncates a file because it shits itself, which it has been known to do, then you lose the whole log.

Moderators, you might want to familiarize yourself with the festering pile of shit which is Lennart Poettering, as well as the pile of crap which is systemd, before you moderate any systemd discussions. Because you clearly have no idea what you're doing.

No one who looked at the code has ever considered the programmers behind it "gods". The PostgreSQL developers for example have been complaining about it for years, including a major look at alternatives in 2011 because we hated the code's API and its license so much. However, that crappy API serves as a form of lock-in, making it harder to migrate to other libraries than it should be.

As a programmer, KDBUS (or any proper IPC system for Linux) sounds really useful.

Here is a write-up on DBUS vs KDBUS for those who are interested.

To sum up: D-Bus is great for sending control messages ("change volume") but not for lots of data (audio streams), it's not available at boot-time (a serious problem if you need to talk to it!), and it's got security flaws. KDBUS is the incremental solution to these problems. A kernel space message sending system that all programs can use at boot to talk to each other.

Bundling http support with OS distribution is one thing. Making it _kernel_ module is different thing altogether.

You mean like this?

http://lwn.net/Articles/580419...

So www.lwn.net has a better section dealing with the 4.0 kernel including what persistent memory and lazytime changes are. I would suggest going there.

http://www.lwn.net/

I like to find more information than the smattering that was a "detailed look". as they say.. NOT.

That's because there's close relationships between "free (as in freedom) software" and "open-source." Neither is a proper sub-set of the other though.

Bolded part has me curious. What sort "free software" would not fall under the looser defintion of "open source" at the same time?

I can think of a couple edge cases.

First, software that you make for yourself and don't let others use. Not even through services. Google and Facebook are considered non-free in that regard. But if you make it for yourself, then you're exercising your freedom and not hurting anybody else.

Second, software that is isolated in a coprocessor and cannot be modified. Then it can be considered part of the hardware, and Free Hardware is not a priority of the Free Software Foundation. That's the approach being taken for the GTA04 OpenMoko phone.

http://lwn.net/Articles/79302/

Phantomfive, first may I say that your "code review" was a disappointment. I was hoping for a pretense to objectivity.

However, the gnome/systemd thing has been fought out on the gnome developers mailing list, on LWN, and on various developer's blogs. The short form is they need various (generally session-related) features that are not provided by anything else. All of these decisions have been fought over heavily.

https://blogs.gnome.org/ovitte...
https://blogs.gnome.org/ovitte...
http://lwn.net/Articles/520892...

Frankly, I don't think you have any qualifications to be second-guessing anyone else's coding decisions, and certainly not if your "code review" is any evidence. However, all of the decisions and justifications have been public, so the information is out there if you want to look.

Digging around a bit this is what I gathered:

TSYNC is some flag added to seccomp to aid in something relating to thread synchronization: http://patchwork.linux-mips.or...

And seccomp is a security mechanism of the Linux kernel used to implement the sandbox in Google Chrome, which it uses for instance to run the Flash plugin in such a way that it doesn't compromise the system if one of its many security weaknesses: http://lwn.net/Articles/347547...

None of this seems to have any relation to spyware, in fact it would seem to have the exact contrary purpose: protecting the system from potentially malicious code and security exploits.

Unless I'm missing something obvious, it sounds like Ben Hutchins (the Debian mailing list guy who made the comment on spyware) just dislikes Chrome for whatever reason unrelated to TSYNC and decided that it would be a fine way to ensure new versions of Chrome don't run.

Probably DarkMail could be considered as SMTP securing, not sure if in the way you propose.

Try the settings - standard kernel options for linux don't work for this.

The only options that work today are using driver level code for audio processing or a real time Xenomai task.

Please support Thomas Gleixner via the Linux Foundation to help to fix this limitation of Linux: http://lwn.net/Articles/572740...

Until then, all high performance low latency audio processing in linux needs to not use any user level tasks.

Jeff

Technology-wise: In rate-distortion terms, Theora is comparable to H.263-family codecs such as DivX (a popular implementation of MPEG-4 ASP). VP8 is comparable to the baseline profile of H.264. This means the picture can be more detailed at the same bitrate.

License-wise: WebM is distributed under the revised BSD license. As a free alternative to a patented format, it's in a similar position to Ogg Vorbis, for which RMS approved of use of the revised BSD license.

You've written linux kernel drivers, but you have to ask slashdot?

Writing linux kernel drivers is really easy, surprisingly easy. Get this book and you can learn to do it in an afternoon. If you've never compiled a kernel before, that might take two afternoons to figure out.

Putting it in pid1 is mostly driven by cgroups (the Linux kernel's hierarchical process-grouping/resource-management system). The initial kernel design for cgroups was that it was a shared resources managed via a pseudofilesystem (cgroupfs), but the developers of that subsystem seem to have decided that design was unworkable, and are moving towards a design where there can be exactly one userspace controller of the cgroups system at any given time. That more or less has to also be the process supervisor, or else you can't really do sensible things with tying resource-management to services (and increasingly, containers). And that all has to happen when the system is brought up, too. So either it needs to be in PID1, or it needs to be in several PIDs that are tightly coupled via an IPC mechanism. The systemd designers consider the second design more complex and error-prone. See e.g. here, plus a third-party comment here.

From your link:

1.8 No constructors

Functions can serve the same purpose as constructors without adding any language complexity.

How many good OO language exist without constructors? Maybe only javascript. This seems like a terrible decision.

Or maybe an informed one. Go and Rust -- objects without class

Besides, Rust isn't an "OO" language. It's a multi-paradigm language that supports pure-functional, concurrent-actor, imperative-procedural, and object-oriented styles. After 40+ years, a growing opinion seems to be that pure OOP isn't without its problems, and other approaches may fit development goals better. I'm not sure multi-paradigm languages are the answer (there seems to be a huge potential to be confusing, IMHO), but OOP isn't the evolutionary pinnacle of language design that the last few decades of hype would have us believe. I'm willing to give this approach a chance (and I'm always up for learning something new).

Critcisim of the OOP paradigm

(Aside: Not quite sure why, but the use of the term "paradigm" multiple times makes me feel slightly icky for some reason. Probably due to it's misuse in business jargon.)

Sadly, the rt-linux project is all but dead. http://lwn.net/Articles/617140... Unless this changes quickly, such linux-based projects will no longer be possible.

Been tried already; see gnutls. We tried to switch from OpenSSL to gnutls as the preferred SSL library for PostgreSQL a few years back, even got some press coverage documenting the whole thing. But, sadly, OpenSSL has too many quirky APIs to make a transition away from it easy. And anyone who tries to be "bug compatible" creating a replacement to that mess is going to inherit some of the same bad design that needs to be burned with fire.

The linked LWN article meantions some reasons: Among them that Kawa is much faster than closure (both execution speed and start-up speed). Plus some might like that Kawa is mostly-compatible with a pre-existing independently-specified language.

From this article here it appears that shingled hard drives are not completely random-access for writes. They will probably need some sort of flash-like translation layer to support normal file systems. (Or Seagate has provided that layer internally like SSDs do, in which case as a first-generation device it is probably buggy and will lose your data...)

LWN: https://lwn.net/Articles/62497...
kernelnewbies: http://kernelnewbies.org/Linux...
omgubuntu: http://www.omgubuntu.co.uk/201...

Thanks, but I'd be surprise if that happened.

1. You may have noticed that the "story" submitter is Jaromil, so I suspect (extrapolating from experience) he's accompanied by his sock puppet army (do they imitate the NSA with forum flooding and FUD techniques, or does the NSA imitate them?)
2. I've always suspected that the NSA is actively involved in ceasing this opportunity to divide Debian, if not celebrating the number of senior Debian developers who have left due to the number of personal attacks and threats they've recieved from the "anti-systemd" "campaign"

Jaromil does some excellent graphic work - but his musical ability is more autistic than artistic, allowing for a broad spectrum of tastes... and his "software accomplishments" is less than truthful (his hasciicam program lacks truthful attributions to it's true basis, and his Dyneobolic distro is just one of very many "respins". Not a patch on Knoppix - which is the work of one person , or a shadow of Mint and other Debian derivatives. There have been many Debian fork attempts...

Some vaguely related trivia regarding your pseudonym. Unix was a joke name chosen by the developers of Multix - the operating system that was intended to "do everything", when their funding was cut. Eunuchs/Unix was the result. Linux was the name given to Linux Torvalds to create a non-Unix compatible kernel.

apt-get install sysvinit-core

more insightfult news and posts from lwn. Regarding burnout and voicing concerns over systemd. lwn.net lwn.net

more insightfult news and posts from lwn. Regarding burnout and voicing concerns over systemd. lwn.net lwn.net

Once again you just disregard already given information. I summarized the bug and the related posts, but since you are going to whine regardless, I'll have Jonathan Corbet of LWN do the honours.

His article has all the links, to the bug and the related discussion. Of course you are going to cherry pick single posts again, but at least the peanut gallery will get to see who is being disingenuous here.

And this is my last word in this entire discussion. I have nothing to prove; you just have to show that you can do more than cherry pick to justify your irrational hatreds.

Another turn in the wrong direction, in my opinion, is Wayland, which breaks many highly useful (to users) capabilities provided by X11.

If Keith Packard thinks Wayland is a good idea, I'm inclined to trust him. And, he does.

Perhaps you don't fully understand what Wayland is or why the senior X11 developers think it is a good idea. Please read through this and see if it changes your mind:

http://www.phoronix.com/scan.php?page=article&item=x_wayland_situation&num=1

Newer versions of GNOME (3.8 and after?) rely on a DBus API of systemd's logind component, for reasons I've never seen adequately explained.

The talk of forcing all cgroup interactions to go through systemd would in effect make anything that interacts with cgroups or cpusets such as hwloc, TORQUE, and SLURM rely on systemd. I can't imagine that the developers of hwloc, TORQUE, and SLURM are especially happy about that.

That there can only be one cgroup manager at the time is caused by the cgroups developers decision to make a unified hierarchy tree with only one canonical manager instead of exposing cgroups fs directly to end users. systemd is just an example of such a manager. If you don't use systemd, you can just use another cgroups manager instead.

Regarding SLURM, they are of course starting to integrate systemd in their project. I assume most other cgroups projects are doing the same.

> It's not like the journal format is some state secret. It's documented
> and there are already several journal parsers to choose from.

Please explain http://lwn.net/Articles/468049...

> From the FAQ:

That LWN article is 3 years old and very outdated. The systemd developers was still developing the journald in those days, so they didn't want to freeze the API etc. it until they thought it was ready.

The journald log file format have been stable for a very long time now. Here is the developer info and documentation:
http://www.freedesktop.org/wik...

There are already independent journald readers and several log watch programs that query the journald directly.
Most tellingly; rsyslog can now read systemd journals directly. No need to forward syslog messages to it anymore if you use it as a log sink. It can read and write journald log files directly.

Here is a list over stable API's in systemd:
http://www.freedesktop.org/wik...

> It's not like the journal format is some state secret. It's documented
> and there are already several journal parsers to choose from.

Please explain http://lwn.net/Articles/468049...

> From the FAQ:

> Will the journal file format be standardized? Where can I find an explanation
> of the on-disk data structures?

> At this point we have no intention to standardize the format and we take the
> liberty to alter it as we see fit. We might document the on-disk format
> eventually, but at this point we donÂ't want any other software to read, write
> or manipulate our journal files directly. The access is granted by a shared
> library and a command line tool. (But then again, itÂ's Free Software, so
> you can always read the source code!)

I found this when I was researching "OMG!#! systemd even includes QR code library." Why would they do that? They are smart guys after all, they don't do things without purpose. Then I found this gem. It is actually used to ensure the system is intact and no one has tampered with logs, etc:

http://www.h-online.com/open/n...

It's called Forward Secure Sealing: http://lwn.net/Articles/512895...

Another small gem is "Why, oh why, they created NTP clone?" There is a very good rationale for that, like having coherent timestamps on embedded device boot:

https://wiki.archlinux.org/ind...

Naturally these are optional, and not forced upon you.

Newer versions of GNOME (3.8 and after?) rely on a DBus API of systemd's logind component, for reasons I've never seen adequately explained.

The talk of forcing all cgroup interactions to go through systemd would in effect make anything that interacts with cgroups or cpusets such as hwloc, TORQUE, and SLURM rely on systemd. I can't imagine that the developers of hwloc, TORQUE, and SLURM are especially happy about that.

No matter how I swing it? How about I use my system, then I get So it's more like 5:1:1 in favour of systemd.
The Debian charta is using the Schwatz set to determine with system wins.

> A.6.6: Schwartz set is {D,U}
> A.6.8: There are no defeats in the Schwartz set, so the elector with
> the casting vote chooses which of these options wins.
>
> Per 6.3.2, the casting vote is held by the Chairman, who is currently
> Bdale.

http://lwn.net/Articles/585363...

sysvinit is full of hacks, like start-stop-daemon, the mysterious /etc/init.d/functions, environment variables hackery like "# Check that networking is up.
[ "${NETWORKING}" = "no" ] && exit 6", loops, pid files, and so on. Which all belongs in a proper init system.

As PID 1 it is the parent process of all services, therefore it can observe them all. No PID file hackery needed.

rsyslog vs. journald you can read for yourself
http://blog.gerhards.net/2011/...
http://blog.gerhards.net/2011/...
http://lwn.net/Articles/470058...

xinetd and systemd
http://0pointer.de/blog/projec...
IMHO socket activation belongs into a init-system.

To which Ubuntu forum users massively agreed that this would make a great release name !

Oh come on! There are only 6 hundred distributions.

You misunderstood the video. Nobody is using the X protocol to send stuff over the network, the 2D graphics primitives. It's all bitmaps, using extensions to X. I've been looking but I haven't found a better summary. This article goes into some of the security problems of X, which could be summarized as "X doesn't do security." Another issue is the conflict between popups and screensavers, which can't be fixed without breaking X.

Mostly I think that you are hung up on your misunderstanding of network transparency, and that you enjoy ranting. I would suggest that if someone slapped you upside the face to where you realized that you were an ignorant cuss, and you wished to remedy said ignorance, you might go bother the wayland IRC channel, or Daniel Stone directly -- his email is on his blog.

Wayland is not a thing you should be fighting. It's not going to steal your lunch, and it doesn't seem like it's going to be ready for prime time for years yet to come, and nobody is ever going to force it on you if you like the broken shit you're used to. Also, regarding network transparency, you should be happy that Wayland isn't trying to absorb that into its mission -- or do you prefer the systemd approach? If you get around to figuring out why it's out of scope for the project, you might be able to make some constructive comments on the matter. As is, you're hurling insults at all the people going the wrong way -- because you're too dumb to know you're in the wrong lane.

Binary logs are also far more secure, but I guess that doesn't matter to you.

Oh horseshit, what you speak of is security by obscurity. By the same token you could say gzipped logs are more secure than non-compressed logs. When reading a binary format is well understood it's not an increase in security it's merely pig-headed obfuscation for the sake of itself, a sentence that describes the intentions and outcome of the entire systemd project perfectly.

You seems to misunderstand how the signed logs works in systemd: the logs are perfectly readable by anyone with the right permissions. There is no encryption going on, only secure signing. (striclty speaking it isn't signing, or hash' chaining)

There is no signing key on the computer that can be extracted. The key is only used once to sign the first log segment, then removed from the system, the next signing key is generated on the basis of the first and so on. systemd makes cryptographically secure sealing called "Forward secure sealing". The concept is old in the crypto world, here is an introduction to how it is done:
http://lwn.net/Articles/512895...

If you're reliant on trusting the logs of a system that you think might have been compromised you're already shafted. If an intruder can edit your plain text logs then they can edit everything else on the system as well, including binary ones; hacking is generally more sophisticated than vim /var/log/daemon.log dd dd dd :wq. There's nothing inherently unhackable about binary logs and if your box is rooted your only real option is to burn the hard drives to the ground and reinstall.

That simply isn't true. If a hacker gets access to gpg encrypted mails, he can't read or alter them undetected if he doesn't have the key. Same with systemd journal logs with "Forward secure sealing". This isn't hash'es but strong crypto security like gpg. The concept is quite old in the crypto world:
Here is an introduction to FSS:
http://lwn.net/Articles/512895...

have a read of this. http://lwn.net/Articles/512895...

this might help. the binary log files are subject to Forward Secure Sealing - http://lwn.net/Articles/512895...

Here's a public link to the article.

1) You can still use rsyslog (or syslog-ng or ...) with journald if you want and I believe all the major distros still do: http://blog.gerhards.net/2013/...
2) journald supports "Forward Secure Sealing" to prevent tampering of its logs: http://lwn.net/Articles/512895... See the "Seal" option in journald.conf: http://www.freedesktop.org/sof...

but the fact remains... Windows/Microsoft has been playing catch-up in security where Linux has been leading over the last decade.

So where are those facts?

Because they way I look at it there has been several embarrasing, high-profile successful attacks on Linux servers over the past few years:

Debian server compromised: http://www.zdnet.com/debian-se...
Ubuntu servers compromised: http://www.theregister.co.uk/2...
kernel.org compromised: http://lwn.net/Articles/457142... (we're still waiting for the post morten on that)
linuxfoundation.org and linux.com compromised: http://thehackernews.com/2011/...
red hat and fedora servers compromised: http://www.cnet.com/news/red-h...

(and we do not even mention the OpenSSL fiasco)

So where are the widespread Windows Server compromises?

To be frank, I don't think anyone bothers reporting on them anymore. For a journalist "Linux server compromised" sounds far more sexy than "windows server compromised." These guys, after all, have to get readers in order to put food on the table.

but the fact remains... Windows/Microsoft has been playing catch-up in security where Linux has been leading over the last decade.

So where are those facts?

Because they way I look at it there has been several embarrasing, high-profile successful attacks on Linux servers over the past few years:

Debian server compromised: http://www.zdnet.com/debian-se...
Ubuntu servers compromised: http://www.theregister.co.uk/2...
kernel.org compromised: http://lwn.net/Articles/457142... (we're still waiting for the post morten on that)
linuxfoundation.org and linux.com compromised: http://thehackernews.com/2011/...
red hat and fedora servers compromised: http://www.cnet.com/news/red-h...

(and we do not even mention the OpenSSL fiasco)

So where are the widespread Windows Server compromises?