Well, it kind of sucks to have an idea to contribute and no way to contribute because you have to be invited by someone before you can offer...

The problem is volume.

Just like AI slop content isn't generally that much worse than human slop that flooded the services, at *least* the human slop required more effort to generate than it takes a person to watch, and that balance meant the slop was obnoxious, but the amount was a bit more limited and easier to ignore.

Now the LLM enables those same people that make insufferable slop to generate orders of magnitude more slop than they could before. Complete with companies really egging them on to make as much slop as they possibly can.

LLM can be useful for generating content, but it is proportionally *way* better at generating content for content creators that don't care about their content.

Which for self-directed people is an easy-ish solution, don't let the LLM far off a leash if you use it at all. Problem is micromanaging executives that are all in and demanding to see some volume of LLM usage the way they think is correct (little prompt, large amounts of code).

As far as I've seen, the AI fanatic's answer is "don't care about the code".

They ask for something and whatever they get, they get. The bugs, the glitchiness, the "not what they were expecting" are just accepted as attempts to amend purely through prompting tend to just trade one set of drawbacks for another rather than unambiguously fix stuff. Trying again is expensive and chances are not high that it'll be that much better, unless you have an incredibly specific and verifiable set of criteria that can drive automatic retry on failure. However making that harness is sometimes harder than making the code itself, and without a working reference implementation even that may be a lost cause.

I've always hated trying to salvage outsource slop, and LLM has a very similar smell with similar reactions where people resign themselves to the crappiness.

Well, in one respect it is 'very useful'. Executive direction that the legacy codebase must be 'documented' fully. Poof, it is 'documented'. Is it correct? Who knows, no one will ever read it, but it fluffs the executives "thought leadership". The compromise between 'port the code' which is a risk no one will take and 'document the code to prepare for a porting effort that will never come'.

Just be careful to keep the LLM vomit clearly distinguished from actually curated documentation, lest some naive person one day believe the documentation is actually based on anything.

So we have LLM vomit directed in ways to make the leadership feel like we are 'properly' leveraging the hype while we wait for the hype train to run out of steam.

Problem being that this is requests from people trying to contribute.

Even when they avoided github, they got hit.

I wager at one point, a project that stayed strictly email based will have threads with this sort of slop in it.

Unless you make your repository and all means of contact with you invite-only, it's going to be hard to avoid.

Though they managed to ultimately extend this github brand to github copilot, that will gladly push stuff to forgejo, gitlab, etc...

Even worse, they've extended it to tooling that they pitch to developers who use git for anything under the brand affinity of 'github' (which *way* too many people already assumed git == github).

May not ever 'figure it out'.

A lot of 'leadership' saw "everyone is hiring tech" in the aftermath of the pandemic and so they did, with or without any vision.

This represents a narrative consistent with shedding those people they didn't have business value for. So they end up no more broken than they were in 2019, and it provides a narrative consistent with doing things "right".

Based on some codebases I've seen...

AI slop can be bad, but has *nothing* on the closed source codebases I've seen for low quality slop.

Don't care. If your shit shows me ads, it's not getting into my kitchen. Note to self: Don't buy appliances from Samsung anymore.

Yes, I am vocal in how much I hate ads. I believe the CEOs of advertising companies should get one hit with a stick for every time their ad bothered someone even in the slightest.

Exactly what I'm saying.

The fact that users and enterprise customers are not demanding better software from Microsoft with the same fervor their ancestors demanded that the witch be burnt speaks volumes.

And I'm specifically talking about operating systems here. Software can crash for all I care. I'm fine software quality being all over the place, the market can sort that out. But operating systems are natural monopolies and the foundation for everything else. We should not accept shoddy quality there.

So, during this story, someone pointed out a command to contextualize the info:
# userdbctl user --output=json $(whoami)

Ok, so run that and I see "hashedPassword". A field that my entire career has been about "not even the user themselves should have access, even partial access to it needs to be protected by utilities that refuse to divulge that to the user even as they may need that field to validate user input. And now, there it is, systemd as a matter of course saying "let arbitrary unprivileged process running as the user be able to access the hashed password at any point".

Now this "age verification" thing? I think systemd facet is blown out of proportion. All it is is a field that the user or administrator injects, no "verification". Ultimately if wired up, the only people that are impacted are people who do not have admin permissions to their system and have an admin that's forcing your real date of birth somehow.

The biggest problem comes with "verification" for real, when an ecosystem demands government ID or credit card. However, most of the laws consider it sufficient for an OS to take the owner at their word as to the age of the user, without external validation. So a parent might have a chance at restricting a young kid (until kid knows how to download a browser fork that always sends the "I'm over 18" flag when it exists), but broadly the data is just whatever the people feel like.

Users should never be able to do things that cause crashes in the same way that drivers should not ever be able to press any button or press any pedal that causes the engine to spontaneously burst into flames.

I'm also a Mac user, but let's not boast here, shall we?

My personal guess would have been at least 10x. Did Microsoft bribe the study authors?

Dude, are you living under a rock?

These bands are creating new music. But the money that allows them to do so comes from their old music. I have bands in my collection that have been making music for 30 years.

No they don't. They don't even make ok money. Tours are expensive and a lot of people, from road crew to venue security, take their cut before the musicians. The big guys, they make a killing on tours. But the small ones sometimes don't even break even.

In fact, a common wisdom in the industry is that touring is worth it not because the tour itself makes profits, but because it builds a fanbase and drives what is called "catalog discovery" - both old and new fans looking buying the albums with the songs they liked (and for the old fans, didn't know).

This study: https://www.giarts.org/article... says that 28% of income across all the musicians surveyed comes from tours. The share is larger for the rock/pop sector where it nears 40% but even that isn't easy money. And if you consider that only 20% of the rock/pop musicians make more than $50,000 a year, then it becomes a hollow statement.

Plus, it goes directly against your first statement - while on tour the band is not creating new music. So if you want to drive musicians more towards constantly creating (which most of them already do), then you can't make live performances the main income source.