> At that point the code becomes a compile target, and then you need a new source of truth.
The problem is that there won't be a single source of truth left. Everything will have to be reverse engineered each time, which is extremely wasteful in my opinion.
Isn't it already too late for that?
The devices were made obsolete in part to disable known methods of de-DRM kindle books.
It is quite possible you won't be able to de-DRM anything if you try right now, and any point in the future.
It is the absolute best for backwards compatibility: it runs 16 bit apps.
Now it is getting faster for gaming.
And the reverse relation is also true: In Linux, the best backwards compatible stable API is WinAPI.
I can play 30 year old Windows games in Linux. They just work and run better than ever.
For the same project (https://www.descent2.de), I can not even install the dependencies to compile it in a modern distro, as every library is deprecated and removed from the repositories. The precompiled native Linux binaries also can't work.
People say this a lot about Linux and it somewhat rubs me the wrong way - sure, the Windows binary works if you install its library dependencies (wine). Likewise (OK, ever since libc5/glibc2 changeover in 2001) the Linux binary should work if you have its library dependencies (SDLv1 it looks like?). So what's really the problem? Your distribution stopped distributing the dependencies, making them harder to find? "DLL Hell" was a thing too.
I didn't see any binary downloads for Linux on that website, only source code.
I gave it a try anyway, the dependencies were actually not a problem for me, Debian has libsdl-{net,image}1.2-dev, libglew-dev, and so on, and if your distro does not have SDLv1 there is libsdl1.2-compat. But after the dependencies, there was a problem with the source code doing something involving bitfield packing that does not compile on x86_64.
I do see the source code has lived on, i can `apt install d2x-rebirth` on Debian 13 which has a comment about https://www.dxx-rebirth.com/ ...is that helpful?
> the Windows binary works if you install its library dependencies (wine).
Yes but all it takes is an `apt-get install wine` or `zypper install wine` or `pacman -S wine` or your distro equivalent and if you are using a Linux distro with any sort of desktop functionality, 99% of the time wine will be there.
> Your distribution stopped distributing the dependencies, making them harder to find?
Yes, this is a big problem because these dependencies not only are harder to find but even if you track all of them (there is a chance they too have their own dependencies) you still need to figure out how to build and install them. And if they are old enough for distros to drop them, then chances are building them isn't going to be a straightforward `./configure && make && make install` ("straightforward" is very relative here :-P). And woe is you if there are conflicts with newer (yet API/ABI incompatible) versions of these libraries and/or their dependencies.
Of course since you have the source, technically you can make things work, but that doesn't make the process any less of a major PITA.
After a few fixes, it builds on a debian-13. You just need to install a few dependencies (glew, SDL, curl).
The real problem here is the tooling. New versions of automake and C++ compilers are stricter than they used to be.
Indeed, for long term conservation, you need to vendor your dependencies AND your tools to make sure that the project is sustainable without intervention. But with the magic of LLMs now, this is not a problem anymore. Claude was able to fix it in less than 10 minutes.
And having the source code beats playing the original game. You can recompile in high def and make all the modifications you want to make it feel like a modern game (or not!) and sill get you your dose of nostalgia.
I have been arguing for years that Win32 is the most stable Linux ABI. Commercial games are all proprietary software, so they're more prone to breakage as the libraries and APIs they depend on change or even disappear over time.
I believe use of Electron is known as premature deoptimisation and if it had been a thing when Knuth coined the original phrase I'm sure he would have come up with that term too. Use of Electron to deliver software is popular and works but that doesn't make it any less of an abomination.
I'm actually considering, for the first time since 2013/14 when I worked on a Visual Studio extension, creating a piece of desktop software - and a piece of cross-platform desktop software at that. Given that Microsoft's desktop story has descended into a chaotic mishmash of somewhat conflicting stories, and given it will be a cold day in hell before I choose Electron as the solution to any problem I might have, most likely I will roll with Qt + Rust, or at least Qt + something.
20-odd years ago I might have opted for Java + Swing because I'd done a lot of it and, in fairness to Swing, it's not a bad UI toolkit and widget set. These days I simply prefer the svelte footprint and lower resource reuqirements of a native binary - ideally statically linked too, but I'll live with the dynamic linking Qt's licensing necessitates.
I'm going to put a huge `depends` on this one. If it's for a small widget you click on once in a while, but it stays loaded as a full Electron app all the time, then yeah it's terrible. If it's a full time front and center application like VS Code, then Electron earns it's keep. The more often you interact with the app the more willing you will be to put up with the headroom that Electron requires in order to get the real benefits that Electron provides.
Now that's an stupid argument. I'm with you.
Removing SQL injection has little if anything to do with performance, so it is not an optimization. I guess we will get more of this with the vibe coding craze.
We'll see. It's easy enough to ask Claude to red team and attack the system given the codebase and see what holes it finds to patch up. It's good enough now to find blatantly obvious shit like an SQL injection.
That would require them to accept it was the wrong decision.
I am doing the only thing I can: to vote with my wallet.
My current phone is a Sony Xperia and it has the headphone jack. I am listening to Hi-Fi music from Tidal right now, using the jack, and wired Crinacle earbuds.
If you want an easy, stress free job, sure, nothing is high stakes. You will never be invited to meetings with executives, and you can google everything all the time.
If you, on the other hand, attend meetings, you will need both deep knowledge (requires many hours of styding) and fast thinking, and the questions will make you realize you know little about many things. You need to have general knowledge of many things, not just whatever you are building at the moment. If you are successful on these meetings, your salary can and will grow.
Also, some meetings will make you realize that college and/or university are life in easy mode. Very few things you consider hard in college will be work-level hard.
The problem is that there won't be a single source of truth left. Everything will have to be reverse engineered each time, which is extremely wasteful in my opinion.
reply