We need to wait for a better solution in Jessie+1

Posted Feb 13, 2014 6:39 UTC (Thu) by roskegg (subscriber, #105)
In reply to: We need to wait for a better solution in Jessie+1 by mpr22
Parent article: The Debian technical committee vote concludes

All GNU software requires a CLA to the Free Software Foundation; why quibble when Canonical asks for it? It gives them the guaranteed legal standing they need to defend the software from legal attacks.

Issues of "standing" are very real in court rooms. If you don't have "standing", a judge will throw your case out without hearing it.

Since the software is released under GPL, how does the license assignment hurt anything?

I am viewing this move toward systemd with alarm.

First, some schmuck made it so I can't tar/backup/archive my own home directory, because of a stupid little non-readable directory that makes tar barf. Not sure if it was Poettering responsible, but it was definitely endorsed by the Gnome/Pulseaudio crowd. Pulseaudio, what a fiasco. First, they make files that break automated backup tools. Then they make binary formats.

There is a time or place from binary formats, but the ESSENCE of Unix is that everything is a stream of text.

I came to Unix to get AWAY from the bloat and binary obfuscation of Windows, COM/CORBA.

Especially when it comes to the base system. I need to be able to view my systems configuration and logs in vi.

Poettering and the Gnome cabal are trying to imitate M$ Windows. They are spitting on "The Unix Philosophy" outlined so well by Goncarz, and explained in such beautiful clarity by Eric Raymond in "The Art of Unix Programming".

What the hell, Red Hat? You've been subverted by the NSA? Why are you hiring all these Microsoft weenies to spoil our POSIX operating system?

We need to wait for a better solution in Jessie+1

Posted Feb 13, 2014 6:56 UTC (Thu) by fandingo (guest, #67019) [Link] (1 responses)

There are significant differences between the FSF CLA and the Canonical CLA.

1) The FSF is an American 501(c)(3) charitable organization. If the FSF were to go bankrupt, and the assets liquidated by a court, they cannot be liquidated in a manner inconsistent with the charity's principles. This doctrine is known as cy pres. That means that FSF copyrights could never be sold to an organization that would license them under nonfree terms. Canonical is a commercial company, and those assets could be sold to a company that could relicense the code under proprietary terms, although the current versions would also still exist under the present license.

2) The FSF makes explicit, legally binding promises that they will never relicense (or dual license) the code in a proprietary manner. Canonical does not do so.

3) The Canonical CLA requires that you attest to owning *any* patents that may exist on a work. If a contributor does not know that a contribution infringes a patent, and the holder of that patent sues Canonical, Canonical could seek legal recourse from the contributor. The FSF has no patent attestation clause.

The most that could possibly go wrong with a work handed over to the FSF would be a future license version is at odds with what the contributor intended. Again, the code will always remain free because they promise to do so. It would be more like you contributed when GPLv2 was the newest version and were unhappy that the work is now GPLv3.

The Canonical and FSF CLAs couldn't be more different, and it's not fair to compare them.

We need to wait for a better solution in Jessie+1

