The reason GCC is not a library (2000)
gcc.gnu.org
gcc.gnu.org
Five years later the main llvm developer proposed [0] to integrate it into gcc.
Unfortunately, this critical message was missed by a mail mishap on Stallman's part; and he publicly regretted both his errors (missing the message and not accepting the offer), ten years later [1].
The drama was discussed in realtime here in HN [2].
[0] https://gcc.gnu.org/legacy-ml/gcc/2005-11/msg00888.html
[1] https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00...
https://bugzilla.mozilla.org/show_bug.cgi?id=35839#:~:text=C...
Chat has a way of getting completely lost. All your knowledge that goes into chat either goes into somebody’s head or it just disappears into the ether. This includes Slack, Discord, Teams, etc. Useful as a secondary channel but serious projects need something more permanent.
Bug tracking systems just don’t support the kind of conversations you want to have about things. They’re focused on bugs and features. Searchability is excellent, but there are a lot of conversations which just end up not happening at all. Things like questions.
That brings us back to mailing lists. IMO… the way you fix it is by having redundancies on both sides of the list. People sending messages to the mailing list should send followup messages. You should also have multiple people reading the list, so if one person misses a message, maybe another gets it.
Mailing lists are not perfect, just better than the alternatives, for serious projects.
(I also think forums are good.)
it does include threads, and no need for admins
Their biggest problem is that nobody uses them, though.
And since then... nothing. No more improvements. Development seems to have more or less halted since the Salesforce acquisition.
I used irc for a couple of decades before Slack, so was happy with purely linear chat (yeah, I'm also one of those weirdos who likes rebasing in git). Threads make everything more horrible, but at this point it feels like I just have to put up with it.
I like both rebasing and threads. More generally, I hate hate hate the 20+ individual messages on a single topic in a channel. It's just so annoying, threads are great for stuff like that, and give you one target for a reminder/update on whatever the issue is.
And yet, every time I change companies I realise again how much most people just don't threads on Slack.
alternatives:
discord has inline quoting and threads. treads are a bit more visible.
zulip creates a new thread for every message because it prompts you to set a topic, and then you browse the messages by topic.
To be fair, this is hyperbolic. To clarify, small groups within most orgs tend not to use threads in their internal channels AND congratulate everyone on their birthdays. The combination of this irritates me due to repeated notification spam.
One of the reasons I enjoy HackerNews is dang's enlightened and sensible moderation policy.
The static pages are there for browsing. They load fast, and I like the entire thread being on one page. No clickety-clicking and forgetting where you are in a forest of postings.
they are both messages in threads. what's different is the presentation.
some of the forums i use support both seamlessly, and i can choose which interface i prefer.
of course for the issue we are discussing, presentation is what matters. but, for most forums i do not believe they would have made it any easier to not miss a message. just look at hackernews. it is actually quite difficult to track which messages i have not read yet, (even if there is a marker on what's new) and it is therefore very easy to miss some.
that is not the case with email. because my mail client tracks the rad/unread status for each message. the problem with RMS has nothing to do with the form of a mailing list but with his particular async style of accessing the internet.
They can be treated like mailing lists, but are easy to navigate , easy to search and index, and easy to categorize.
[1] https://www.freelists.org/
With phone calls? Not that I suggest using calls as a way to manage your project, but at least you typically know that the recepient is there and listening before you transmit.
Serious question, since in my experience even specifically assigning someone a Jira tix doesn't guarantee they'll actually look at it and act.
The fact that RMS missed an email and nobody else did anything about it either is a sign of an absolutely dysfunctional relationship between the project and its leadership.
LLVM could have been integrated under the GNU/FSF umbrella as a separate project of course.
[1] since the egcs debacle was resolved, RMS has had very little control of GCC
You can't infer anything from this episode about the suitability or unsuitability of email for any particular purpose.
This caught my eye as well.
I'm not sure what his objection to accessing email in a normal-ish way might be. Any ideas?
My best guess is that it's something surveillance-related, but really not sure.
> I generally do not connect to web sites from my own machine, aside from a few sites I have some special relationship with. I usually fetch web pages from other sites by sending mail to a program (see https://git.savannah.gnu.org/git/womb/hacks.git) that fetches them, much like wget, and then mails them back to me. Then I look at them using a web browser, unless it is easy to see the text in the HTML page directly.
(he describes his arrangements in detail here: https://www.stallman.org/stallman-computing.html)
20 years ago someone missed an important email.
Every 20 seconds someone misses an important message in a thread hidden deep in a chat.
I don't understand how we have moved from email and IRC to the various chats. The latter seem to actively hide communication, as some deliberate sabotage.
I know that in the old days IRC chats were sometimes “made public” in the sense that a bot would scrape the entire chat and put it on the web. If that's what you're after, there's no technical reason I can think of you can't also do that with Discord except that it's not as trivial to implement because it's not just text and not just a single linear chatroom.
The discussion here is about archivability and searchability and I'm really not sure an IRC log fits that bill any more than a hypothetical Discord log.
I don't have a tonne of experience with all the chat offerings, just lots with one of the big ones, but to me the main flaw the new ones seem to have is that they have these "threads". Maybe I'm old and senile ("skill issue"), but if you reply to a message of mine into a thread, there's a 99% chance I'll never see it.
Maybe this is a UI issue, not a skill issue.
I have asked other people how they manage to follow updates in threads in order to see updates, and the answer seems to be that they don't. They just accept that many messages are just never seen by anybody. So it's not just me.
IRC doesn't have this. Starting a new channel, while extremely low effort, is not as integrated in the message flow. So people don't, the way they spawn threads left and right in new chats.
A second reason, in my experience (which may be atypical), is that IRC is seen as obviously not a replacement for a design or an email. But because new chats have more of an illusion of being authoritative rather than ephemeral, more people go "oh the rationale for that is in the discord/slack somewhere", whereas nobody with shame would ever say that about IRC.
> archivability and searchability and I'm really not sure an IRC log fits that bill any more than a hypothetical Discord log.
Yes, the Discord log is much better. But that's one of my points. It's better, so people choose it over something more suitable. So it's not "worse is better", but "better makes worse".
How do you do it in IRC?
The only way you can guarantee that you see all messages is if you read all messages. You can do that on Discord (it keeps track of read/unread messages) or on IRC. Obviously this is unreasonable if the Discord server/IRC channel is high-traffic. I really don't see how the two are any different in this regard.
I do take your point about the rest. You're saying that the differing capabilities cause people to use it differently and that is a point I hadn't considered. If IRC doesn't offer threads or pinned messages then you have to put documents outside of it and that might make it easier to find/index etc.
The question was how to see that threads are getting messages, and following them. IRC doesn't have threads, so doesn't have this problem.
On a higher level, how do I follow different conversations happening on IRC at the same time? I wouldn't say it's ever been a problem, in the decades that I've used IRC.
Hell, I use some IRC bridges that just flatten all the threads into one timeline, and that works much better too. Yes, in theory someone could just reply "yes" 10h after the previous message on a thread, and you have no way of knowing "yes to what"? But in practice that basically never happens.
Now, if the sender of that message had been on IRC, they would have instead said "yes I'll come to the dinner". Which would have been REALLY helpful on Chat too, because people may get popup notifications (phone or desktop) that just say "yes", and now they have to find (much harder than it should be) and open the thread to even know what the question/topic was.
And yes, people will probably also adjust their timelines a bit. Like if there's a major outage, maybe in modern Chat people start a thread to discuss a weekend trip (though do they? I'd expect them to start a completely separate group chat), whereas on IRC maybe they would go "you know what, this discussion can wait until after the outage". But people do that with modern Chat too. It's not just that the Chat is busy, the people are busy too, so you wait.
Still, there's no problem having a couple of conversations.
If you feel like I'm not answering your question it's probably because you seem to be saying "how do you solve this problem in IRC?", and I honestly don't understand what the problem is.
I have a WAY harder problem keeping up with newer chat. Right now on my work social chat my full desktop monitor has enough vertical space to show a whole 5 messages. My IRC on the side on a smaller monitor is showing 28 messages at once.
Now, because the Chat is Google Chat, those 5 are all I'll ever see, because if I try scrolling up, the page starts dynamically populating messages, causing a bunch of scrolling, flipping pages up and/or down losing my place, so I just give up and chase the ephemeral "Jump to bottom" button before it decides to disappear.
I'm pretty sure Google Chat is the worst of all options in terms of UX, so I'm not saying Slack is as bad.
> You can do that on Discord (it keeps track of read/unread messages)
In my experience the number of threads people create will greatly exceed the ability of even a "supertasker" to keep click-click-clicking to follow. Basically if this isn't the thread you have open, you're not on it.
> Obviously this is unreasonable if the Discord server/IRC channel is high-traffic.
If an IRC channel is too high traffic, it tends to topic split into another channel. And IRC clients can certainly keep track of what you last saw.
> pinned messages
Channel topic serves that purpose, I think. Or maybe not for the way you use pinned messages?
I think the only functionality I'm missing in IRC is the ability to attach images and receive them inline if needed. Gotta have the memes. And some clients (e.g. irccloud) do support that.
Did he convince other GCC devs with that post? Mentor younger devs on free software strategy?
What's happened in the ten years since?
C'mon GCC mailing list lurkers-- spill the tea! :)
1: https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00...
Doesn't mean he would have accepted it he had seen the message.
It will take a very long time (30 years maybe?) - I did say slowly - but the direction of travel is pretty clear.
Did Dave Malcolm contact RMS privately as he said then? I only know about https://gcc.gnu.org/legacy-ml/gcc-patches/2013-10/msg00228.h...
Why did RMS back down then? He still opposes a ffi for emacs, even if behind the scenes there is now a ffi in emacs for gtk.
But emacs is big enough. Cannot get much bigger
Ultimately Stallman was against a kind of digital feudalism, where whoever developed software had power over those that didn't
To which none can answer how it creates freedom without mass adoption to actually get the software into end users' hands. The great contradiction in FSF philosophy is to create highly pure software within a monastery of programmer-users while simultaneously insisting to focus on end-user freedoms without reconciling programmer incentives to build what these end users need.
So there doesn't need to be an answer. He can just show it to you.
It is Free Software whether it is BSD or GPL3. By all measures, Free Software as originally envisaged has been a massive success. It's just the goalposts have expanded over the years.
You clearly did not read the FSF manifestos and don't understand their positions. They will call the BSD license "permissive" and will correct you if you attempt to call BSD "free/libre".
> Why would it matter
The FSF didn't build "open source." They actively work to discredit open source. Let's not give them credit for what they tirelessly denounce.
Linux is open source, but did not adopt the GPL3. Firefox is open source but uses MPL. If the FSF is a leader who is responsible for all of these great projects, why doesn't anyone want to use their license?
Wrong. https://www.gnu.org/philosophy/categories.en.html
> The FSF didn't build "open source." They actively work to discredit open source. Let's not give them credit for what they tirelessly denounce.
Where did I ever use that term in this conversation?
You didn't because you glossed over my central point. Open source's success in the last twenty years came in spite of the FSF, not because of it.
If reality disproves your theory, it's not reality that's wrong.
What is your criteria for judgement here? The FSF GPL licenses, in reality have worked quite well, if the criteria is longevity, high usage, popularity, utility and maintained.
If your only criteria is "Well, they're only #2", then sure, by that criteria they did not "work".
What are you talking about? GCC usage is well ahead of LLVM usage.
And even if it wasn't ahead, it's still the default compiler for almost every production micro controller in use.
GCC is the default on most deployed systems today.
LLVM: 5k GCC: 1k
This is not what sustainability looks like:
https://trends.google.com/trends/explore?date=today%205-y&q=...
The crossover will more likely be driven by silicon trends providing an opportunity for LLVM's velocity to translate to enough competitive advantage for casual users to want LLVM. Once that happens, you will see some Linux distributions switch over. Hard liners will fork and do what they do, but asking people to use a compiler that gives them a worse result or is harder to work with isn't going to hold the gates.
Linus prefers LLVM for development.
People need to get out of the 90s and look at some data.
I can't see the future, but I can tell you without a doubt that, as things stand right now, the GPL has been a runaway success for users' rights.
Will that change in the future? Who knows? But that wasn't your claim nor my counterclaim.
As RMS indicated, this strategy had already resulted in the development of C++ front ends for the Free software ecosystem, that would otherwise likely not have come about.
At that time the boom in MIT/BSD-licensed open source software predominantly driving Web apps and SaaS in languages like Rust and Javascript was still far away. GCC therefore had very high leverage if you didn't want to be beholden to the Microsoft ecosystem (it's no accident Apple still ships compat drivers for gcc even today) and still ship something with high performance, so why give up that leverage towards your strategic goal for no reason?
The Linux developers were more forward-leaning on allowing plugins despite the license risks but even with a great deal of effort they kept running into issues with proprietary software 'abusing' the module APIs and causing them to respond with additional restrictions piled atop that API. So it's not as if it were a completely unreasonable fear on RMS's part.
(Not knocking them, i think sometimes being obnoxiously stubborn is the only way to change the world)
However, I quite value their stand. It's principled and they are, more or less, sincere about it. Many of their concerns about "open source" (as contrasted to free software) being locked up inside proprietary software etc. have come true.
The statement in question was issued during a period in which software vendors routinely demanded several hundred — and in some cases, thousands — of dollars[0] for access to a mere compiler. More often than not, the product thus acquired was of appalling quality — a shambolic assembly marred by defects, instability, and a conspicuous lack of professional rigour.
If one examines the design of GNU autoconf, particularly the myriad of checks it performs beyond those mandated by operating system idiosyncrasies, one observes a telling pattern — it does not merely assess environmental compatibility; it actively contends with compiler-specific bugs. This is not a testament to ingenuity, but rather an indictment of the abysmal standards that once prevailed amongst so-called commercial tool vendors.
In our present epoch, the notion that development tools should be both gratis and open source has become an expectation so deeply ingrained as to pass without remark. The viability and success of any emergent hardware platform now rests heavily — if not entirely — upon the availability of a free and competent development toolchain. In the absence of such, it shall not merely struggle — it shall perish, forgotten before it ever drew breath. Whilst a sparse handful of minor commercial entities yet peddle proprietary development environments, their strategy has adapted — they proffer these tools as components of a broader, ostensibly cohesive suite: an embedded operating system here, a bundled compiler there.
And yet — if you listen carefully — one still hears the unmistakable sounds of malcontent: curses uttered under breath and shouted aloud by those condemned to use these so-called «integrated» toolchains, frustrated by their inability to support contemporary language features, by their paltry libraries, or by some other failure born of commercial indifference.
GNU, by contrast, is not merely a project — it is a declaration of philosophy. One need not accept its ideological underpinnings to acknowledge its practical contributions. It is precisely due to this dichotomy that alternatives such as LLVM have emerged — and thrived.
[0] Throw in another several hundreds for a debugger, another several hundreds for a profiler and pray that they are even compatible with each other.
That's the context here. If you build a new compiler based on GCC, GPL applies to you. If you build a new compiler based on LLVM it doesn't.
but such a compiler or IDE would not GPLv3 infect it's users' target sources and binaries.
If the requirement was still just to implement a "simple" C89 compliant compiler, and I was worried about software freedom. The GPL is probably still a good bet.
This gave LLM a leg up too.
I don't think this is a valid assumption. If the root cause was a refusal to adopt GPL software, I think it's rather obvious that in a universe where LLVM doesn't exist, companies such as Apple will still diverte their resources to non-LLVM software.
Apple is also not resource-constrained or a stranger to develop compilers and their programming languages. Does anyone believe that GCC is the only conceivable way of developing a compiler?
There's a lot of specious reasoning involved in this idea that LLVM is the sole reason some companies don't adopt GCC. The truth of the matter is that licenses do matter, and if a license is compatible with their goals then companies can and will contribute (LLVM) whereas if it isn't (GCC) companies will avoid even looking at it.
A lot of this is driven by FAANG or FAANG wannabes, companies at a scale where they can basically reproduce huge chunk of OSS infrastructure.
They also put out a lot of Open Source with they don't want to license as GPL due to a general fear of GPL contamination.
Most of this is huge corporation driven.
It's always an option if you're willing to put up with the awkwardness and inefficiency. GPL has more in common with DRM than you would think.
By Stallman's own telling a free Objective-C frontend was an unexpected outcome. Until it came up in practice he thought a proprietary compiler frontend would be legal (https://gitlab.com/gnu-clisp/clisp/blob/dd313099db351c90431c...). So his stance in this email is a reaction to specific incidents, not careful forethought.
And the harms of permissive licensing for compiler frontends seem pretty underwhelming. After Apple moved to LLVM it largely kept releasing free compiler frontends. (But maybe I'd think differently if I e.g. understood GNAT's licensing better.)
This real apocalypse did happen upon making gcc a c++ project. This is probably one of the biggest mistakes in open software ever.
There were rumors which do match the timing: the media labs (and gcc steering "committee") at MIT being fiddled auround by B. Gates via Epstein (yes, the one you are thinking about). Are those rumors true? Well, there is "something", but "actually what"? All we know is RMS had to "disappear" for a little while... and that was not for health issues and probably to avoid being splash by the MIT 'media labs' affair.
Open source is not enough anymore, we (all of us) need _lean_ open source, which excludes de facto ultra-complex syntax computer languages (c++ and similar), that to foster real-life alternatives in the SDK space.
gcc is now not much better that closed source software.
I agree that moving to C++ was a mistake, and I agree that for software to be truly free it has to be lean, so that users can meaningfully contribute. Apocalypse is certainly exaggerated, as GCC is still something that is fairly accessible to newcomers. But it certainly reflects the general and unfortunate trend of making things too complex.
And it seems we are more and more to understand how critical _lean_ is for open source software (and file formats/network protocols), _including the SDK namely the computer languages_. Real-life alternatives or deep customizations are way harder to build without _lean_ software.
A good example: web "app" and web "site". web "app" is javascript requiring one of the massive whatng cartel web engines. web "site" is classic or noscript/basic (x)html (aka basic 2D/table based HTML forms only, with a clean CSS/presentation split).
Also, I should be able to bootstrap, and that reasonably, a full elf/linux based OS with a simple C compiler (assembler+linker), for instance cproc/scc/tinycc/etc. gcc being now c++ broke everything, and I cannot believe the MIT media lab/"gcc steering commitee" did not know that, and the rumors of B.Gates interfering at "MIT medialab" via Epstein funding would explain open source quality obvious sabotage decision making.
All that said, I think it is game over, and we should move toward RISC-V assembly written programs sided with high-level languages (python/ruby/shell/javascript only engine/etc) with RISC-V assembly written interpreters, with a very conservative usage of macro preprocessing (because some preprocessors may reach c++ and similar complexity and that would not be much better than the current state). I am currently coding basic rv64 assembly (no pseudo-instructions, only core ISA, using a basic C preprocessor). I have a littele rv64 interpreter to run them on x86_64... well, until the programs stay simple enough.
In any case, there is still a path open for bootstrapping via TCC / GCC 4.8 ...
C++ - in general - is just the mistake of the overall trend in the industry to add overly complex nonsense.
Although ideally both should have been replaced by now.
https://godbolt.org/z/6PY1ve8ev
Or to use one of the beloved compiler extensions,
https://godbolt.org/z/6KKjcM7bP
Additionally these extensions are now part of C++ as soon C++26 gets ratified, given that P3471R4 has been accepted.
Whereas in C that isn't even an option.
However the big difference is that WG21, at least is making something about it.
On C land, radio silence and worse, clever ideas like VLAs on the stack, naturally also without bounds checking.
WG14 is also working on such topics, so this is more your ignorance speaking. But complaining on the internet about the work of volunteers is rather bad style anyway, IMHO.
I am not sure what VLA on the stack have to do with it, but VLAs certainly enable bounds checking when used. The more important thing is the type system part.
LLVM is the only open source project that rivals with the Linux kernel in the amount of contributions.