Rewriting the GNU Coreutils in Rust [LWN.net]

Rewriting the GNU Coreutils in Rust

Posted Jun 10, 2021 9:39 UTC (Thu) by khim (subscriber, #9252)
In reply to: Rewriting the GNU Coreutils in Rust by pizza
Parent article: Rewriting the GNU Coreutils in Rust

> The "industry" always hated copyleft, and I think what we are seeing today would have happened even if the GPLv3 had never come to be.

I'm not so sure. Industry always hated copyleft, true, but not enough to actually dedicate substantial resources to it's eradication. Apple have chosen to open up Objective C instead of asking some other company for the base C compiler (and there were many such companies back then). Everyone who was using Linux was using bunch of GNU software, too (that's, ironically, why term GNU/Linux haven't gotten traction and was considered superfluous for many years).

This all have changed when discussions about tivoization and, more importantly, talks about changes to GPL to prevent that have started.

Grudging agreement between “free software” movement and industry was broken and “war” have started. Maybe that war was inevitable, who knows? But even if it were, ultimately, inevitable, GPLv3 provoked it early and thus made “free software” position worse instead of making it better.

> A license can't protect users' freedoms if code authors choose to not use it. Which only tells you those authors don't actually prioritize "protecting users' freedoms"

True. But before GPLv3 lots of people (“open source” camp, people who don't try to eliminate proprietary software) who don't really care about user's freedom and only want tit-for-tat (as Linus likes to put it) have chosen GPL anyway. Which “free software” can then portray as their victory and, more importantly, can use to get some freedom for users.

Today… these people usually pick APL or MIT license because they expect that this would just attract more potential contributors that way and would make proprietary forks unsuccessful. This is somewhat risky ploy, but, after GPLv3 fiasco and industry rejection of it… more-or-less inevitable.

to post comments

Rewriting the GNU Coreutils in Rust

Posted Jun 10, 2021 10:46 UTC (Thu) by pizza (subscriber, #46) [Link] (21 responses)

> Grudging agreement between “free software” movement and industry was broken and “war” have started. Maybe that war was inevitable, who knows? But even if it were, ultimately, inevitable, GPLv3 provoked it early and thus made “free software” position worse instead of making it better.

I believe that GPL enforcement efforts poisoned the well far more than GPLv3 ever did. All companies ever cared about was money, and GPL enforcement changed "I get to use this for free" into "we have to actually pay attention to what we're using in our products", which required changes to how they did business.

Mind you, supply chain management is critically important (though "the industry persists in trying to bury their head in the sand and ignore this) and GPL compliance is downright cheap, especially when compared to most regulations that a typical company has to deal with. But it was the publicity around that (minimal) GPL enforcement that seeded the general industry rejection.

(And I say that as someone who is firmly in the "GPLv3 is better than v2" and "we need _more_ enforcement" camps)

> Today… these people usually pick APL or MIT license because they expect that this would just attract more potential contributors that way and would make proprietary forks unsuccessful.

Those that _contribute_ determine the direction software takes, and "the industry" massively out-contributes the "free software" crowd, so it's no surprise those contributions reflect the priorities (including the ethics) of "the industry"

> This is somewhat risky ploy, but, after GPLv3 fiasco and industry rejection of it… more-or-less inevitable.

Equally inevitable is the failure of that ploy, because it does nothing to prevent the a bigger fish from taking your software and completely proprietizing it (making it more attractive to users by out-contributing you) or wrapping/bundling it as a service and completely undercutting your ability to monitize your own software.

Rewriting the GNU Coreutils in Rust

Posted Jun 10, 2021 12:30 UTC (Thu) by khim (subscriber, #9252) [Link] (18 responses)

> Equally inevitable is the failure of that ploy, because it does nothing to prevent the a bigger fish from taking your software and completely proprietizing it (making it more attractive to users by out-contributing you) or wrapping/bundling it as a service and completely undercutting your ability to monitize your own software.

If it's as inevitable as you say then why there are so many projects which don't support that fate and so few popular GPLv3 projects?

Actually you answered that question.

> Those that _contribute_ determine the direction software takes, and "the industry" massively out-contributes the "free software" crowd, so it's no surprise those contributions reflect the priorities (including the ethics) of "the industry"

Indeed — that's why you can pick APL/MIT and face the problems you outlined above. Risky and uncertain choice, yes. Or you may pick GPLv3 and guarantee the failure.

IanKelling class for GPLv3+ fork of uutils. Basically do what you say industry does to APL/MIT-licensed projects. But have any such GPLv3 fork succeeded? Ever? I'm not saying it's impossible, I'm really genuinely curious.

Because for now it looks as if choice of GPLv3 doesn't doom the project, but certainly hurts and if any GPLv3 ever succeeds it's because it's not just better than alternatives but better enough to overcome GPLv3 stigma.

GPLv3 fork of any permissively-licensed project can show that it's not true and we can learn on it's example about how GPLv3-software can win. But to do that we need at least one example of such a project.

Rewriting the GNU Coreutils in Rust

Posted Jun 10, 2021 14:08 UTC (Thu) by pizza (subscriber, #46) [Link] (17 responses)

> IanKelling class for GPLv3+ fork of uutils. Basically do what you say industry does to APL/MIT-licensed projects. But have any such GPLv3 fork succeeded? Ever? I'm not saying it's impossible, I'm really genuinely curious.

The only way a "GPL fork" of a permissively-licensed project will be "successful" (in terms of mindshare, marketshare, whatever) is if the GPL-proponents out-contribute the others, producing something that is "better enough". Which is bloody unlikely when you're a handful of part-time volunteers up against teams that are funded by industry consortia.

BTW, you seem to define "success" as "the industry widely adopts it". I *do not care* what "the industry" wants (which is "everything, for nothing"). Instead, I care about (1) the software meeting my own personal needs, and (2) the other users of my software.

Rewriting the GNU Coreutils in Rust

Posted Jun 10, 2021 14:45 UTC (Thu) by khim (subscriber, #9252) [Link] (16 responses)

> Instead, I care about (1) the software meeting my own personal needs, and (2) the other users of my software.

Do you? How does GPL (any version) helps with either (1) or (2)?

I don't see how GPL can help either (1) or (2) if industry rejects your software.

If industry accepts that software than (and only than) license starts to matter.

> Which is bloody unlikely when you're a handful of part-time volunteers up against teams that are funded by industry consortia.

Then why the hell do you insist on putting yourself in that position?

Back in XX century FSF (and GNU project) worked with the industry. GNU tools were “unofficial standard” on many OSes (and FSF's FTP even carried binaries for popular OSes like Solaris) even if definitely mostly helps the ones who adopted free software because of convenience and not because of their belief in “free software”. Heck, back then, back in XX century Stallman wrote If you want to accomplish something in the world, idealism is not enough—you need to choose a method that works to achieve the goal. In other words, you need to be “pragmatic.”

And back then copyleft worked. The biggest achievements which Stallman lists in his essay are few cases where someone made a piece of software because copyleft forced them to do that.

After GPLv3 fiasco… that stopped happening. Instead of releasing things under GPLv3… people started releasing stuff under permissive licenses or, alternatively, stopped using GPLed programs as basis for development and don't release anything at all.

And instead of trying to be pragmatic and adjusting their stance “free software” camp doubled-down on their idealism and is now quickly driving themselves into irrelevance.

That's sad to observe, but… if these people want to fight… against the whole industry… well… that's their choice, in the end.

Rewriting the GNU Coreutils in Rust

Posted Jun 10, 2021 15:47 UTC (Thu) by pizza (subscriber, #46) [Link] (15 responses)

> I don't see how GPL can help either (1) or (2) if industry rejects your software.

"Industry" has failed me (and the users in my little niche) many times over. WTF would I give a damn what they want?

If I released my code under permissive terms, I'd be effectively paying them to screw me over again. That'll sure show them!

> And instead of trying to be pragmatic and adjusting their stance “free software” camp doubled-down on their idealism and is now quickly driving themselves into irrelevance.

There is no compromise with someone who doesn't believe you have the right to exist. Keep that in mind when you talk about compromising ideals.

Rewriting the GNU Coreutils in Rust

Posted Jun 10, 2021 16:33 UTC (Thu) by khim (subscriber, #9252) [Link] (14 responses)

> There is no compromise with someone who doesn't believe you have the right to exist. Keep that in mind when you talk about compromising ideals.

That lines highlights the issue with the GPLv3 and the reason why it shouldn't be used much better than anything else.

The truth is different: extinction is much worse than even the “compromise with someone who doesn't believe you have the right to exist”.

But in the end, as I have said, it's your choice: if “free software” camp want to become just an article in Wikipedia about yet another group which no longer exist… who am I to judge them?

> "Industry" has failed me (and the users in my little niche) many times over. WTF would I give a damn what they want?

Care to write an article which explains how “industry” have failed you, and, more importantly, how you are thriving now without them?

I'm sure people on LWN would appreciate it. As cautionary tale if not anything else.

Rewriting the GNU Coreutils in Rust

Posted Jun 10, 2021 17:18 UTC (Thu) by pizza (subscriber, #46) [Link] (12 responses)

> That lines highlights the issue with the GPLv3 and the reason why it shouldn't be used much better than anything else.

The entire purpose of the "tech industry" these days is to sell advertising (and/or access to "content") on locked-down appliances. "user empowerment" as embodied in the "Four Freedoms" is in direct conflict to this.

But your takeaway is that the GPLv3 is the problem, rather than the ones seeking to repress users? WTF?

> Care to write an article which explains how “industry” have failed you, and, more importantly, how you are thriving now without them?

Printers. I've said here in the past that I've been threatened with lawsuits by companies that were actively distributing (if not outright using) my code -- Code that I only wrote because they refused to support Linux users.

Meanwhile, the actual "need" that got me into this area to begin with was a brand-new printer with memory card slots that couldn't handle abitrary jpegs... and also violated the flow control portions of the USB printer class specification.

And yes, by any objective standard, I'm thriving. My personal printing needs are well met these days, and I've been able to leverage this work into a (very) modest consulting business that pays for more creative-outlet-type devices (most recent one was a laser engraver that runs GPLv3-licensed GRBL).

Rewriting the GNU Coreutils in Rust

Posted Jun 10, 2021 21:04 UTC (Thu) by khim (subscriber, #9252) [Link] (11 responses)

> The entire purpose of the "tech industry" these days is to sell advertising (and/or access to "content") on locked-down appliances. "user empowerment" as embodied in the "Four Freedoms" is in direct conflict to this.

… because that's the only thing that you can actually make and sell. It's not as if there are no attempts to create other types of devices — people are just not buying these.

> But your takeaway is that the GPLv3 is the problem, rather than the ones seeking to repress users? WTF?

GPLv3 is a problem because it's expressly designed to make sure code released under that license wouldn't reach actual users and would forever stay irrelevant.

Yes, it was brave attempt to change the industry rules… and it failed. Time to move on.

> And yes, by any objective standard, I'm thriving. My personal printing needs are well met these days, and I've been able to leverage this work into a (very) modest consulting business that pays for more creative-outlet-type devices (most recent one was a laser engraver that runs GPLv3-licensed GRBL).

Interesting. This means that while industry-at-large changed and now using GPLv3 for something like uutils just means that nobody would bother to even look on your creation… yet at the same time certain niche markets appeared where GPLv3 is not considered large enough liability to try such software.

This certainly is an interesting example and article may show how more such niches can be found (or made?). That would mean that “free software” may still be relevant to some people beyond core “die-hard believers”. And certain types of software may actually exist as genuine “free software” because of that.

I wasn't aware such niches remained. All the software I develop and use is either:

Used by billions of people — and then, of course, GPLv3 is just flat out unacceptable, or
is niche enough that you can't make a business out of it — and then GPLv3 is irrelevant since there are noone who would misappropriate it in the first place (since there are no money in it)

If you may show where “free software” can be actually useful then it would be 100 times more important than whining about the desire of uutils makers to create something that people would actually use.

Rewriting the GNU Coreutils in Rust

Posted Jun 11, 2021 0:39 UTC (Fri) by pizza (subscriber, #46) [Link] (10 responses)

> … because that's the only thing that you can actually make and sell. It's not as if there are no attempts to create other types of devices — people are just not buying these.

Of course there are other types of devices, and real people do buy them. There is a considerable middle ground between "tens of millions of units shipped in a quarter" and "nothing".

> GPLv3 is a problem because it's expressly designed to make sure code released under that license wouldn't reach actual users and would forever stay irrelevant.

[citation needed]

> If you may show where “free software” can be actually useful then it would be 100 times more important than whining about the desire of uutils makers to create something that people would actually use.

"free software" isn't inherently useful, except in an abstract educational sense. But "useful software" is made more so by being "free".

Rewriting the GNU Coreutils in Rust

Posted Jun 11, 2021 8:24 UTC (Fri) by marcH (subscriber, #57642) [Link]

> Of course there are other types of devices, and real people do buy them. There is a considerable middle ground between "tens of millions of units shipped in a quarter" and "nothing".

Yes and the resources to pay engineers and develop software are a direct function of that volume.

Rewriting the GNU Coreutils in Rust

Posted Jun 11, 2021 8:26 UTC (Fri) by marcH (subscriber, #57642) [Link] (8 responses)

> > GPLv3 is a problem because it's expressly designed to make sure code released under that license wouldn't reach actual users and would forever stay irrelevant.

> [citation needed]

Let's quote you then:

> The entire purpose of the "tech industry" these days is to sell advertising (and/or access to "content") on locked-down appliances.

Rewriting the GNU Coreutils in Rust

Posted Jun 11, 2021 10:37 UTC (Fri) by pizza (subscriber, #46) [Link] (7 responses)

Those aren't mutually exclusive, and in any case, my quote says nothing to support the assertion that GPLv3 was "Expressly designed to make sure code wouldn't reach actual users and would stay irrelevant" (I'd think such an absolute declaration as to the intents of the GPLv3 would be trivial to cite, as the whole drafting process was quite public)

And do I really have to point out that the software world is *much much much* bigger than the "tech industry"?

Rewriting the GNU Coreutils in Rust

Posted Jun 11, 2021 11:53 UTC (Fri) by khim (subscriber, #9252) [Link] (6 responses)

> I'd think such an absolute declaration as to the intents of the GPLv3 would be trivial to cite, as the whole drafting process was quite public

The whole thing was designed to fight tivoization. It wasn't the only reason to create GPLv3, but that was the main one. And the expected outcome was that hardware manufacturers would just make it possible to change the code on a device they sell.

But it was really quite naive to expect such an outcome in a world where the same hardware is sold to a different users at “differentiated prices”. Think Intel's CPUs or compare prices of TI-NSpire and TI-NSpire CAS (not only they have identical hardware, their sales rely on the inability of the buyer to tinker with their software… they are not doing all that good of a job ensuring that, actually, since they only need to claim that it's impossible to change the software, they don't need to make it actually impossible — but that stil absolutely precludes use of GPLv3 software).

FSF hoped to, basically, change the business models of many different industries, laws (that's very explicitly written there, look on section #3), the style in which governments operate — with very limited reward: the ability to use some software for free. No wonder the attempt backfired.

It was a gamble: we may change the rules under which the whole world operates or we would be kicked out of mainstream and relegated to tiny, insignificant niches. But GCC looked so entrenched, Linux was so popular… the die was cast. “Free software” lost.

> And do I really have to point out that the software world is *much much much* bigger than the "tech industry"?

Indeed. And since software replaces hardware more and more it becomes more and more important for the developers of hardware to stop unauthorized modifications. For market compliance and other reasons.

Indeed, that was pointed out to FSF many, many times during the GPLv3 drafting. And it was altered to accommodate some such uses (look for distinctions WRT to “User Product”, e.g. — it's there specifically to allow producers of industrial devices not intended to be used by “Joe Average” to be able to delived locked-down hardware to their customers who very expressly don't want the ability to change the code on a device with associated liability). But it was very obvious even back then that such cases would become more widespread, not less (heck, look on #3 “Protecting Users' Legal Rights From Anti-Circumvention Law” again).

In a world where problems in software may lead to, at most, some papers being incorrectly printed GPLv3 may have been acceptable (yet, ironically enough, it was also not needed in such a world). In a world where software drives literally everything… it's unusable and ensures that end-users would never see your software.

Relying on software to fix hardware bugs is the norm novadays and it's much, much, MUCH simpler to rely on the locked down, signed, firmware instead on some nebulous schemes which may detect and alter modification of core system library (like libstdc++) and save the hardware anyway.

It's certainly nice that some niche industries may still afford to use GPLv3 and I really would be glad to read your article about that (no sarcasm here) but GPLv3 was expressly designed to make sure software under said license wouldn't be acceptable for many, many, MANY industries and thus would never reach the end users.

Rewriting the GNU Coreutils in Rust

Posted Jun 11, 2021 12:15 UTC (Fri) by pizza (subscriber, #46) [Link] (1 responses)

> but GPLv3 was expressly designed to make sure software under said license wouldn't be acceptable for many, many, MANY industries and thus would never reach the end users.

This may have been the end result, but it is was not the "Expressly designed intent", as you yourself said in the very first sentence of your reply:

> The whole thing was designed to fight tivoization. It wasn't the only reason to create GPLv3, but that was the main one. And the expected outcome was that hardware manufacturers would just make it possible to change the code on a device they sell.

(though that should be "continue to make it possible" -- manufacturers have to do considerably more work to create a locked-down device than not)

Anyway. In my experience (based on discussions with the last two $dayjobs' legal staff) it's not the anti-DRM clauses that made the GPLv3 a pariah -- that was a minor nuisance, easily worked around via technical means. The patent language, however, was the RealProblem(tm).

Rewriting the GNU Coreutils in Rust

Posted Jun 11, 2021 12:36 UTC (Fri) by khim (subscriber, #9252) [Link]

> though that should be "continue to make it possible" -- manufacturers have to do considerably more work to create a locked-down device than not

Locked-down devices predate not just GPLv3, not just the whole GNU project. They go back to early days of the IT industry. IBM sold features which would be unlocked (by installation of some SMS cards) back in 1950th, TROS modules in 1960th and so on.

Yes, it was relatively easy to circumvent these limitations (compared to RSA signature in modern devices) but that's not something people invented just to make FSF angry at them.

GPLv3 needs entirely new scheme, though: the one where you can change part of your base system software but not the whole thing.

That is certainly harder to achieve than full lock down of the whole thing.

> Anyway. In my experience (based on discussions with the last two $dayjobs' legal staff) it's not the anti-DRM clauses that made the GPLv3 a pariah -- that was a minor nuisance, easily worked around via technical means. The patent language, however, was the RealProblem(tm).

How is that substantially different from Apache license? It also includes the patent grant. And is loved by the industry.

Rewriting the GNU Coreutils in Rust

Posted Jun 11, 2021 12:49 UTC (Fri) by pizza (subscriber, #46) [Link] (3 responses)

> It's certainly nice that some niche industries may still afford to use GPLv3 and I really would be glad to read your article about that (no sarcasm here) but GPLv3 was expressly designed to make sure software under said license wouldn't be acceptable for many, many, MANY industries and thus would never reach the end users.

For the "tech industry" as a whole, the "user" is not the "customer" -- as in, those _using_ the product/device/whatever are not the same parties who actually fork over money. In those scenarios (and other business models where hardware is sold at a loss and made up for on the back end), locked-down devices are economically advantageous.

For everything else, barring legal/regulatory anti-tamper requirements (which are actually quite rare), there simply isn't an economic incentive/advantage to lock the hardware down; indeed it doing so can actually place you at a competitive disadvantage (because it both raises your costs and _reduces_ end-user functionality/utility)

In my two decades of experience in this field, the general concept of copyleft as a whole is the problem -- businesses simply don't want to have to comply with source distribution requirements and the risk that their "secret sauce" is forced into the open due to viral GPL contamination. Nevermind that having the processes to maintain/track the "software supply chain" is a practical necessity (ie _not_ having it can be a massive liability even without copyleft/GPL)

Once they accept the practical realities of having some GPL software (ie providing corresponding source code and keeping their proprietary stuff, if any, properly segregated), GPLv2 vs GPLv3 vs MPL vs SCCL or whatever is largely irrelevant... unless you have patents you're trying to protect/enforce, and the GPLv3's explicit patent license can possibly render your business' entire patent portfolio effectively useless for anything other than purely defensive means. That scares the bejeebus out of the suits, so the edict comes down that GPLv3 is bad, along with the funding to avoid its use, even to the point of wholesale development of in-house replacements.

Rewriting the GNU Coreutils in Rust

Posted Jun 11, 2021 12:57 UTC (Fri) by khim (subscriber, #9252) [Link] (1 responses)

You still haven't explained what makes explicit patent grant in GPLv3 worse than no less explicit patent grant of APL. And APL is certainly warmly embraced by the industry.

Rewriting the GNU Coreutils in Rust

Posted Jun 11, 2021 14:17 UTC (Fri) by pizza (subscriber, #46) [Link]

While both licenses have explicit patent grants, they differ greatly in scope.

ASLv2's patent clauses kick in only for _contributions_ to the software (ie "by contributing, you're granting a license for all patents you have that relate to the software") , but GPLv3's patent clauses go considerably further, applying even if you merely redistribute unmodified 3rd party software covered by a patent you hold or have licensed.

Rewriting the GNU Coreutils in Rust

Posted Jun 11, 2021 15:42 UTC (Fri) by marcH (subscriber, #57642) [Link]

It's just one example but I worked on a project that forked the last GPLv2 version of GRUB for pure tivoization reasons. No one at $BIGCORP ever seemed to care about any GPLvX patent difference, it's all about the tivoization difference, in fact there are mandatory trainings about the latter and not about the former.

macOS has been stuck to the last GPLv2 version of bash for years, now switching to zsh. Same for other software on macOS.

Same timing all across the industry, what a coincidence!

Rewriting the GNU Coreutils in Rust

Posted Jun 28, 2021 14:09 UTC (Mon) by immibis (subscriber, #105511) [Link]

> > There is no compromise with someone who doesn't believe you have the right to exist. Keep that in mind when you talk about compromising ideals.

> That lines highlights the issue with the GPLv3 and the reason why it shouldn't be used much better than anything else.

Pardon? What about the GPLv3 doesn't give people the right to exist?

Rewriting the GNU Coreutils in Rust

Posted Jun 11, 2021 5:05 UTC (Fri) by NYKevin (subscriber, #129325) [Link] (1 responses)

The people who care about monetization were never using permissive licenses, are not now using GPLv3, and increasingly they're not even using AGPL. Instead, they're inventing their own proprietary fake-open-source licenses such as the SSPL or Commons Clause. As it turns out, "take somebody else's open source software and host it for a small fee" is an increasingly viable business model, and the Four Freedoms (particularly freedom 0) were specifically designed to allow people to do that sort of thing.

Rewriting the GNU Coreutils in Rust

Posted Jun 11, 2021 6:20 UTC (Fri) by joib (subscriber, #8541) [Link]

> The people who care about monetization were never using permissive licenses

Some are, typically those using an 'open core' business model.

> As it turns out, "take somebody else's open source software and host it for a small fee" is an increasingly viable business model, and the Four Freedoms (particularly freedom 0) were specifically designed to allow people to do that sort of thing.

Sure. Software where only the copyright holder is allowed to monetize it is quite clearly not free, as freedom from the tyranny of the copyright holder is one of the core ideas behind both free software and open source. That being said, if an oligopolistic megacorporation uses their superior economy of scale to crush anyone else, including the original creators, from hosting an open source app that's a problem too. I don't know what 'the solution' to this would look like, though it seems the lack of success of AGPL would suggest that increasingly stringent copyleft isn't it.

Rewriting the GNU Coreutils in Rust

Posted Jun 10, 2021 19:57 UTC (Thu) by Hobart (subscriber, #59974) [Link] (11 responses)

Re: Objective C and "openness" from the benevolent goodness of Apple:

https://web.archive.org/web/20160106033123/https://tech-i...
> At that time, I envisaged the legal ramifications like some others who have recently posted on this list, so I did not see a basis for saying they could not do this.
> But at the same time, I realized that it would not bode well for the GNU project if such a thing were permitted. So I responded, "I will have to check with our lawyer."
> It's a good thing I did, because when I checked, I found that there was a basis for objecting to this plan. Such .o files would have implied the presence of the GNU compiler, linked with them. They would be, in effect, a way of distributing a larger program which implicitly includes the GNU compiler; as such, it must follow the terms on the GNU compiler.
> I told NeXT this, and NeXT decided there was no alternative to making the Objective C front end free software. So now it is available to all of us as a part of GCC.

Characterizations elsewhere in this thread of people who want their time & code to be "share and share alike" peppered with canards about religion are inflammatory.

If Apple is benevolent and sharing of their source code, it would be nice of them to open the NetBSD-based Time Capsule code for to save customers who shelled out hundreds from owning bricks. Here's a Guardian story on that one. https://www.theguardian.com/news/datablog/2010/jul/14/app...

🎵Join us now and share the software🎶

Rewriting the GNU Coreutils in Rust

Posted Jun 10, 2021 20:02 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

You miss the fact that NeXT could have just contracted the compiler to one of the many proprietary C compiler writers. They have mostly died out now, but back in 90-s it was an easy option.

Yet they decided to just open the source and keep gcc, because it wasn't really a big deal for them.

Rewriting the GNU Coreutils in Rust

Posted Jun 13, 2021 22:13 UTC (Sun) by nix (subscriber, #2304) [Link] (1 responses)

This was not the 90s. This was the late 80s. There was very little in the way of an alternative base for a compiler around at the time.

Rewriting the GNU Coreutils in Rust

Posted Jun 13, 2021 22:29 UTC (Sun) by khim (subscriber, #9252) [Link]

At least half-dozen compilers existed back then: Aztec C, Lattice C, Megamax C, and others. Year 1983 article name Nine C Compilers for the IBM PC speaks for itself (and note that back then GCC had no support for x86 which means there were more compilers than these nine).

If Jobs really wanted to avoid publishing Objective C changes he could have easily done that. But apparently for him it wasn't a big deal. This changed with GPLv3: suddenly the deal was altered enough that it have become a big deal for Apple.

Rewriting the GNU Coreutils in Rust

Posted Jun 11, 2021 2:25 UTC (Fri) by ncm (guest, #165) [Link] (7 responses)

I am not sure Objective-C[++] is a relevant example here: does anybody code in that language anymore?

Probably more important is that Gcc utterly nuked the whole compiler industry, and probably even killed Ada as a viable industrial language (even though GNU Ada eventually came out). Linux similarly nuked the OS business, causing a massive collapse and consolidation.

When you look around for relevance of GNU-licensed and other Free software, look at companies that collapsed or never came into existence. Everything else is a rounding error. New GPLed software is a good way to eliminate an industry sector that might otherwise be dictating terms to you.

Rewriting the GNU Coreutils in Rust

Posted Jun 11, 2021 15:17 UTC (Fri) by joib (subscriber, #8541) [Link] (6 responses)

> I am not sure Objective-C[++] is a relevant example here: does anybody code in that language anymore?

To the extent the Apple ecosystem hasn't yet switched over to Swift, I believe it's still used there.

But apart from GNUStep which is quite niche, I don't think it has ever been much used in the FOSS world.

> Probably more important is that Gcc utterly nuked the whole compiler industry

Playing the devils advocate, AFAIU people used gcc mostly because it was free as in beer, and good enough (heck, in many cases better than the proprietary alternatives). Had it been available via a permissive license, the end result would have been the same. Sure, someone could try to build a proprietary compiler business on top of 'permissive gcc', but the same problem would remain: why would anyone go through the hassle of paying for it if gcc is good enough and free?

> Linux similarly nuked the OS business

Again, we don't have alternative universes to run experiments on, but one could argue that Linux success instead of, say, FreeBSD, was more due to lucky timing (the BSD's being caught up in lawsuits during the critical early years etc.), and a better more scalable development model.

(All this being said, I do think copyleft offers at least some protection against 'proprietarization' (not so much of for SaaS as we've seen in recent years), and I think it's a shame it's become so shunned in recent years.)

Rewriting the GNU Coreutils in Rust

Posted Jun 12, 2021 8:20 UTC (Sat) by ncm (guest, #165) [Link] (4 responses)

That the Unix Wars carried on with BSD in the background throughout relieves us of any need to speculate. We saw.

Had Gcc not been copyleft, we would have seen identically the same balkanization in compilers, with each ISA's owner fielding its own proprietary, binary-only Gcc variant.

What we got instead was that to field a new ISA without providing Gcc patches would be instant death. That x86 in the end wiped out all but ARM *anyway* is a whole other story, one that might yet get a new chapter on RISC-V. (I am ready for Risc-6 already, taking RISC-V and walking back its less fortunate choices.)

Rewriting the GNU Coreutils in Rust

Posted Jun 13, 2021 8:36 UTC (Sun) by joib (subscriber, #8541) [Link] (2 responses)

> That the Unix Wars carried on with BSD in the background throughout relieves us of any need to speculate. We saw.

It was a different world back then, and further doesn't prove that the superior development model of Linux rather than the license, or uncertainty due to the lawsuits, was the key factor.

> Had Gcc not been copyleft, we would have seen identically the same balkanization in compilers, with each ISA's owner fielding its own proprietary, binary-only Gcc variant.

> What we got instead was that to field a new ISA without providing Gcc patches would be instant death. That x86 in the end wiped out all but ARM *anyway* is a whole other story,

And today LLVM is roughly on par with GCC, and the feared for balkanization hasn't happened. There are some proprietary forks of LLVM, but largely nobody cares about those. Any architecture that wants to be taken seriously needs to have both GCC and LLVM support.

> (I am ready for Risc-6 already, taking RISC-V and walking back its less fortunate choices.)

As far as ISA's go, I think aarch64 is pretty nice. You just have to go convince ARM to 'open source' it. :)

Rewriting the GNU Coreutils in Rust

Posted Jun 13, 2021 13:13 UTC (Sun) by pizza (subscriber, #46) [Link]

> And today LLVM is roughly on par with GCC, and the feared for balkanization hasn't happened. There are some proprietary forks of LLVM, but largely nobody cares about those. Any architecture that wants to be taken seriously needs to have both GCC and LLVM support.

Nobody cares, except, of course, for those who have to actually _use_ those forks.

A few years ago I actually had five different LLVM-based compilers installed onto my $dayjob workstation. Only one had source provided, the rest were proprietary, and as such I was entirely dependent on the vendor to fix bugs and otherwise provide updates that the Distro-supplied one received on a routine basis.

Rewriting the GNU Coreutils in Rust

Posted Jun 13, 2021 16:25 UTC (Sun) by ncm (guest, #165) [Link]

What has happened since the ISA wars is that introducing a new ISA is, itself, instant death. So, the existing compiler compiles code for everything, and new chips run code it already produces.

Rewriting the GNU Coreutils in Rust

Posted Jun 13, 2021 22:24 UTC (Sun) by nix (subscriber, #2304) [Link]

> What we got instead was that to field a new ISA without providing Gcc patches would be instant death.

Well, also what we got was that ISA vendors tended to fob off the job of producing a compiler on a convenient consultancy that wouldn't compete with them, i.e., Cygnus. These days, well, RH ate Cygnus and IBM ate RH and I'm not sure (even if the toolchain division was still doing that sort of heavy embedded work) that embedded vendors would be as happy that IBM wouldn't compete with them as they were that Cygnus wouldn't.

Rewriting the GNU Coreutils in Rust

Posted Jun 21, 2023 6:19 UTC (Wed) by ceplm (subscriber, #41334) [Link]

> Again, we don't have alternative universes to run experiments on, but one could argue that Linux success instead of, say, FreeBSD, was more due to lucky timing […], and a better more scalable development model.

I was not thinking about FreeBSD, where it is quite certainly true, but more like a sad death of Plan 9. It seems to me that ESR is (again) wrong in claiming that

>> The long view of history may tell a different story, but in 2003 it looks like Plan 9 failed simply because it fell short of being a compelling enough improvement on Unix to displace its ancestor.

I think it is not enough acknowledged how much exactly licensing issues and the entry cost damaged Plan 9. With the advent of both FreeBSD and Linux, there was just no reason to bother with the proprietary OS at all. Engineering decisions could cause for Plan9 to be just small community somewhere in the corner in the style of FreeBSD, Haiku, or even Hurd, which could survive and carry on the system to be a good citizen of the 21st century (not of 1980s as it is now), but because of it has been opened only when it was completely dead (April 2002), it never happened, and we have now 10 (according to Wikipedia) forks none of them compelling enough to push other ones to merge.

There is no GPLv3 fiasco

Posted Jun 28, 2021 14:07 UTC (Mon) by immibis (subscriber, #105511) [Link] (2 responses)

Merely not using copyleft licenses is hardly "dedicating substantial resources to its eradication". Industry has never and will never use copyleft licenses except in rare cases where it's to their advantage. Nothing has changed except public opinion of the GPL, and that new opinion has no grounding in reality.

There is no "GPLv3 fiasco". What is this "GPLv3 fiasco" you speak of? I have never seen a "fiasco", only a smear campaign, from companies that would like to Tivoize, and from "useful idiots" who repeat and amplify the arguments of those companies.

Industry rejected GPLv3, yes. Industry also rejected GPLv2 until they realized they could Tivoize. Industry likes BSD/MIT because it lets them have what they want and give nothing in return. It's not smart to avoid GPLv3 just because "industry doesn't like it". Them not liking it is kinda the point.

There is no GPLv3 fiasco

Posted Jun 28, 2021 17:20 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

> There is no "GPLv3 fiasco". What is this "GPLv3 fiasco" you speak of?
The fact that there is hardly any successful widely used GPLv3 projects.

There is no GPLv3 fiasco

Posted Jun 28, 2021 18:34 UTC (Mon) by mpr22 (subscriber, #60784) [Link]

GPLv3, above all, feels like a classic case of revolutionary ardour colliding with reality – specifically, the reality that of all the copyleft software out there, the piece with the most day-to-day practical importance had a GPLv2-only licence grant, an enormous number of contributors, and no centralization of ownership.