Because running servers costs money. The project I work on gets donations towards it’s CI costs and it’s not insignificant.

Your making a big assumption extrapolating from one particular study involving Java code and a static analyser.

How is that patch sloppy?

I feel the term slop is being overused to cover anything an LLM has touched. If I ask an agent to re-read a mail thread for me and apply the changes to my tree to review is that slop? Would you feel better about it if I copy and paste from email to code in my editor?

I’ve just been doing a bunch of bug triage which was mostly driven by the agent although I checked the issues where it had commented. Was that slop? Ironically a lot of the issues where AI generated although for the most part more complete than a lot of the purely human submissions we get. Are those bug reports slop? What about the poorly drafted human ones?

That’s not kernel policy but LF guidance. From the kernel’s point of view patches still have a high bar to pass to get merged and I don’t think we have enough data yet to see if LLM based submissions to the kernel have a higher or lower error rate than humans.

I certainly feel the uptick in LLM reports though - one of the projects I’m working on is seeing a deluge of them at the moment.

Even Debian has popcon as an opt in. I can see why collecting data about hardware and package choices is useful to Ubuntu. I didn’t think they collected any personally identifying information.

If it’s finding valid vulnerabilities then it’s just another tool like static analysis, fuzzers and sanitizers. There definitely seems to be a difference in quality compared to earlier generations that were behind the sloppy avalanch of reports.

I swear people have rose tinted glasses as to the state of the init system before the current generation of system management daemons.

If you really want to have Debian without systemd there is always Duvean but the Debian architects are free to choose the technologies that solve the very real system orchestration problems that exist.

Who are the community employing? Why do they need consulting before code changes are made?

What a pointless drama article this is. FLOSS software does stuff for legal compliance more often than you’d think. The whole point is people can contribute fly by patches and the maintainers make the decision to merge. It seems like being an optional field but potentially providing useful functionality is enough for systemd. If you don’t like it I’m sure there are forks you could join or even use a different init system. No one’s freedom is being oppressed here.

When it comes to export controls and sanctioned entities it doesn’t really matter what Red Hat would like to do - they have to comply with the law in the jurisdictions they work in. Even if it was purely a community project individual contributors face a similar liability if based in those jurisdictions.

When it comes to sanction lists there is a fair amount of commonalty between the US and Europe. This is really something to complain to government about.

What was wrong with working with Godot that made them want to fork?

I guess somewhere between 6 and 7…urm 6/7 👐 (and my kids say I don’t understand memes 😅).

I think the OP’s analysis might have made a bit of a jump from overall levels of hobbyist maintainers to what percentage of shipping code is maintained by people in their spare time.

While the experiences of OpenSSL and xz should certainly drive us find better ways of funding underlying infrastructure you do see a higher participation rates of paid maintainers where the returns are more obvious. The silicon vendors get involved in the kernel because it’s in their underlying interests to do so - and the kernel benefits as a result.

I maintain a couple of hobbyist packages on my spare time but it will never be a funded gig because comparatively fewer people use them compared to DAYJOB’s project which can make a difference to companies bottom lines.

The year of Linux on the desktop is whatever year you personally switched over.

mu4e inside my Emacs session.

I’ve generally been up front when starting new jobs that nothing impinges my ability to work on FLOSS software on my own time. Only one company put a restriction in for working on FLOSS software in the same technical space as my $DAYJOB.

The article mentioned there is a long history of forks in the open source Doom world. It seems the majority of the active developers just moved to the new repository.

I helped with the initial Aarch64 emulation support for qemu as well as working with others to make multi-threaded system emulation a thing. I maintain a number of subsystems but perhaps the biggest impact was implementing the cross compilation support that enabled the TCG testing to be run by anyone including eventually the CI system. This is greatly helped by being a paid gig for the last 12 years.

I’ve done a fair bit of other stuff over my many decades of using FLOSS including maintain a couple of moderately popular Emacs packages. I’ve got drive by patches in loads of projects as I like to fix things up as I go.

I didn’t know who Kirk was until the assassination I have better things to do with my limited time than go on a deep dive into their history before posting any comment on the news. I kinda got the vibe when I realised that was who Cartman was based on in the recent South Park.

Was it before or after Oracle acquired Sun that the fork happened? I’m fairly sure it was Oracle that passed the project across to Apache and I have no idea why the Apache foundation accepted it.