More extreme people may see it as a major milestone in “killing” GPL.
At some point the GNU project focused their attention more on leading “gnu + Linux” debates and not so much on developing a stable and secure OS. So now it’s legacy cruft.
What happens if the uutils team says that they're not releasing the source of the latest version but the $CURRENT-5 from now on, moving to a closed source, open baggage model? What prevents them from pulling an effective EEE?
I don't follow this argument. This can happen under GPL as well. Nothing stops the copyright holder from relicensing future versions of the software under a different license. The existing versions already out there under GPL/LPGL/MIT/BSD, there's no take backs, but the copyright holder is free to do whatever they want with future versions.
What would happen in your hypothetical scenario is that everyone would get really really angry with the uutils team and the latest open source version would get forked by the community. The proprietary one would wither and die, because who in their right mind wants a proprietary set of coreutils?
Fundamentally, the choice between copyleft and permissive is simply if you care that someone takes your software and incorporates it into a proprietary package. Clearly, the uutils team doesn't care if eg. Apple makes a proprietary fork of uutils for OS X. And that's their prerogative.
Accepting contributions without a CLA does, because then there's too many copyright holders to do so.
The GPL is an attempt at software freedom by restricting freedoms to have a lever that leads to greater overall freedoms.
In some way it has worked for the Linux kernel if you look at contributions wrt drivers. But I am not sure so much that it worked so well for other aspects
I choose GPL, because I do not code these tools with my programmer hat. I code them on my free time, primarily for myself, to be used by people who appreciate the work went into them and find these tools beneficial.
These tools, while vary in sophistication, are high quality items which are built for their users, and not open to be monetized by another company just because they can build something with or on top of it.
I have no qualms with Open Source software when done honestly. Most of today's Open Source projects are not honest.
Try to deploy a service or compile an Open Source tool solely from the provided source code. 99.99% of the time you'll wish that you land flat on your face, which would be easier and less painful.
I choose GPL, because not only I promise that you'll be able to build the thing I released, I promise that I'll make it buildable with minimum fuss and effort as much as possible.
What I put out is complete opposite of a run of the mill Open Source Software. Free, easy to understand, easy to build, no moats whatsoever. It's a gift instead of a window dressing. It's a free offering with no strings attached instead of "fix our code, so you might get internet cookie points in return". It's crafted instead of produced.
* With the exception of diff3.
The problem with permissive licenses started in my eyes with companies abusing the freedom they provide by creating *ium projects and started to push closed source applications with pseudo-open-source *ium projects. Also the same companies get these software fork it, add a small thanks with a 3pt font, printed to the space between the last page and back cover, and be done with it.
This is not illegal, but against the spirit of open source in general, and harmful on the long run.
As someone said: Open Source is about developer freedom, Open Source is about user freedom.
And developers are users of the software they don't develop, and they're cutting the branches they're sitting on.
On the whole, I am firmly against Open Source and would generally go with Source Available, but this seems like FUD.
First, you need to ship the source of that GPLd binary with the binary itself. Second, no derivative of that source code (and the binary as a result) can have a different license unless you're the copyright holder on that source code.
On the whole, I am firmly against Open Source and always go with Free Software, but this seems like incomplete knowledge.
edit: Added the "Note" section in the beginning. There was confusion it seems.
Yes, you're right. And you play e-mail ping-pong while trying to find the correct person in most cases. IIRC Linksys got into "warmer than usual" water because of not honoring the offer.
If you link, or modify the code, then you have some license issues. FUD.
The license states the following[0]:
3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:
a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.)
The same applies if you're hosting a SaaS with AGPL license.
Sorry, but I'm too old for this FUD thing. I neither have the motivation, nor the desire, nor the reason to do it.
I again edited the comment which lead to the confusion.
The issue is with GPLv3.
So, companies doesn't like to share their source code in a usable form if they're not against GPLv2 but are against GPLv3.
Companies are being companies. It's not about the license, but allowing others to use their code on their products. So they're after smoke and mirrors, and when their mirrors are taken away, they have moved to mirrors that work.
Am I understanding that right?
But yes, companies are much less interested in people modifying software on devices they sell. It isn't smoke and mirrors, there are just different reasons that different individuals support open source software. And there's different licenses to suit different purposes.
I get a similar feeling. This is more attractive than ports like cygwin as a solution because if you have this in every place you can be more sure your environments match. With ports there will be more delay getting changes/fixes in different environments, at least in theory, than with a solution that is cross-platform as a core goal. The other main options, running Linux in a VM (directly or via WSL2) adds an extra layer of friction.
A cross-platform solution is more likely to match bug-for-bug in different environments, which can be as important as matching feature-for-feature: if something is going to fail out there it will fail the same way in your dev/test environments.
Also some will want to use it from a licensing PoV. Many¹ find GPL related licences bothersome and use the GNU coreutils because there isn't (until this matches their requirements) an alternative. Similarly, the language might be an attraction to some, either ideologically or because they might want to dig into the source, though this is more of a factor for projects developing new features rather than trying to be drop-in replacements.
I expect the attraction to be relatively niche though, people won't start using it as a drop-in for the GNU tools en-mass until, for instance, popular distributions use it (or a niche distribution using it becomes more popular for some other reason).
----
[1] I am not one of that many, but they are many so this is a notable consideration.
I think it's important for free software that people coming into the community are enthusiastic to maintain it. It took the wind out of my sails a little when I realised the GNU code base, while it produces critical tools I use every day, is written in a way that I found extremely (unnecessarily) terse and "clever". Tracing how different combinations of flags are handled is not much fun. Documentation is helpful for the user, less so for the tinkerer who is trying to understand the stack.
If this project manages to hit parity with GNU coreutils, and my distro(s) provide support, I'll switch to it purely on that basis.
It's a different mindset and one that is no longer useful.
I disagree. Sure, 6 bytes is approximately free in most contexts, but 100MB is not free, and 5GB is even less free.
But more importantly, writing code under constraints can force good behavior. For example, BIOS is a legacy mess but it’s a small, self-contained legacy mess that fits in a few kB. Compare to UEFI, which is unbelievably complicated and bug-ridden. A mess like UEFI could not have fit within the constraints of BIOS.
This is not to say that writing obscure code to save a couple bytes of source file size is at all worthwhile any more, but the idea that one should constrain bloat (design bloat, code bloat, executable bloat, network bloat, etc) is very much still valuable.
While user facing programs are not faster by any means, computers got faster in some aspects after all.
What your greybeard might have been talking about was to do with interpreted languages where the interpreter had to parse through the code in some situations when performing a jump/goto. This meant that the more characters there were between the jump origin and destination, the slower execution was. I remember this being a factor in early 8-bit BASIC implementations, leading to a desire to make programs as terse as possible to achieve fast execution. Later implementations tokenized the source before execution, avoiding that problem.
He started these things with punched cards, and worked at the prominent companies of the time (like IBM and HP), and seen tons of bizarre computer architectures on the way like registerless processors.
He might be recalling a very specific example, or about a very slow system, but I remember the conversation well.
That thing has been probably sorted out by the mid of 90s, but I was just starting programming back then.
Oh, I'm a proud member of "descriptive variable name mafia", but not affiliated with the Java branch. They're a different breed. On the other hand, being written real math in C++ (differential equations), having three letter variable names for everything is equally painful. :)
Never again.
My preferred line-width for code would be 80 characters, not including indentation for the line, with a maximum of 120 characters including indentation.
CMMetadataFormatDescriptionCreateWithMetadataFormatDescriptionAndMetadataSpecifications
So, saving as many bytes as possible is still very relevant.
That attitude has got to die in an age of everything being exploited by bad actors. Anything that has any form of networking should have regular replacement at least of the control plane components budgeted in from the start.
You're not going to find a 30 years old machine that controls the pumps of nuclear reactor on the internet.
Stuxnet would like to have a word with you. Airgap isn't enough to prevent malware from spreading.
The longer our devices can last the less ewaste we generate. It may not be the easiest to secure, but it isn't impossible.
The license stuff is what people focus on, but to me that is much more interesting. C is a pretty decrepit language and while I don't care much for the "rewrite it in rust" cult, the coreutils are exactly the type of program rust excels at - a non-iterative target that doesn't change often and can be made with "best practices" in mind.
Not having to deal with the utterly inane amount of dead architectures that GNU projects inherit probably helps them too on that end.
Given how mature and well defined the GNU Coreutils are, how small their scope is, how they are used, I really don't see the supposed security upside here.
There simply has to be a better reason to me, than "Rust good".
Specifically, integer overflow is much easier to correctly handle in rust, making bugs like CVE-2015-4042 less likely, and correct handling of multibyte strings is basically enforced by the standard library, making issues like CVE-2015-4041 very unlikely in a rust implementation
1: https://www.cvedetails.com/vulnerability-list/vendor_id-72/p...
I can search uutils/coreutils for "overflow" and get way more hits, I don't see how this is a rational thing to be afraid of within GNU Coreutils considering it's a collection of tools, that have been developed and maintained for decades and used by millions over that time period.
https://github.com/uutils/coreutils/issues/1420 https://github.com/uutils/coreutils/issues/886 https://github.com/uutils/coreutils/issues/5149
To be clear, I don't see any problems personally with any of these issues, they don't seem very exploitable to me.
However, I think that relying on Rust to be the bastion of safety merely because the name "Rust" is mentioned is nothing but a fallacy.
To me, logic bugs are the far more egregious category in something like coreutils. Me making the assumption, that something works the way it's documented, but doesn't can lead to horrible things down the road. Much more so, than any integer overflow crash could ever dream to.
Arguably it's the "pay attention" part that causes the bug in the first place, so I don't think the performance-oriented default was a good pick.
The issue is mitigated a bit by the remaining runtime array bounds checks, but I must wonder if those checks could be removed by the optimizer when it believes e.g. a variable can never be below a certain value.
I haven't tried that style in Rust—or in C++ for that matter—but is it truly much nicer than the options available for C++? Perhaps out-of-the-box experience is the winner there.
Yes, but Bash (or any other shell) isn't part of coreutils.
https://en.wikipedia.org/wiki/List_of_GNU_Core_Utilities_com...
The fact it's released under MIT instead of Apache (or GPL) does worry me though.
It adds nothing but confusion to the conversation.
The reason why it would be useful to sublicense it as GPL would be to intermix it with changes that are GPL. The combined work would be covered by the terms of the GPL, and the original work would remain covered by the MIT license.
What makes you think this? The point of licenses like GPL (copyleft licenses) is to prevent sublicensing.
GPL sets very specific rules and you need to follow them. You can’t just ignore them and change the code’s license.
MIT isn’t copyleft in that sense (as you don’t _have_ to release changes you make to MIT code) but any code released based on MIT code must also include the MIT license.
You can’t just change the license all willy nilly, that would defeat the purpose.
The body of the license, particularly in contrast to the copyright granted automatically, and other copyright licenses. The MIT and BSD licenses are not very long and quite easy to digest. I recommend giving them a read.
> The point of licenses like GPL (copyleft licenses) is to prevent sublicensing.
The juxtaposition with the previous question makes me think you may have missed that your question was in reply to permissive licenses, or maybe you think that the GPL is a permissive license? Either way: I agree. The GPL does prevent (further) sublicensing.
> [...] but any code released based on MIT code must also include the MIT license.
Yes. That's why I said:
> That effectively nullifies the value of slapping the GPL on it, but you can do it.
In my previous comment. Because when you simply slap the GPL on some MIT code and release it like that, people can choose to use the MIT licensed code with the MIT license instead. Effectively nullifying the value of the GPL.
> You can’t just change the license all willy nilly, that would defeat the purpose.
Never meant to suggest you could.
That tells me that "some options and behaviours are still different" is also being treated like a bug.
Even if this is only used by huge companies like Meta or for new projects, it will still justify its existence..
I’m sure there are a thousand similar but different enterprise environments like this. At home / solo dev it makes no sense, you’d just install ubuntu / get a macbook and get working without any fuss.
Docker works but it makes test runs 100x slower (yes, I measured, it’s not made up).
I even do some directx dev with it.
All with very portable code that can even be built in the standard github action ubuntu.
For example, I've had problems on docker for Mac where accessing lots of (python) files in a volume mount was slow. I had to use some beta setting at the time which was far better (though I had to do a OS upgrade to use it, which also entailed some IT nonsense).
The overheads of docker are there but if it was that bad people wouldn't use it.
Docker is still useful, it’s great for sharing a complicated setup across machines.
Their compiles take 2m, mine take 30s.
I might be missing something, but isn't Docker on Windows or MacOS actually a VM running Linux (or, on Windows, perhaps it uses WSL2, which is also a VM running Linux)? How could you use Docker if VMs are banned?
Similar situation for MacOS docker containers on a MacOS host (see recently discussed https://news.ycombinator.com/item?id=37655477)
But for running Linux containers on MacOS or Windows I think you are right
I'm no Windows fan but WSL has worked extremely well on several different machines I've worked on since 2015 and Cygwin was no WSL but I could get a lot done with it back in the day as well.
> Docker works but it makes test runs 100x slower (yes, I measured, it’s not made up).
Yeah, I don't know what you're doing that it could be 100 times slower, something else is wrong.
Cygwin has been very useful to me, but also caused its share of issues with its permissions model, creating large directory trees that couldn’t be deleted.
I'm sure there's desire out there for a pure-Rust close-to-POSIX userspace you can put on top of Linux, but I don't exactly see a whole lot of progress toward that. At minimum, you'd need coreutils, findutils, diffutils, tar, grep, sed, compression libraries, crypto libraries comparable to OpenSSL or GnuTLS, an editor, a POSIX shell, an init system, a service manager, system-wide DNS and DHCP. Going beyond pure POSIX to a more practical server distro would probably include a PGP implementation, a package manager, sudo or equivalent, ssh, iproute2, probably many other things I'm forgetting.
uutils seems to give you findutils and coreutils. ripgrep is not a drop-in replacement for grep. I'm sure there are other "rewrite it in Rust" projects out there I don't know about, but low-level system utilities aren't exactly the gloryland most developers are interested in rewriting and POSIX includes a lot of stuff.
Frankly, I don't think this is a realistic terrain for any single organization. GNU itself took over a decade to get a practical distro and that was only because other developers provided a kernel, package managers, boot loaders, crypto, and what not. And the GNU project is not really a single organization. It encompasses many people from many different employers. Systems software in general wasn't as fragmented. If you were working in the space at all and cared about being cross-platform and collaborating across organizations in the 70s and 80s, you were using C. Everything else was proprietary. If we're ever going to get something comparable but in Rust, it's not going to be from a single Github org like this.
If I remember correctly, Mac has any GNU utility from before they all switched to GPL v3. Which was decades ago now.
But also, things like BusyBox and ToyBox are very popular alternatives which contain non-standard ports of only a subset of coreutils. A complete and mostly compatible set of coreutils would be more popular than either, but they also have some different constraints that Rust builds make difficult (eg: binary size).
* nb4 "it's just configure/make/install what do you mean" consider if you want coreutils without glibc, cross compiled, or want to bootstrap your environment without any of them. The GNU ecosystem is "easy" to build/use within the GNU ecosystem, which is not unopinionated about what that looks like and how it works.
You can find the GNU coreutils for Windows on sourceforge but it always feels like spyware when I download something from that site, plus I don't know how old they are or if they are actively maintained.
With this rewrite, I like that I can download them from the repo's releases page. There is an issues page for problems and I can see the project is actively worked on.
Installing them as binaries is simple and, this goes for all Rust/Go projects, I actually know how to compile them (sorry, I know C/C++ is great but between gcc||msvc||clang, missing deps, ./configure ./install and make - I rarely have a pleasant experience compiling something in C/C++).
To clarify, I'm not intending this as a negative comment. It's an impressive project, and aiming for cross-platform sharing of scripts seems a worthy goal. The graph of progress against the GNU test suite is neat and encouraging. However, I can't imagine anyone in Unixy lands moving to this - although I may be wrong there - so it feels like a "compatibility" project for MacOS and Windows. I'm not familiar with the situation on MacOS but how bad is the compatibility issue? Similarly, on Windows what's the situation with WSL or VMs or even Cygwin? Is performance the issue?
Do people actually want this, is there a market for it? It's got 17.8k stars so seemingly so? Again, I'm not intending to cast aspersions, just trying to understand the audience. This is clearly different from a "for the fun of it" side project.