The LLM part is bad news but it isn't the sign.
-
@corbet@social.kernel.org @mhoye @gvwilson definitely more than one, unless one's incredibly insular and conservative about who's getting counted.
Setting aside the blame-game for a bit, though: for someone who's been tech adjacent for 30+ years, I have a weird sideline in psychology/spirituality (once disparagingly described as a "fluffy bunny dippy hippie.") With that hat on, I do wonder if a lot of people are experiencing a deep/unconscious dissatisfaction with tech, as a primary thing (rather than as a result of e.g. LLM roll-out.) It might actually explain some of the AI-enthusiasm as well, even if that's a very misguided manifestation.
I have a nagging feeling that what we really need to do right now is start radically reducing the complexity and "abstractness" of our society. I'm not at all sure however that we have the time to do that gracefully before the wheels come off.
Returning to OSes, I have no real idea what the right way forward is. If nothing else, we need Linux's hardware support.
-
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.
@mhoye tbf the value of terseness is very much an individual thing - I certainly find modern languages a little too verbose to read easily. The MS-style (pseudo) Hungarian notation that took over the world in the late 90s is also a total curse.
Isn't the real lesson that we need to build ecosystems that allow for more diversity of contributors? Hard to do in one particular codebase, but a more loosely coupled ecosystem of smaller components might do it.
-
There are plenty of good alternatives to driving your community off a cliff like a gaggle of demographic lemmings, but if you're still convinced that mailing lists and insularity are the path to durability in this godforsaken year of our lord two thousand and twenty six then I'm not sure what words will convince you that there's nothing at the bottom of that cliff but sharp rocks and seawater.
If your community isn't accessible and welcoming to new, learning participants, the clock's ticking.
@mhoye I have many deep criticisms of the modern kernel community, but conflating mailing lists with insularity might be a tough one to argue. Email is still just about the most widespread, open comms platform - most of the alternatives people jumped to instead were more or less proprietary. Isn't the issue more a failure to build better tooling on top of that platform? (Which tbf a fair amount of effort in recent years has been going into remedying.)
-
@hal_pomeranz If it's up to me to pontificate, I think it will happen sooner than people might expect. It will either an explicitly anti-AI OS like NetBSD or a pure fork that focuses on a welcoming community and modern tooling.
@mhoye @hal_pomeranz hardware support is I guess the biggest stumbling block. A few years back someone in .. I think? .. the redox community was talking about running linux in a VM to use its drivers with hardware passthrough, then copying data back and forth. The *BSD world seems to have the "rump kernel" idea as a similar thing. I'd love to see something like that, I wish I still had the energy & skills to attempt to contribute
-
@corbet@social.kernel.org @mhoye @gvwilson definitely more than one, unless one's incredibly insular and conservative about who's getting counted.
Setting aside the blame-game for a bit, though: for someone who's been tech adjacent for 30+ years, I have a weird sideline in psychology/spirituality (once disparagingly described as a "fluffy bunny dippy hippie.") With that hat on, I do wonder if a lot of people are experiencing a deep/unconscious dissatisfaction with tech, as a primary thing (rather than as a result of e.g. LLM roll-out.) It might actually explain some of the AI-enthusiasm as well, even if that's a very misguided manifestation.
I have a nagging feeling that what we really need to do right now is start radically reducing the complexity and "abstractness" of our society. I'm not at all sure however that we have the time to do that gracefully before the wheels come off.
Returning to OSes, I have no real idea what the right way forward is. If nothing else, we need Linux's hardware support.
@srtcd424 I am not sure whether my post here is an act of kindness or of vandalism, but here you go for your radical reduction! Make of it what you will.
https://ecosophia.net/ -
@srtcd424 I am not sure whether my post here is an act of kindness or of vandalism, but here you go for your radical reduction! Make of it what you will.
https://ecosophia.net/@paulmckrcu ooh, ta. My reading comprehension/energy is sporadic these days but I will give it a go
Many years ago I heard someone attribute a quote to Rudolf Steiner about "the point of absolute materialism from which all progress will be made" - I've never managed to actually find a reference, but it does feel like it describes where we are now.
-
@mhoye @hal_pomeranz hardware support is I guess the biggest stumbling block. A few years back someone in .. I think? .. the redox community was talking about running linux in a VM to use its drivers with hardware passthrough, then copying data back and forth. The *BSD world seems to have the "rump kernel" idea as a similar thing. I'd love to see something like that, I wish I still had the energy & skills to attempt to contribute
@srtcd424 @mhoye @hal_pomeranz heh. Long before Linux achieved something like FOSS hegemony on the driver front, we were picking the cherries (blackdown jdk) while running our homemade console servers on NetBSD boxes serving the world. Linux emulation on BSD was faster than 'linux'. That was 1998. Times a comin and the little red devils be back.
-
@corbet @mhoye @gvwilson I do also wonder if these problems are in some way an unexpected social consequence of a monolithic kernel with in-tree drivers etc. It seemed like a brilliant idea for years/decades, because internal APIs could be refined without piles of compatibility layers, etc - but it also ends up creating a monolithic community.
I've been wondering for a while if a less performant microkernel(ish) approach with defined APIs would make for a healthier social ecosystem. But I guess industry might not have tolerated that performance hit.
-
re: "It's the talking about planning secession while simultaneously complaining that nobody new wants to learn"
There are three people identified as "she" in that piece, and one of them was the only person to say something like "[she] said that she can identify the people who will stick around fairly quickly, and some of the new folks who have come in are excellent. For this reason, she still spends a lot of time with people sending spelling fixes. "
It's gendered labor.
@richpuchalsky @mhoye this tracks. It's not that they can't find people to mentor, it's that they think they are above mentorship.
-
@mhoye Linus and his posse have been elitist unwelcoming jerknobs for decades though. If an alternative were to appear, I agree that people would leave them to wither and die. But so far no reasonable alternative has appeared. *BSD, Plan9, etc have all failed to gain traction.
@hal_pomeranz @mhoye indeed, the moat of Linux was always hardware support, which was there because people got paid to make it happen. Community isn’t a competitive advantage until you have software most folks can even run on their machines. Linux being anti-community is nothing new, as you pointed out. It’s being run as a business, and from what I can tell quite a profitable one. Perl of course had nothing like that.
That’s not to defend any of that. It’s just… what it is.
-
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.
@mhoye This was not my experience of the Perl community. I found a lot of discourse about how to write humane and readable Perl. The people pushing this were anything but marginal.
-
@mhoye That would actually help new contributors understand how existing maintainers are using LLM “tools” the “right way”! It’s more process of course to be that rigorous in using an LLM to include how you’re using it when offering up code, but if it really is a “useful tool” then you have to teach people how to use it.
@mhoye @r343l yeah this part is fucking baffling.
Either commit and say "look we want them to be tagged so we know as much about provenance as possible" (even just for knowing which specific LLM model related reasons!)
Or say you don't have to disclose at all.
I feel like they know that there's backlash and they're trying to protect people from facing it. Which all I have to say to that is: cowards.
You don't get to have it both ways
-
@froztbyte @mhoye having worked on python packaging until they suddenly released "oh wait this guy is going to make things actually good" https://web.archive.org/web/20250218154403/https://cfp.packaging-con.org/2023/talk/hpuhu7/ and then having astral steal credit for my work and sell to openai and then seeing
uvpop up fucking EVERYWHERE having fucking EVERYONE rave about HOW FUCKING FAST IT IS when I FUCKING DID THAT SHIT—i think labor needs rights and protections@mhoye @froztbyte @hipsterelectron fun fact I was using
uvto manage things for a work project (idek why I normally use poetry) and then found out they ship Tk support but they don't bind with Xft which means the fonts look fucking awful -
@mhoye also I think almost everybody who regularly came to DC Perlmongers meetings in the day has moved on to other languages (if they're still programming at all), so it seems unlikely that even the olds who used to use Perl first would still make that choice.
-
@froztbyte @mhoye it puzzles me frankly particularly the rust part. rust is a microsoft fucking product now but nobody listens to packagers about bootstrap deps. i used rust for 10 years and made the zip crate the safest and fastest zip impl ever and i cannot contribute code to that system again until gccrs is complete
@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?
-
@froztbyte @mhoye having worked on python packaging until they suddenly released "oh wait this guy is going to make things actually good" https://web.archive.org/web/20250218154403/https://cfp.packaging-con.org/2023/talk/hpuhu7/ and then having astral steal credit for my work and sell to openai and then seeing
uvpop up fucking EVERYWHERE having fucking EVERYONE rave about HOW FUCKING FAST IT IS when I FUCKING DID THAT SHIT—i think labor needs rights and protections@hipsterelectron @froztbyte @mhoye This shit right here is why I am not working on my seL4/Idris crap in public. Giving your shit away to comrades is fundamentally different from giving your shit away to the people in the power structures above you, and we need a way to encode and defend that distinction before we can have free software that doesn't feed the monsters.
-
@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 @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
-
@hipsterelectron @froztbyte @mhoye This shit right here is why I am not working on my seL4/Idris crap in public. Giving your shit away to comrades is fundamentally different from giving your shit away to the people in the power structures above you, and we need a way to encode and defend that distinction before we can have free software that doesn't feed the monsters.
@hipsterelectron @froztbyte @mhoye Not that my shit is any good; just look at the rest of what I've put up prior to this if you doubt me. But it's the principle of the thing!
-
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 it appears to this reader that Linus hates people and likes a stochastic text machine.
-
@hipsterelectron @froztbyte @mhoye Not that my shit is any good; just look at the rest of what I've put up prior to this if you doubt me. But it's the principle of the thing!
@lykso @froztbyte @mhoye i like idris a lot and i have mixed feelings on seL4 but it is definitely cool software
-
P pelle@veganism.social shared this topic