Posted Feb 13, 2014 15:57 UTC (Thu) by madscientist (subscriber, #16861) [Link]

Additionally, the FSF licenses back to you the code you contributed (but only your code!) so that you can reuse it for any purpose (not just under the GPL). The only right you give up is the actual copyright: the license you have gives you back every other right, including to relicense in a different way.

So if you develop some stand-alone code and then assign copyright to the FSF, you can still take that code and use it in your proprietary program if you want (as long as it doesn't derive from any other GPL'd code, that you didn't write, of course).

We need to wait for a better solution in Jessie+1

Posted Feb 13, 2014 8:58 UTC (Thu) by tao (subscriber, #17563) [Link] (5 responses)

What's the non-readable Pulseaudio-related directory you're talking about? I'm curious; I haven't seen anything like that (I'm using Pulseaudio), but obviously that's no guarantee. Also, there's no GNOME/Pulseaudio crowd. They are two different groups of developers.

Again, as others already explained, if you don't like binary formats, just set journald to pass-through mode and use rsyslogd, or keep the journald settings as they are but run rsyslogd on the side (that way you get your beloved text-logs, which still having the extended logs that journald provides available side by side).

The system configuration for systemd is done using text files and are much easier to overview and understand than initscripts.

TINC.

Also, towards the end of your message you really sound like a troll. Next time try to plead your case with rational arguments instead of troll-like behaviour.

We need to wait for a better solution in Jessie+1

Posted Feb 15, 2014 22:42 UTC (Sat) by lsl (subscriber, #86508) [Link] (4 responses)

> What's the non-readable Pulseaudio-related directory you're talking about?

It's probably just a mounted FUSE filesystem. Per default those can't be accessed by root to prevent random users from DOSing or at least annoying root's processes.

There's no connection to Pulseaudio.

We need to wait for a better solution in Jessie+1

Posted Feb 16, 2014 1:51 UTC (Sun) by roskegg (subscriber, #105) [Link] (3 responses)

Yes, that one. That is a crime that was committed at the Linux kernel developer level.

NOTHING should be withheld from root. When I am root, I want to be able to access my directories! Also, since all the permissions were turned off, even running tar with the correct user permissions didn't work. It is frickin UGLY.

We need to wait for a better solution in Jessie+1

Posted Feb 16, 2014 2:35 UTC (Sun) by mathstuf (subscriber, #69389) [Link]

Personally, I'd much prefer root getting -EPERM than infinite looping in "ls". I suppose you could ask for a FUSE sysctl knob like fuse.footgun, but that's your fight ;) .

On the root-is-omnipotent front, have you heard of Secure Boot? I think it has benefits for groups like schools and companies who want to ensure that *their* hardware is used as intended, not by the student or employee. If I have root, it is not necessarily true that I own the hardware too (e.g., installing packages might be relevant for teachers). The fear with SB is that manufactures will start "owning" hardware they sell indefinitely. *That* is valid, but it is not a reason to not do it.

We need to wait for a better solution in Jessie+1

Posted Feb 18, 2014 21:30 UTC (Tue) by Wol (subscriber, #4433) [Link]

Actually, that's one of the biggest Unix MISfeatures, imho, the ability for root to do anything.

From Rev19 onwards, Primos had ACLs. The one thing you couldn't take away from the superuser was the ability to override them (actually, it was implemented as a "priority acl").

So if I was testing stuff that required to run as super-user, I could just do a "set-priority-acl live-data superuser:no-rights", and then be CERTAIN that however badly I screwed up, I couldn't damage the live system. Once I was happy it was all working, I would delete the priority acl and could run the script for live.

After all, if the super-user always has the ability to edit access rights, then any (by default) lack of access rights merely makes things that little bit harder. Which is what you want - the last thing you want is the system making it easy for finger-trouble et al to cause a disaster. It's a safety-catch, not a barrier.

Cheers,
Wol

We need to wait for a better solution in Jessie+1

Posted Feb 18, 2014 21:56 UTC (Tue) by rodgerd (guest, #58896) [Link]

Just because you're root doesn't mean they're your directories.

Anyone who has worked as a sysadmin for anything other than their own toy boxes should understand that.

We need to wait for a better solution in Jessie+1

Posted Feb 13, 2014 15:15 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

> There is a time or place from binary formats, but the ESSENCE of Unix is that everything is a stream of text.

So why the exception for things like compiled code? That's a stream of binary. The reason is that the tradeoffs are worth it and you have tools like nm, ldd, and readelf to coax text streams from them, so why would journalctl be much different? Just because something has historically been text doesn't mean it's the best solution forever (git tools slowly migrate from shell/perl to C which has caused me to go track the source down on multiple occasions).

> I need to be able to view my systems configuration and logs in vi.

Configurations are going to be text for a long time (though you have hashmap for postfix, so there are exceptions already) and ISTR journalctl being able to work even on Windows, so log viewers should be possible nearly everywhere.

> Poettering and the Gnome cabal are trying to imitate M$ Windows.

If you mean the fact that Windows has stable APIs which work across all instances, sure, I could see that. Other than that, systemd has *many* more features than Windows' init. Also, just because Windows does something doesn't mean it's bad and we shouldn't do it on principle. I agree that there is a lot of crap I'd never want, but I don't see those things happening in systemd (here's the binary logs, but journalctl is nice enough to forgive that).

> Why are you hiring all these Microsoft weenies to spoil our POSIX operating system?

Where are the new hires popping up from nowhere to work on it? If you're referring to Lennart himself, that's a *long* play by Microsoft.

You're also aware that Linux was never POSIX certified, right? RHEL is and Windows was, but the kernel+coreutils never was.