Besides windows being a bit of a sluggish mess, I’m not particularly fond of its default window manager. Developer are replacing the os part by running linux under wsl, maybe there should be a way to replace the window manger as well? Oh wait, what’s left? :)

I see what you did there but LLMs aren't compilers. There is no source code except the prompts, and those do not really work for someone else to later add stuff or fix bugs.
If there was working source (prompts) that could be revision controlled and that could be patched and regenerated, then I guess it would be workable to not tinker with the generated code.

You wouldn't compile your C once, and then force any fixes to be direct binary patches to the executable, would you?

Ok, fair point. However from what I have seen the current set of tool aren't really supporting this kind of repeatable workflow (yet?). You'd need to be able to store the seed/context window, and a repeatable reference to the actual model used.

If you can't understand the code as allo writes above, then the prompts leading to the code is all you have. If that is not repeatable, how do you even know what to modify?

There might be some process here that can be used as a sustainable workflow but it's not at all obvious.

"inconsistent style" can create problems when doing maintenance of the code base over time, different files use different libraries for the same thing and so on. Makes traversing the code much harder for someone trying to add something.

Way back at my then workplace there was a guy who refused to write anything in ANSI C, he only did K&R. I guess it was consistent within the portion he was working on at that particular time, but it kept others out of there.

It's not really the same as the process of using an LLM to create the code isn't repeatable. You might not get sufficiently working code feeding in the same instructions.

The equivalent of this using a traditional computer language would roughly be to compile the code into binary, and then throw away the source code.

This is an interesting perspective. I have a similar time of experience 25+ years in embedded development. We didn't always have formal code reviews, but I've rarely not worked in a team. Usually 3-4 people in the same discipline as me, and then cooperating with other disciplines.

But as our perspectives are so different, I can't help to wonder what the actual ratio between single devs and team devs really is? Never seen a study on this.

Ok, but are these people then performing their job adequately? If you are working in a team that uses code reviews, what do you do when you get a question about some part you don’t understand? It’s going to be pretty hard to get the PR approved in a well functioning review process.

Well, now it will at least be free of authoritarian US regimes. Also wondering why this is /. material

I guess itâ(TM)s time for the world to start collecting the debt and sever the ties then, no? The US regime can then mind their own business. They are welcome back when/if they change their mind. No hard feelings.

So does anybody know the market share of linux desktop at the work place? If my experience of this is representative, it should be much higher than 4%, at least in engineering.

Although this is no longer the case for many distros. You have debs, rpms, snaps and flatpaks and they come from many different sources, some with dubious traceability to source.

I suspect this is just the most boring April fools ever concocted.

I disagree. The "snaps" are the problem, because unlike the apt-get flow, "snaps" are uncurated. They also auto update by default, and in fact it's very hard not to have them auto update. This means a vendor can easily push malicious content at a later time without most users (and canonical) noticing, even so called "power users". Even Apple lets users control if and when to update. "snaps" as they are implemented now are not an acceptable distribution solution IMO.

mod parent down. You should absolutely be allowed to say "something stupid" privately among friends.