Alpine 3.24 is out, but there is still no vibecoding ban :(

it is kinda sad because this will probably be the last Alpine release I contribute to. i do not want to contribute alongside vibe coding: it is a fundamental philosophical difference.

yes, there is technical debt, but vibe coding will create a different, and much worse, form of technical debt: as people become more and more detached from their technical output, they will quit understanding said technical output

@dysfun i am less concerned about that, because fuck copyright tbh

@ariadne 🙁

what a painful and fundamentally disturbing realignment this is all proving to be

@dysfun generative output is public domain, thus it can be redistributed. the liability for using copyrighted data in the training process likely falls on the model vendors.

@dysfun sure, but i see no reason there would be a different outcome in europe, for example.

@dysfun yes, i agree it is still a risk, but it just isn't the concern i have.

the concern i have is software defects being missed because people are prompting rather than thinking about the feedback they are observing while building.

i've watched people do vibe coding, and when the model goes down a path which is clearly wrong, the users tend to accept its explanations rather than push back on it. that's dangerous for software reliability.

@ariadne my entire hobby electronics hobby has basically been ruined by this. libraries i've depended on for a decade have gone full slop. they treat it like a hustle. i just want to make LEDs blink and I can't even do that anymore without giving rationalists money (since they autorun it on PRs).

@ariadne

Gentoo, on the other hand, has a clear policy against it:
https://wiki.gentoo.org/wiki/Project:Council/AI_policy

I wonder what they'll do about the linux kernel itself.

@albertcardona @ariadne nothing, seeing as that same page says it "does not prohibit adding packages for (...) software that is being developed with the help of such tools upstream". it's unfortunate, but there isn't really any other option, practically speaking

@hatzka @albertcardona yes, i will probably just go use gentoo instead, probably directly maintaining my software in portage

@dysfun this is why i've come to the conclusion that code contributions from LLMs are not allowed in my projects, but LLM-based vulnerability scanning is ok.

a bug report is a bug report, after all.

@hatzka @albertcardona @ariadne

Well, there *is* another option... You can always switch to GNU Hurd.

We introduced experimental Hurd profiles for Gentoo on April 1. The only joke there was the part where we said we were immediately deprecating Linux for eventual removal. ;)

It is an interesting space to explore, and who knows what the future might bring?

@eschwartz @hatzka @albertcardona i need my computer to continue working reliably.

@ariadne what I don't understand is the advantage for a project like alpine - is the council really convinced that the productivity improvements that have completely failed to materialize in the past two years will somehow happen and will be indispensable for alpine to stay... competitive? with... other distros? even though it's not a competition?

is someone in the alpine council actually just taking a kickback?

@dysfun yes, that is why i prefer the maintainers to do the scans and just explicitly ban LLM use from non-maintainers :p

@kerio no, the argument is that alpine's technical debt, particularly in areas where there is less interest in contributing, can be cleared by a maintainer vibe coding. Alpine 3.24 includes some examples of that already.

which... maybe. i am not convinced though.

@ariadne so the plan is to replace technical debt with technical debt that takes an increasingly expensive subscription from a proprietary service? 😬

@ariadne @dysfun this is roughly my standpoint as well

@kerio @ariadne technical credit default swaps

@kerio it seems so. I can't depend on that.

@ariadne @eschwartz @hatzka @albertcardona I’ve also heard some mumbling (but do not have an independent source) that the most of the Hurd x64 port was extruded from a slop machine.

@ariadne @dysfun *as long as it's actually vetted by someone competent first*

the LLM beg bounty grifting is exhausting

@jpm @ariadne @hatzka @albertcardona

I'm not really following Hurd mostly. But I heard the same rumor. The person who told it to me said that when he went looking to confirm the rumor he discovered an unmerged patch series that had received no objections, in large part because it hadn't received much notice at all.

I was told that it's therefore a reason to be cautious but "panicking is premature".

No idea what's happened since then. Portage can theoretically support many kernels if wanted...

