I agree with the overall sentiment, but I’d like to add two points:

1. Everyone starts off as a code editor, and through a combination of (self-)education and experience can become a software engineer.

2. To the point of code editors having to worry about LLM’s taking their job, I agree, but I don’t think it will be as over the top as people literally being replaced by “AI agents”. Rather I think it will be a combination of code editors becoming more productive through use of LLMs, decreasing the demand for code editors, and lay people (i.e. almost no code skills) being able to do more through LLMs applied in the right places, like some website builders are doing now.

I’m not that familiar with WSL, can it interface with libraries like DirectX or Vulkan?

I didn’t know that, thanks! That’s actually very impressive, and given how efficient qemu-style emulators are, I wouldn’t be surprised to see near-native performance despite a little bit of overhead from emulating game logic.

No, not that much. The emulation of the syscalls are specific to Linux, so none of that is usable on Windows. They could reuse the emulator, but it seems likely they would write their own from scratch so they can keep everything closed source. Obligatory: fuck Microsoft.

Well, not exactly… WINE is a compatibility layer for syscalls between the x86 Windows API and (among others) the x86 Linux API, quite similar to how DXVK translates from DirectX to Vulkan.

What proton does is combine utilities like Wine and DXVK into a user friendly bundle, along with contributing substantially to the projects it bundles to make them interoperate well.

This looks to me like they want to bundle another utility, which does fast emulation of x86 user code on an ARM Linux system. Another commentator mentioned they are using FEX for this, which looks to me to do the same core task as qemu-user, but more focused on x86 to ARM and generally user-friendlier. That emulator could then be used to run x86 Wine on ARM.

The way qemu-user and FEX emulate one ISA on another is actually very cool btw. They realise massive speed gains by intercepting syscalls and executing them directly, instead of emulating a whole x86 Linux system.

To combat this I think drivers, firmware, etc. should be acknowledged as being in the same category as spare parts, manuals, repair tools, etc. They are equally as vital to being able to repair your device, and therefore should be open sourced at the latest when a manufacturer pulls support. Of course I would prefer them to be open sourced immediately, but with how software IP works currently that seems like a pipe dream, especially for devices with very complex drivers, like GPU’s.

IMO this should be the case for everything developed using public money, looking at you, pharmaceutical companies…

And they force you to use it if you want autosave, which is essential in a work environment given the stability of MS Office programs (or at least my ability to crash Excel).

I don’t know what happend the last few years with Lunduke, but it seems like he went down the conservative/conspiracy rabbit hole and now I don’t trust anything he writes anymore. Please see for yourself, this article is a good starting point: https://lunduke.substack.com/p/the-tech-industry-hates-you?utm_source=profile&utm_medium=reader2

Friendly FYI: Brave is based on Chromium, so under the hood it uses the same browser engine as Chrome. I can’t recommend switching to Firefox enough, not only because it’s a good and fully featured browser, but also because its existence is vital to keeping Google’s power in check.