Ah, hashcash. Wish that had taken off, it was a good idea …

I feel this – we had a junior dev on our project who started using AI for coding, without management approval BTW (it was a small company and we didn’t yet have a policy specifically for it. Alas.)

I got the fun task, months later, of going through an entire component that I’m almost certain was ‘vibe coded’ – it “worked” the first time the main APIs were called, but leaked and crashed on subsequent calls. It used double- and even triple-pointers to data structures, which the API vendor’s documentation upon some casual reading indicated could all be declared statically and re-used (this was an embedded system); needless arguments; mallocs and frees everywhere for no good reason (again due to all of the un-needed dynamic storage involving said double/triple pointers to stuff). It was a horrible mess.

It should have never gotten through code review, but the senior devs were themselves overloaded with work (another, separate problem) …

I took two days and cleaned it all up, much simpler, no mem leaks, and could actually be, you know, used more than once.

Fucking mess, and LLMs (don’t call it “AI”) just allow those who are lazy and/or inexperienced to skate through short-term tasks, leaving huge technical debt for those that have to clean up after.

If you’re doing job interviews, ensure the interviewee is not connected to LLMs in any way and make them do the code themselves. No exceptions. Consider blocking LLMs from your corp network as well and ban locally-installed things like Ollama.

Yes, and they used the name first, not google. Arseholes.

So whats the selling point of this vs. just Devuan itself?

This sounds really nice. I’m using Devuan currently, but MX looks very polished and worth a try…

C# development was spearheaded by Anders Hjelsberg, one of the brains behind Borland Delphi/Object Pascal.

There’s a dedicated tool named sshguard which works nicely.

Bedeviled NXP/ARM SDK stdlib. Hate it, we need \n\r there. Why!!! What a PITA.

Dunno about docker setup, but I mirror github repos I worry may disappear automatically using my self-hosted gogs instance. (Gitea/Forgejo likely also can do it). It’s point-and-click, you just specify the github URL and check a box “this is a mirror”.

Neat, will try it out.

Has anyone written an android desktop search widget for it? A quick search only foumd one veeery old experimental project.

Writing a kernel in two languages when it has for its entire history been written in one is just asking for needless complexity.

If Rust wants to have a kernel, then perhaps port or re-write Linux in Rust from scratch as a separate project. Once it’s reached a point of being self-hosting, let ‘the market’ decide in an open competition.

If the Rust version is demonstrably superior and more secure, then it’ll naturally supplant ‘legacy Linux’.

As someone who hasn’t yet moved to Wayland, how good is support these days for alternate keyboard mappings? Is this something that each individual window manager needs to support, or does Wayland itself manage them?

Not just “international keyboard” support, but truly arbitrary keyboard/symbol mapping support. I muddle in programming with APL, which needs its own key mapping with Unicode symbols.

I recall KDE had its own mapping support which used some system APL layout but I’d rather not have key mappings tied to a specific window manager.

deleted by creator

Fair enough… I admit I’m a bit of an old curmudgeon, set in my ways. :s

Aren’t you at all curious why it failed though? (If not, no harm no foul – I certainly know time diagnosing a bug is always in short supply, from personal experience). What if it’s a symptom of something important that might happen later even in Fedora 41?

Sometimes it just feels like containers are used as justification for devs to blow off bug reports. As a dev I want to understand why a failure occurs.

Agreed there – it’s good for onboarding devs and ensuring consistent build environment.

Once an app is ‘stable’ within a docker env, great – but running it outside of a container will inevitably reveal lots of subtle issues that might be worth fixing (assumptions become evident when one’s app encounters a different toolchain version, stdlib, or other libraries/APIs…). In this age of rapid development and deployment, perhaps most shops don’t care about that since containers enable one to ignore such things for a long time, if not forever…

But like I said, I know my viewpoint is a losing battle. I just wish it wasn’t used so much as a shortcut to deployment where good documentation of dependencies, configuration and testing in varied environments would be my preference.

And yes, I run a bare-metal ‘pet’ server so I deal with configuration that might otherwise be glossed over by containerized apps. Guess I’m just crazy but I like dealing with app config at one layer (host OS) rather than spread around within multiple containers.

Call me crusty, old-fart, unwilling to embrace change… but docker has always felt like a cop-out to me as a dev. Figure out what breaks and fix it so your app is more robust, stop being lazy.

I pretty much refuse to install any app which only ships as a docker install.

No need to reply to this, you don’t have to agree and I know the battle has been already lost. I don’t care. Hmmph.

Keyboard media keys (Fn + F keys, eg. vol mute, +/-, brightness etc.) do NOT yet work in mainline kernel. There is some good work going on over here on github but it’s preliminary.

Also note kernel 6.10 broke the bottom display it would appear; I’m using kernel 6.13-rc4 currently.

If you happen to be trying to do this on a laptop with dual-graphics and the GPU is NVIDIA, it took me a while to find that one often can get proper GPU support by adding this just before wine (as in, right before it on the same command line):

__NV_PRIME_RENDER_OFFLOAD=1 \
  __GLX_VENDOR_LIBRARY_NAME=nvidia wine <game .exe> ...