@eschwartz @ariadne @hatzka @albertcardona there’s really no escape, and this is why I’m so disillusioned in the entire IT industry. Even FreeBSD has slop in kernel (thanks to OpenZFS)

@ariadne @hatzka @albertcardona

Yeah I would very much regard it as exactly what it claims to be: an experiment that isn't production ready but lets the people hacking on it get some zero-pressure fun tinkering time in.

And maybe, one day... Well, Gentoo is the opposite of excluding the mere consideration of "in the possibility that it becomes production ready we will get behind it".

@ariadne @dysfun Unless you take it as comparable to photocopier or audio-sampler usage, where even if upstream voided copyright it still falls on final distributors anyway.

And as much as I can also be "fuck copyright" at times, it's the current legal framework with pretty harsh laws towards individuals and Alpine isn't a formal org, so would likely fall on the council and/or whoever packaged it.

That said I'm more concerned about things like reliability/security than legality, so for once I'll stay on either v3.23 for a while or a ~rolling "oldstable" Alpine rather than latest-stable.

@lanodan @dysfun i still consider options. i backed down from forking because i do not wish to destroy the distribution. but i don't know what to do.

@lanodan @dysfun and yes, it is not just about AI, but about all of the other things too.

@eschwartz @hatzka @albertcardona @ariadne Hurd is actually worse, SMP support on x86_64 was vibecoded

@ariadne @dysfun Well I guess could always move to another distro, thankfully here I'm more sitting on Gentoo than Alpine so I can have a bit of a "wait on the side and see what happens" approach.

And I guess you're referring to governance on that last one? It really tainted Alpine for me on that part, like comparable with Debian current shenanigans if not worse.

@lanodan @dysfun yes. i think it is reasonable to expect the TSC to meet regularly, and the council to meet regularly, and for a foundation to be incorporated given that it has been ~6 years since the ticket for a foundation was opened

@jpm @ariadne @hatzka @albertcardona

Well, I asked my source and he tells me that the LLM patch was rejected for "being wrong and also being a jumble of too many changes mixed together".

On top of which rms has said gnu projects cannot accept LLM contributions anyway. (Apparently it took kind of a while to get that statement but it has finally been said?)

@eschwartz @jpm @hatzka @albertcardona do you have a source for RMS saying that? because several GNU projects *are* accepting LLM contributions...

@ariadne so there goes the last good distro? honestly considering quitting computers at this point

@xyhhx are there really no other distros that are good? what makes alpine good to you?

@ariadne i just really liked a lot of the choices alpine made ootb. small, secure kernel; many of the packages i wanted were available and up to date; apk is lovely; and everything was simple without compromising on quality. and tbh many of the people who ive met who worked on it seemed good (yourself included but others too)

im honestly very surprised about the lack of policy on vibe coding

also tbf I'm in a extremely bad headspace these days so maybe im being overly pessimistic

@ariadne @kerio What areas is the Alpine debt mostly in, and what are some examples of vibe coding trying to address them?

@ariadne @jpm @hatzka @albertcardona

So my understanding is that the GNU project is concerned that LLM output cannot be copyrighted meaning that they'd stop being able to enforce the GPL, and that any already merged patches don't need to be reverted but need to be kept track of in case they decide later that it does need reverting. And that no new LLM code is permitted until and unless there is explicit permission to do so. It's from internal meetings so I'm not sure about a public source.

@dysfun @gsuberland yes, exactly

@ariadne That’s sad to hear… personally I started using Alpine because of you, I saw your posts about the distro, got curious, tried it and liked it.

For me I think it’s too early to jump ship, Alpine became my favorite distro, because of the way it does things and its efficiency…

Sometimes I think about going back to debian or Arch and enjoy the glibc compatibility, but idk, I’m already used to my life on Alpine and musl.

I think Alpine without you will be weird and maybe it will lose some of its essence

@nube I am thinking through things.

@ariadne @lanodan @dysfun

This feels rather unfortunate. Even back in 2005 Gentoo knew enough to write up a governance structure that requires the council to hold open meetings at least once a month or face being dissolved and re-elected.

