Seems to me that if you are a "local user", which is someone with access to the actual keyboard of the server, you likely have direct access to the actual server itself, which is even more a security risk.
Slashdot videos: Now with more Slashdot!
We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).
From where I sit, the opposition is from people who don't like, approve or trust how systemd is incorporating more and more into itself. It smacks some people of bad design, bloated design and insecure design. Plus, it's the kind of behavior most often seen and witnessed by the historical enemies of Linux; it's the method of feature creep that reminds people of Microsoft and others, designed to make it difficult, if not impossible, to use anything else... ("lock-in" by another name). I'm sure that much of the "small elite" in opposition are opposed because Linux was supposed to be the revolution that got us *away* from that sort of monolithic control that they see systemd as.
As for me? meh.
Although there was strong opposition to the move from the older and more conservative SVN devs, and reportedly a lot of grumbling and ranting when the vote was tallied, a member of the PMC (who asked to remain anonymous) told the author that "this [migration] will finally let us get rid of the current broken design to a decentralized source control model [and we'll get] merge and rename done right after all this time.""
Link to Original Source
Linus gets it wrong again: The ASF does NOT require CLAs for "drive-by" patches. It only requires them for official contributors or committers, not for people providing patches on email lists, via JIRA, etc... Only when people have obtained the merit to directly change the official code is an iCLA required. As it *should be* for IP tracking. Double shame!
With Eclipse and Apache, the CLA is a Contributor License *Agreement*. It is NOT a Copyright *ASSIGNMENT*. Shame on Linus for spreading such FUD!
Ahhh... good ol' jagubox. I recall that old A/UX server warmly and credit it with my 1st real "claim to fame" on the Interwebs. But jagubox is, sadly, no more, having long ago been retired after I left NASA. There are a handful of mirrors around, last I checked.
Thx for the memories!
Here's a dime. Buy a clue.
First of all, Outercurve != Microsoft.
Secondly, I work for Red Hat, which is open as Open Source as you can get.
Thirdly, I am also on the board of Apache and OSI. Maybe you've heard of them.
Fourthly, your ignorance is showing.
Fifthly, Bananas are the Atheists' Nightmare.
Just to be clear, I did not "sell out" nor did anyone associated with Outercurve. It's a shame that little brains can only hold so much info before their lower intestines take up the load.
Why? A couple of reasons. First of all, it was the basis for Apache entering into the EC and the JCP. Our involvement was predicted on the ability to obtain TCKs for Apache projects. Secondly, the ASF was promised it, but then denied the TCK (actually, an *open source compatible* TCK), and that's simply Not Right. Finally, the goal of creating s/w is that it be used, and the lack of certification significantly hampers that, as well as opens the project to submarine patents. Think Oracle is going to sue itself?
Ahh, but then s/w patents aren't necessarily patents of algorithms. Lets define, exactly, what constitutes a software patent by defining what a "good" one is, and then we can debate whether the concept is OK or not.
The issue is that Oracle controls who gets the TCK and they put restrictions on it for Apache that they didn't put on for themselves (OpenJDK). Despite having a signed agreement to the contrary as well as agreeing w/ Apache back before Oracle bought Sun.
And yet, you are here as well...
Also, to be clear, even though I'm mostly associated with the ALv2, I hack and develop code under a bunch of other license as well, including GPL, et.al.
A license is a tool, and you pick the license based on how you want, or don't want, your code to be distributed, used and shared. There is no one-size-fits-all license, and your choice of license should be done with some thought, not based on who has the longest or bushiest beard.
Both the Microsoft Public License and the Microsoft Reciprocal License are Free and Open Source licenses (as determined by the FSF and OSI). The others ain't and so there's no need to use them, imo.
Typo: It should be the 'EC' not 'EA': Executive Committee