Rewriting the GNU Coreutils in Rust

Posted Jun 10, 2021 19:57 UTC (Thu) by Hobart (subscriber, #59974)
In reply to: Rewriting the GNU Coreutils in Rust by khim
Parent article: Rewriting the GNU Coreutils in Rust

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.