Rayosay

From the perspective if the people working on it, I imagine it's immensely satisfying when they successfully reverse engineer something and get it working. It's not on the same scale or of the same complexity, but I feel that satisfaction when I finally understand something I've been trying to reverse engineer in a retro game.

From a user's perspective, I can only speak for myself, but I'm grateful for the Asahi Linux project's work. I have less than zero interest in ever running macOS again. It's user-hostile, constraining, and not a good experience. I prefer Debian with Plasma 6. But Apple makes high quality hardware, and they are one of the few choices for a fast ARM laptop with excellent battery life. I avoided getting one for a long time until Asahi got to a point where it ran pretty well on the M1 and M2 with relatively few caveats. Then I bought an M1 Air second-hand, and have used it exclusively with Linux ever since. I'm very happy with it. My only complaint is that I have to waste a big chunk of disk space to keep a macOS install on a separate partition that I can never remove and occasionally need to boot into to get firmware updates since I can't get them through fwupdmgr like I can on most of my other systems.

What's wrong with it? I like Crush. It's hard to find good harnesses that don't pull in mounds of Javascript like Pi and OpenCode.

Spice86 has a pretty good built-in debugger. I found it much easier to work with than DosBox's debugger. Spice86's DOS emulation isn't as good as DosBox's yet, but it's getting better all the time. https://github.com/OpenRakis/Spice86

I second LowLevelMahn's recommendation for IDA 5 Free. It's a good disassembler for DOS applications and helps me navigate what I'm looking at in the Spice86 debugger. It also runs very well in Wine.

That's great! I didn't know that Arch had online manpages too. I frequently use https://manpages.debian.org/ for similar reasons.

As someone who has tried this, I agree that Winelib is the way to go. Just don't go into it expecting it to "just work" without any code changes. Since NTFS is case-insensitive, it's likely that you'll have to fix your include paths to use the right case. If you used any MSVC compiler extensions, you'll likely need to modify your code to not use them or add `#ifdef __GNUC__` with alternative implementations for GCC. GCC's `-fms-extensions` can emulate some of them, but not all. Winemaker can help you with some of the more wrote aspects of this conversion, but not all of it. It will also produce Makefiles for you, but if you want a single build system that works on all platforms, I'd recommend that you use CMake with a CMake toolchain file targeting Winelib and `winegcc` instead. Visual Studio has pretty good CMake support these days, so it should look pretty much like any other Visual Studio solution when you open it there too.

Once you do get it working, you'll notice that on first run of your application Wine will create a `~/.wine` directory and populate it just like it would if you created a new Wine prefix to run a standard Windows application in. Other than that, it will feel pretty seamless. You'll even get a native application launcher for it (which is really just a shell script to run your project's `.exe` under Wine, but it's hidden from the user so it feels native if you don't look too closely.) Compiling against Winelib has the added benefit that you'll only be using win32 features that Wine supports, and can use native platform libraries (if you choose to do so when you're compiling your application, as described in the Winelib User's Guide) mixed with Windows libraries from Wine. It's nicer and works more smoothly than just running a Windows application you compiled with Visual Studio under a bundled version of Wine, in my experience.

I'm sure that you'd be able to bundle it as an AppImage, but I haven't actually tried that part myself.

Good luck!

I'm hoping that the new Snapdragon X2 Elite based laptops coming out this year will beat it. Qualcomm seems to have been trying to upstream driver support for them earlier than the X1. Then it's up to what kinds of laptops OEMs offer with them.

Personally I'd still just get a used ThinkPad X13s Gen 1 on eBay at this point if I were going to buy another one today because they're available for around $400, and I don't see anything better that's passively cooled, with great battery life, and great Linux support available at the moment. I hope there will be a better, faster alternative in the near future. I'd gladly upgrade.

I haven't really played around with that much, sorry. I don't typically use sleep on my laptops. I prefer to either hibernate or just shutdown and start up again when I need it.

I'd guess that the X13s hardware support in Ubuntu is likely as good as Debian, and switching probably wouldn't help you much. I have noticed that newer kernel versions (notably 6.12 and later) and the latest firmware (as of sometime last year) really fixed a lot of little issues for the X13s. That probably makes a bigger difference than the distro. I'd check to see which versions you're using.

I think that the ThinkPad X13s Gen1 might meet these requirements. It is my favorite ARM Linux laptop I've ever used. It has great support in Debian 13 (trixie), and it feels pretty smooth and fast. It doesn't have any fans, stays cool, and I regularly get a full day's worth of battery life out of it with margin to spare (10-12 hours). It's better than the newer Snapdragon X1 Elite based ThinkPads, in my opinion, even though it isn't quite as fast because it is passively cooled, is easily fast enough that I've never noticed it feeling "slow", has good driver support in mainline Linux and Mesa (which took a few years to be fully worked out, but is there now), and it's readily available for a good price (on eBay).

I'm in Southern Indiana (Columbus area), and I'd be interested.

It's actually no longer experimental as of the Gitea 1.21.0 release. (It was released in Gitea 1.19.0 as experimental pending some hardening and additional features that they wanted to add, which have now been completed.) It is still under active development, but is a lot more mature now.

Like you, I have been using it since it was experimental, and it has been very nice.

My only complaint with Gitea Actions was that it required Docker specifically, not other OCI-compatible runtimes, but they recently added support for rootless Podman, so even that is no longer a complaint.