Although hmm, that may have had a bit more to do with the nature of the previous dysfunction.

@ariadne @eschwartz @jpm @hatzka @albertcardona

From what I remember reading on emacs-devel, GNU has no policy in place _yet_. They are working on one. source: https://lists.gnu.org/archive/html/emacs-devel/2026-03/msg00554.html

Emacs itself is not accepting LLM code as a precaution. source: https://lists.gnu.org/archive/html/emacs-devel/2026-03/msg00425.html

@eschwartz @jpm @hatzka @albertcardona @PuercoPop at the same time GCC does seem to allow LLM contributions now.

@ariadne @jpm @hatzka @albertcardona @PuercoPop

GCC has not considered itself a GNU project save in name only for a long time now. I wouldn't expect them to allow the FSF to order them around for anything, regardless of topic.

They are currently in the process of running a Working Group to "establish a policy", but I do have hopes regarding it because @thesamesam is on that working group.

@ariadne @eschwartz @hatzka @albertcardona I can't trust a system that does not define PATH_MAX and forces a dynamic allocation every time I want to build a path or call realpath(). Ha ha, only serious.

@ariadne @kerio by definition this isn't true, vibe coding can only create tech debt

@aburka hence 'i am not convinced though'

@ariadne yeah sorry I was attempting to agree

@fwaggle @kerio @ariadne

turning technical debt into financial debt

@fwaggle @kerio @ariadne when the mega corps buy the little guys and one of the products slowly (or quickly) dies.

@ariadne @eschwartz @jpm @hatzka @albertcardona @PuercoPop

Note `allow` might be the wrong wording here. Maybe not complain about the contributions. Now what is happening is the fortran front-end reviewers seemly are using LLMs for their patches. I have not raised it as a problem because I just don't have the time or the energy to raise it as a problem.
As far as I know only fortran front-end folks are actively using LLMs openly (the key here is openly); other folks in the middle-end have been kinda of told off for using it if used openly (the person only attached the patch to the bug report and was told off for doing that). Now there could be folks using LLMs not openly and sometimes it is hard to tell.

Note I have reviewed a patch which smells like it was LLM generated but not marked as such but it also could have been just a bad patch too.

@pinskia @ariadne @eschwartz @jpm @hatzka @albertcardona @PuercoPop The GCC SC has delegated to a WG to recommend something: https://gcc.gnu.org/wiki/working-group-ai-policy and as a GNU Project maintainer I'm aware of the internal discussions and requests by RMS and we are factoring that into our recommendations (including the possibility of having to wait).

@jpm @eschwartz @ariadne @hatzka @albertcardona That could be fixed by getting filesystems out of the kernel...

@eschwartz @hatzka @albertcardona @ariadne You would get something usable writing it from scratch quicker than by starting with HURD. It's like, designed entirely around being intentionally wrong about everything.

@ariadne I'm late to this "party" and only found out that Alpine doesn't have a decent AI policy from the article The Register just published which mentioned this thread https://www.theregister.com/os-platforms/2026/06/24/alpine-linux-324-scales-new-desktop-heights-with-cosmic/5259985

Coincidentally I'd been toying with the idea of installing Void Linux on a PineBook Pro (PostmarketOS does support this but I wanted to install Alpine directly ... but that didn't work so I looked for options ... Voids installer seemed to get further than Alpine hence, doing some research).

Anyway, it looks like Void Linux might soon have a fairly sensible (IMHO) AI policy for contributions https://github.com/void-linux/.github/pull/1/files

Could Alpine be encouraged to do the same?

I suspect the kind of people that use Void and Alpine are doing so to avoid systemd and similar conventional "slop" surely AI slop should be excluded to?

@fionasboots i am not 'anti-systemd', that has nothing to do with my motives of using and working on alpine

@ariadne
My apologies, I didn't intend to imply your specific motives. I was, clumsily, trying to say that there may be some alignment in values between Void and Alpine. Maybe systemd-avoidance isn't it but both distros do seem to aim for lightweight solutions and minimalist approach so could there be other common ground/approaches?