From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
This should be avoided like the plague because of the choice to use MIT over GPL.
Any work dedicated to this can and will be stolen by corporations without giving back if they find it useful. This is what happened with Sony and Apple and their respective operating systems. They chose to base them on BSD so they could steal work and not give back to the public.
Do not be fooled.
They chose to base them on BSD so they could steal work and not give back to the public.
"Here you can use this as you like, no questions asked"
"Hey! Why did you use that in a way that I told you you could!?!?"
i think the argument here is more that saying "you can use this however you like, no questions asked" is a bad idea because it allows corporations to approriate the work
Right. Instead say "here you can use this as you like, and if you improve on it, share that with everyone in the same way so we can all benefit from it." Is why GPL is better.
yes. that is why he is saying go with the gpl or at least if your adding code add it to gpl unless you are fine with your stuff being used but nothing coming back to the communities by others.
They chose to base them on BSD so they could steal work and not give back to the public.
Emphasis mine.
Yeah I think you are just ignoring context. He means steal the way someone just taking advantage of the commons might be said to. Ugh he only comes to these things so he can steal away a bunch of pastries back to his pad. The language is to mean that the bsd license allows folks to steal while the gpl requires reciprocity.
The intent of the BSD licences is to allow you to do what you want without reciprocating though. It's not an accident, it's explicitly stated. It is, in fact, your right. You profiting from the work of others is an intended result.
I prefer GPL myself for this reason. But you can't blame companies for obeying the terms of the licence.
But that is what he was actually saying. His comment was he would rather see it as gpl because mit effectively allows the hard work to be stolen like what we saw with apple and bsd. Hes not blaming apple he is just saying he would not have issue if it was gpl instead of mit. Again its like you have to look at the whole message and context for meaning rather than the strict definition of the one line.
It can't be any sort of "theft" if you leave it on the curb with a sign saying "Free" next to it.
ugh. I feel like you did not read my reply. Im saying his use of the word theft should not be taken literally given the context of his statement. he was not looking to say apple stole code he was looking to say use gpl because otherwise corps get code and don't contribute back.
It's you who says it's not a literal use. But I'm protesting even a figurative use since there is NO way the act is THEFT. I didn't steal, in any sense, something that is given to me for free.
It's not like improper use of "steal" is unheard of, I see all the time people use "I'm gonna steal that" and similar even when it applies to things openly given for free. And considering that it's quite clear that the MIT allows others to take without sharing back (it's the main difference with GPL) I'm quite sure the commenter was aware that it wasn't really theft, yet chose that word probably with the intention to insult the practice, rather than as a fair descriptor.
So yes, you're right, it isn't theft... but I don't think that was the point of the comment.
I don't think you understand what the word figurative means.
yes that's exactly what he is criticizing.
Serious question: could we not just fork the project under the GPL and use that?
Isn't this the reason for the switch? I thought MIT was the whole reason they were making the switch.
The reason Ubuntu switched was Rust's "safety". Which is sort of a dumb reason because Coreutils have had very few CVEs in the past. A less dumb reason is performance. Uutils are faster than Coreutils, this was an edge-case.
MIT license is the schizo reason. Making a closed source version of Unix utilities would not be beneficial for Canonical in any way, but that does not stop the schizos from schizoing.
They didn't "steal" anything. The developers choose that license. It's very clear what it allows.
Do I understand the article and github issue correctly and we can put away the pitchforks already because they fixed the specific part already and it's now even more performant than GNU coreutils?
No, you are supposed to stop reading after the headline, and then make a comment, not read the whole article.
Yes
Rust is great, but might it be a bit premature to replace the venerable coreutils with a project boasting version number 0.2, which I imagine reflects its author's view on its maturity?
The author simply listened to the word of 0-Based Versioning. It says more about your maturity than of the projects. Much to learn you still have.
Version is just a number, just like age. (of Rust, of course)
A major version of 0 isn't necessarily any statement regarding the projects maturity, it can also be a hack with semantic versioning. Normally, any change that is not fully backwards compatible requires you to increment the major version, but if the major version is 0, you may only increase the minor version. Because of this, many projects stay at the 0.x.y versions, so they don't need to release version 2.0.0, 3.0.0, 4.0.0 and so on just because of minor but breaking changes as many users might expect significant new features from that version steps.
They don't need to use semantic versioning. I doubt coreutils itself uses it, though I admit I haven't checked. Actually I think semantic versioning is less popular in practice than it looks like.
For a set of tools to that completely replaces another one, announcing a 1.0 version would be a message that the developers think the project has actually reached its initial goals. "0.2" does not.
Wasn't rust suppose to both more performant and more memory safe than it's C counterparts?
Rust and C are the same "tier" of performance, but GNU coreutils has the benefit of several decades of development and optimization that the Rust one needs to catch up with.
Language isn't everything. While Rust provides some features and safety that C doesn't while being roughly equivalent in performance, the algorithms that developers choose will dominate the performance impact on the program.
GNU core utils has decades of accumulated knowledge and optimisation that results in the speed it has. The Rust core utils should in theory be able to achieve equivalent performance, but differences in the implementation choices between one and another, or even something as simple as the developers not having prioritised speed yet and still focusing on correctness could explain the differences that are being reported.
Well the entire point of the project is that they used algorithms/features of Rust that make it easier to write fast code. This article basically reports on a "bug". Uutils are in many ways already faster than Coreutils.
Correctness is really more of a byproduct of using Rust. Coreutils have had only a few CVEs in their lifetime so it would be sort of redundant to rewrite them in Rust for "correctness".
Rust never claimed to be more performant than C. Its performance is equivalent to C.
Rust is fundamentally more limiting than C, even with unsafe. It is often faster if you write naive code (because the Rust compiler can optimize more aggressively due to those same limitations), but an experienced developer with a lot of time for optimization will probably be able to squeeze more performance out of C than they would out of Rust - as you can see in this example. Rust is still better because those limitations all but guarantee that the resulting code will be safer, and the performance differences would be negligible all things considered.
you can still mostly hand-write assembly in rust
Sure, but at that point you can also just write assembly. I'm talking about "idiomatic" code in the language itself.
It's more a thing like in ripgrep vs. grep; new algorithms being vastly faster in most cases except in some.
This would never happen if it were licensed under GPL. /s
Although if it did happen they could be sued for breaking it. I really don't get the sarcasm here. with mit/bsd not giving back is fully legal with gpl its not.