The LLM part is bad news but it isn't the sign.
-
@lykso @froztbyte @mhoye i like idris a lot and i have mixed feelings on seL4 but it is definitely cool software
@hipsterelectron @froztbyte @mhoye Yeah, your work sounds awesome and I am only pursuing the route I am because it seems like a good fit for my relatively limited abilities. These are the pieces I can see and use, and things feel like they are on fire right now so I'm doing what's in front of me. seL4 is juuust beyond the already-available, and I can reach that. You're reaching farther than I am; one day maybe I'll be building atop your work, but laying that groundwork is beyond me.
-
@Lunaphied @mhoye @froztbyte @jyn gcc has a reasonably well-documented bootstrap path from C99. even if i'd like it to be shorter the project takes it seriously and discusses bootstrapping as a concern on the mailing list which i really appreciate. i'm looking to improve the story for emacs atm
@froztbyte @jyn @mhoye @hipsterelectron yeah I mean I think it's stupidly long but at least it's possible. But it should still be one step from an existing binary of the compiler to a new binary of the compiler imo
-
@hipsterelectron @froztbyte @mhoye Yeah, your work sounds awesome and I am only pursuing the route I am because it seems like a good fit for my relatively limited abilities. These are the pieces I can see and use, and things feel like they are on fire right now so I'm doing what's in front of me. seL4 is juuust beyond the already-available, and I can reach that. You're reaching farther than I am; one day maybe I'll be building atop your work, but laying that groundwork is beyond me.
@lykso that is remarkably kind of you
-
@froztbyte @jyn @mhoye @hipsterelectron yeah I mean I think it's stupidly long but at least it's possible. But it should still be one step from an existing binary of the compiler to a new binary of the compiler imo
@Lunaphied curious about this since that is generally my experience with gcc. personally my build system will be maintaining an entirely acyclic bootstrap path from C99 and i absolutely agree that should be a goal for every language
-
@mhoye @hipsterelectron @froztbyte recently I started trying to make a pure Rust Nixpkgs style bootstrap. Assuming you have a Rust compiler binary because that's a given we accept for C ++ (I think an older version of GCC was the only pure-C implementation that was reasonably modern? Less confident on that I thing there might be a C based EDG thing).
But guess what? That's nearly impossible even assuming you start with a binary! First you have to use Cranelift (still billed as experimental, doesn't ship unwinding by default because it possibly bloats binaries though I didn't encounter it) because otherwise you need C++ for LLVM. And even then you don't have an assembler which you need. So okay you write that because I don't think any currently exist.
And then I'm sure you hit some new issue but that's where I stopped for now.
Meanwhile somehow, incredibly, even with the rise of LLM produced projects redoing all kinds of things (I get it, it's a fun exercise) nobody has made a full C compiler in Rust yet. The closest is some Anthropic demonstrator that's been abandoned and isn't finished and a project @jyn started as far as I can tell.
So even if you get there and want to bootstrap from C to a whole compiler chain afterwards to get LLVM support for your Rust, too fucking bad.
I won't accept any issues people claim because you need a compiler binary I think it's arbitrary to allow the C++ compiler but not Rust, but holy shit if your language is going to be self hosting why on earth isn't that actually a full stack even on one platform?
@Lunaphied @mhoye @hipsterelectron @froztbyte i’m confused why a pure-rust bootstrap path matters in practice
-
And for Linux as a plausibly community-managed meaningfully open as in open project, that clock is definitely ticking.
The end of this road is some corporate-funded retirement home for understaffed and underfunded projects once enough of the current devs have aged out without anyone growing into those roles, with private forks at companies that relied on the kernel, also privately relieved there's no need or reason to deal with antediluvian developer processes or bother giving back anymore.
@mhoye As soon as Torvalds threw his LLM tantrum insisting that Linux doesn't do social justice, and that the community is just a side-effect (and not literally the only thing that distinguished Linux thirty years ago from Minix and other UNIX clones), I think that it was pretty clear that the goal was to make Linux as close to proprietary as they can within the confines of the GPL, with the big corporate funders as stewards.
And I started evaluating replacements that week, too...
-
@mhoye It's a phenomenon I'm seeing a lot in FOSS circles lately: LLMs amplify a benevolent dictators ability to handle things on their own, which feeds into their need for control. That can manifest as anything from unwillingness to share work, to outright messages of hostility to potential recruits.
@lrhodes @mhoye@cosocial.Some Examples?
-
@Lunaphied curious about this since that is generally my experience with gcc. personally my build system will be maintaining an entirely acyclic bootstrap path from C99 and i absolutely agree that should be a goal for every language
@hipsterelectron @Lunaphied
That's what I'm trying to do though I am adding shims to allow some C23 things to work even on a C99 compiler.
...
Is shims the right word? I've seen the term "polyfills" used for the web but never seen it used for C versions. -
@thomaswilburn @mhoye I don't think "Linux development is only for the wealthy" is true.
Also, why contributing to the Linux kernel can only be done if you have access to an LLM? I mean, we can still develop like we did 5 years ago.
Personally I wouldn't contribute to projects that promote the usage of LLMs, but I don't see those things related.
@glaskows @thomaswilburn @mhoye because 5 years ago you would be reading and contributing to code written and documented by humans. now you are working on code that is generated by AI and very likely to be unreadable, messy, the documentation could be wrong or incorrect because it was hallucinated, etc etc.
the presence of any ai generated code in a project adds additional mental overhead for any humans working on it.
people who want to code without using AI will give up. people who do want to use AI will remain. more AI generated code will slip in. this vicious cycle will bleed the project of all people who can/want to work on the project by hand untill all that remains is people who depend on an AI to tell them what to do
what i mean by this is no you cant keep coding like you did 5 years ago in a project that allows ai contributions because ai contributions are actively hostile to coding like 5 years ago
-
@hal_pomeranz @mhoye BSDs are a shame, honestly. Fragmentation in the Linux world is bad, but fragmentation in the BSD world is on another level.
@tragivictoria @hal_pomeranz @mhoye tbh given how many projects have devolved into slop I'm grateful for fragmentation more often than not lately, redundancy and diversity are good things for an ecosystem
-
@mhoye @gunchleoc that’s … not my experience of the Perl community. Yes, there was a certain delight in Perl Golf tournaments, but that went hand in hand with a test infected culture of programming even before Test Driven Development was a thing, and there was a strong culture of documentation as well.
In professional work with Perl I always strive for clarity and readability and so did most of the people I knew in the community.
@pdcawley @mhoye @gunchleoc By the time I stopped using Perl, I used Module::Build, English, perltidy, and perlcritic to endurd the code was documented and legible. 'use English' was used specifically to replace the special all-punctuation variables with their verbose equivalents.
I'm sure there were knobs that delighted in writing inscrutable chaos in Perl; can't say I knew anyone like that. Most of us were on call so shipping broken unintelligible code was a good way to get paged at 3am when your code crapped the bed.
I still haven't found a Python equivalent for Module::Build (I gave up and used cookiecutter to maintain my standard project template. Suboptimal but with fewer misfeatures than anything else I tried.)
-
@glaskows @thomaswilburn @mhoye because 5 years ago you would be reading and contributing to code written and documented by humans. now you are working on code that is generated by AI and very likely to be unreadable, messy, the documentation could be wrong or incorrect because it was hallucinated, etc etc.
the presence of any ai generated code in a project adds additional mental overhead for any humans working on it.
people who want to code without using AI will give up. people who do want to use AI will remain. more AI generated code will slip in. this vicious cycle will bleed the project of all people who can/want to work on the project by hand untill all that remains is people who depend on an AI to tell them what to do
what i mean by this is no you cant keep coding like you did 5 years ago in a project that allows ai contributions because ai contributions are actively hostile to coding like 5 years ago
@gabu @glaskows @thomaswilburn @mhoye I sincerely want to cry.
And display your toot everywhere. Can I quote it in the readme of my (still private) project, please?
-
RE: https://woof.tech/@techokami/117439226690379216
The LLM part is bad news but it isn't the sign. It's the talking about planning succession while simultaneously complaining that nobody new wants to learn, that's the sign.
Y'all the kernel is in deep, deep trouble. We saw what happened to Perl and the kernel is in deep trouble.
@mhoye Question is: who is willing to fork pre-LLM version of Linux and maintain that? That would be the most practical solution.
AFAIK most people who care walk away from Linux to less mature NetBSD or RedoxOS, which do have strict anti-AI policy. -
@glaskows @thomaswilburn @mhoye because 5 years ago you would be reading and contributing to code written and documented by humans. now you are working on code that is generated by AI and very likely to be unreadable, messy, the documentation could be wrong or incorrect because it was hallucinated, etc etc.
the presence of any ai generated code in a project adds additional mental overhead for any humans working on it.
people who want to code without using AI will give up. people who do want to use AI will remain. more AI generated code will slip in. this vicious cycle will bleed the project of all people who can/want to work on the project by hand untill all that remains is people who depend on an AI to tell them what to do
what i mean by this is no you cant keep coding like you did 5 years ago in a project that allows ai contributions because ai contributions are actively hostile to coding like 5 years ago
@gabu @glaskows @thomaswilburn @mhoye
5 years ago you would be reading and contributing to code written and documented by humans
Coincidentally, five years ago I actually was working on the Linux kernel and documented is a massive stretch. The code is almost totally bereft of comments. APIs return pointers and the only way to understand who is responsible for cleaning those things up or what the ownership discipline is, is to read other callers and then adopt the consensus view (it’s inconstant you’ll find a bunch of API misuse: if you just copy the first one you find there’s a good chance it will be wrong).
-
And for Linux as a plausibly community-managed meaningfully open as in open project, that clock is definitely ticking.
The end of this road is some corporate-funded retirement home for understaffed and underfunded projects once enough of the current devs have aged out without anyone growing into those roles, with private forks at companies that relied on the kernel, also privately relieved there's no need or reason to deal with antediluvian developer processes or bother giving back anymore.
AWS Linux
-
Anyway, funny story but remember when the discussion was about The Cathedral and The Bazaar?
There's a second axis to that graph, and it's ends are labelled "A Community" and "A Cult".
Just to pile onto this some more:
"Ojeda said that there is a need to deprioritize these contributors, but that we still need to find talented people to join our community. That means finding ways to focus on the people who actually matter."
One of and maybe the biggest challenge we had fostering contributors that I - he said patting himself on the back - recognized early when I started at Mozilla, was in coming to terms, structurally, with the fact that free, open software had... won.
-
Just to pile onto this some more:
"Ojeda said that there is a need to deprioritize these contributors, but that we still need to find talented people to join our community. That means finding ways to focus on the people who actually matter."
One of and maybe the biggest challenge we had fostering contributors that I - he said patting himself on the back - recognized early when I started at Mozilla, was in coming to terms, structurally, with the fact that free, open software had... won.
@mhoye I have wondered for years what the point of licences for open source projects really was if it was trivial to ignore them and it only cost money to deal with it (which companies had and the authors did not).
Am I missing something?
-
Just to pile onto this some more:
"Ojeda said that there is a need to deprioritize these contributors, but that we still need to find talented people to join our community. That means finding ways to focus on the people who actually matter."
One of and maybe the biggest challenge we had fostering contributors that I - he said patting himself on the back - recognized early when I started at Mozilla, was in coming to terms, structurally, with the fact that free, open software had... won.
That is to say: Firefox 1.0. 2004. A smart kid who wants to contribute to a high-profile open source project with name recognition and global impact had basically four choices: the Linux kernel, the GNU project, the Apache webserver and Firefox; outside serious nerd circles that was basically it.
A decade later, after macports and later homebrew, the explosion of the ruby and python ecosystems, git and GitHub and the entire directional shift of the software world, that kid had 10,000+ choices.
-
To explain what I mean by this: for a long time the Perl community took great pride in how difficult and terse the language was. The old joke that well-written perl was indistinguishable from line noise wasn't just a joke, it was a badge of honour.
That attitude was sustainable when the internet was small and alternatives were scarce. But the moment tools appeared that prioritized things like human ergonomics (python) and human interaction (ruby) the perl community started aging out and dying.
I'd respectfully disagree. One can write impenetrable shit in *any* language. I have archives of shit which can demonstrate this quite clearly!
Perl, in fact, encourages good formatting. Well-designed Perl can be nicely modularised into OO-lite objects as well.
I personally do not like Python, for example, because it treats white-space as syntactically critical.
"We all like different things" is probably the takeaway here
-
Just to pile onto this some more:
"Ojeda said that there is a need to deprioritize these contributors, but that we still need to find talented people to join our community. That means finding ways to focus on the people who actually matter."
One of and maybe the biggest challenge we had fostering contributors that I - he said patting himself on the back - recognized early when I started at Mozilla, was in coming to terms, structurally, with the fact that free, open software had... won.
@mhoye the phrase "the people who actually matter" makes me so god damned angry.
