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.

Tell me how you're ever going to implement this on any open-source operating system ever?

Because people will just patch it out.

It's not like it's even a boot-time requirement (thus necessitating it being in the kernel/initrd, etc.). It's an account requirement. Which means that it can be patched out in no time at all.

As far as I know, not one single open-source OS has actually implemented this requirement (they put a field that would be useful for it into systemd, but nobody's actually using it).

Apple push an silent automatic update just for your computer that the next time you type in that key, it sends it to the FBI.

Next?

We're not dealing with a bit of software piracy or finding out who stole someone's Bitcoin, you're talking about agencies dealing with anti-terrorism and wars.

Only in America could you legally argue that an unnecessary profit-making middle-man was legally required and that it would somehow "reduce costs".

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.

The problem with the vast amount of hardware turf that Microsoft covers is different from say, Apples, because Apple highly controls their hardware platforms, and Microsoft by its nature, cannot.

Add in driver components, software legacies, and Microsoft users continue to pay this tax, generation after generation. So indeed these issues ARE similar.

When Oracle updates key functionality, they risk a domino effect, just as Microsoft does. The QA feedback loop can help, but all old code must become crusty because of physics. Reinventing the core code then causes its own ripple effects.

There are ways to fight this, at the risk of business partners going away-- the hardware makers and software vendors with huge installed bases.

Every time a change is made, it would be wonderful to do regression testing. That's why there are "insider" programs, the little beta site for these changes because regression testing today is impossible because the installation platforms are too diffuse.

There is truth in the aphorism, "The bigger they are, the harder they fall.".

Have you ever noticed why no one celebrates Patch Tuesday in the pub? It's because they're waiting by consoles waiting for stuff to break.

Windows, client and server, are a house of cards. This goes far back in history. The citations you challenge are each provably wrong. Ever wonder why the cloud isn't rife with Windows servers? There's a reason for that. Cloud Native Windows is almost an oxymoron. Linux and to a lesser extent, BSD, have taken over that space.

In so many ways, Windows is now a legacy data OS in data centers and for good reason. It's developer community has all but collapsed. It's backwards compatibility with other house-of-cards platforms like dot-net have put ball-and-chains around its neck.

The additions of tawdry pre-release-in-production AI with Co-Pilot causes new train wrecks each and every day.

No serious services developer uses Windows as a new development platform. The metaphors you diss are a dodge. You know exactly what the remarks are about. Windows continues to be a sieve for security. Linux and BSD are far more difficult to breach, correctly configured-- and it doesn't take much.

As a developer, if you are one, Microsoft is putting you to the pasture. Have fun eating oats.