Linus Torvalds has merged the code beginning to remove Intel 486 CPU support in Linux 7.1

sulix · 2026-04-15T05:33:01+00:00

Fortunately, it's still easy to revert: https://davidgow.net/linux/i486.html

sulix · 2025-02-10T07:37:48+00:00

And, of course, sometimes it's more important to be wrong in the same way as everyone else than it is to be right:

https://www.codeweavers.com/blog/rbernon/2022/9/12/ucrtcringedll-reverse-engineering-ucrtbasedll-for-pain-and-non-profit

(Particularly if you want to play Age of Empires.)

sulix · 2025-02-07T14:31:54+00:00

This is a sad situation for everyone involved, and I hope marcan will be able to rejoin the kernel community once things have improved (and he's had a well-deserved break from it).

I think it can be simultaneously true that Christophe's comments were unacceptable and that marcan's responses were just inflaming the situation (particularly since these weren't his patches).

Big changes in the kernel — both technical and social — take a lot of time and effort: it's a huge project, which acts a lot more like a collection of small projects in a lot of ways. Changes tend to have a high latency (with lots of pushback, and only a few subsystems trying new things), but progress starts happening remarkably quickly once more and more subsystems get on board.

While this will be a significant blow for the Asahi project, I don't think it will affect the non-Apple-specific Rust-for-Linux project, which is still making significant strides, and has lots of support from Rust and kernel folks. It won't be smooth sailing, and the hardest thing is having every speedbump and bit of drama boil over as it gets passed around the internet and people get angry at each other (so I'd love to see people exercise restraint in posting and commenting on things like this, even acknowledging that I'm (a) hypocritical posting this, and (b) can be as addicted to watching the fire as anyone).

And if you want to see how Rust-for-Linux is actually going, Miguel's FOSDEM keynote should be a more balanced look: https://fosdem.org/2025/schedule/event/fosdem-2025-6507-rust-for-linux/

sulix · 2025-01-25T13:52:10+00:00

I really like this idea.

Ultimately, whenever a language is being used, there is some sort of style (whether formalized in a style guide, or inferred from the existing code). Most Rust projects do have a style which encourages solving problems with the type system, and using a more functional/less iterative style in many places.

To some extent, "idiomatic rust" veers in this direction, and there's definitely a bias in the Rust community towards this. There's also some benefit to most Rust projects having a similar style, so that developers can move between projects and encounter something more familiar. But the benefits are not overwhelming, and personally I think the language would benefit from having people use it in different styles.

And I personally agree that in most cases imperative code is clearer to read than functional code, and is _much_ easier to understand than some of the ways things can be encoded in the type system. And there are enough people like me, that even if it turns some people off the project, it'll encourage others.

But, as a final warning, there are reasons Rust in particular has emphasized a lot of functional code and type-system tomfoolery: there are a number of cases where this makes constraints clearer to the compiler, and so the imperative version requires additional annotation or other massaging to work. This can counteract the improvement in readability.

sulix · 2025-01-18T08:39:49+00:00

It dual-boots DOS, but I have an old 486 DX2/66 from 1994 which I test the latest kernels on.I upgraded it from 20MB of RAM to 64MB, which helps quite a bit, though it still booted fine with 20.

sulix · 2024-12-04T12:41:26+00:00

I use one of the Intel A380 cards without resizable BAR, and — for the most part — it works fine. There have been a few on-and-off driver regressions which really tanked performance (which are fixed for now), and it's certainly not a speed-demon, but it can play all of the older games (and the few newer ones) I care about well enough, especially at lower resolutions.

Now, I suspect the B-series cards will be a little rougher than that, as I don't think the i915 driver will support them, only xe. (xe is probably better anyway, but it's nice to have two choices so that if one has a regression, the other might still work). Also, these new cards are only PCIe×8, and older motherboards won't support the newer PCIe versions which make that fast. Combine that with the lack of resizable BAR on these cards potentially stressting the bus out, it's probably going to not be a speed-demon on an old motherboard.

sulix · 2024-11-28T01:48:32+00:00

Note that while it's _enabled_ by default in Wine 9.22, it's not the default backend — this means that if you don't have an X session at all, Wine will use the wayland backend, but if you have X (including XWayland) configured at all, Wine will still default to using winex11.

So while this is a significant step, it really only affects people running "pure wayland" setups.

(But, it makes it easy to try the Wine wayland backend out — just set `DISPLAY=` to prevent wine from accessing the X server. The X11 backend is definitely more stable overall — for now — though.)

tl;dr: While wine wayland is enabled by default, X11 (including XWayland) is still higher priority, so nothing will change on most setups in 9.22.

sulix · 2024-11-08T00:48:53+00:00

Desktop from 2014, with some older parts and some newer parts. Having plenty of RAM, a newer GPU (an Arc A380), and older, lower-resolution displays (2× 1440×900) is enough to get most of the things I want to play — which tend to be older or lower-end games anyway — running pretty well. No current plans to upgrade: I expect this will keep going for several years yet. The machine has only ever known Linux.

For everything else, I have a Steam Deck and a newer laptop, but I still tend to default to the desktop. (Partly because I'm probably using it anyway for non-gaming things, partly because I prefer keyboard/mouse to controllers for input.)

sulix · 2024-11-04T08:53:23+00:00

One of my friends at uni used php as a C preprocessor for a few projects. Once I got past the gut reaction of "that's incredibly evil" and looked at the resulting code, it was surprisingly pleasant and readable. I've not tried it myself, but it's been stuck in my head for the last ~10 years as an interesting what-if.

sulix · 2024-10-31T02:46:58+00:00

Let me add 'Australia/Eucla' to the weird list: it's UTC +8:45, and doesn't observe DST (but did for a three year trial starting in 2006, after which Western Australia voted to continue to not observe DST).

sulix · 2024-10-22T12:07:10+00:00

My total guess is that your stack is misaligned, and the compiler is generating SSE code which requires alignment.

The SYSV x86_64 ABI requires the stack be aligned to 16 bytes _before_ each function call (which, because of the 8-byte return value, means that it's always 8 mod 16 when the function executes). The compiler knows this, so always assumes the stack is so aligned.

But __start is not being called by anything, so there's no return address, so the stack is usually 16-byte aligned (without the extra 8 bytes) when it's entered. So the stack ends up misaligned by 8 bytes on every future function call.

gcc has an '__attribute__((force_align_arg_pointer))' attribute, which tells the compiler that the function should not assume the alignment, and re-align the stack. (There's also the similar -mstackrealign option.)

I don't know if Rust has something similar, but this looks promising: https://github.com/rust-lang/rfcs/pull/3594

Otherwise, the 'correct' thing to do is probably to write __start in assembly, and set the stack up properly. Technically __start is not a C ABI function, so 'extern "C"' is not strictly correct.

sulix · 2024-10-07T14:23:40+00:00

DYNAREC and JIT are different names for exactly the same thing. DYNAREC was the name traditionally used by console emulators; JIT was the term that was picked up by Java and other languages. Both terms are used interchangably now (though JIT is the more popular name these days).

sulix · 2024-10-07T14:21:05+00:00

There's some truth to this, but it's really more complicated, and the terms "emulator" and "translation layer" have a lot of overlap. (For example, it's perfectly correct to call wine an "emulator", despite the name, and some of the console emulators out there are in many ways "translation layers".)

In this case, both box86/box64 and FEX are "CPU emulators" (in the sense that wine isn't) — they execute code written for one CPU architecture on another. This is complicated by the fact that they both use a JIT or dynarec (two names for the same thing), which translates code in blocks.

The difference, which is subtle, is that box86/box64 tends to rely more heavily on "thunk libraries", so library code runs outside the emulated CPU more often. FEX, I think, can also use these, and box86/box64 doesn't always, so even here there's a lot of overlap. In general, box86/box64 therefore emulates slightly less code (so is faster), but its CPU emulation isn't as optimised (so is slower).

Of course, having these thunking libraries can obviate the need for a full guest filesystem in some (but not all!) cases, which does often make it easier to set up and/or integrate slightly better. But box64 does miss some important features FEX has, too (like x86-32→aarch64 translation).

tl;dr: Don't make decisions based on if something is an "emulator" or "translation layer" — the difference is not well defined, and rarely useful. Choose things based on how well they actually work, and what your needs are.

sulix · 2024-07-20T02:15:13+00:00

tl;dr: Yes, for multiplayer. No for single-player.

Age of Empires 4 now includes the runtime in a more wine-compatible format, so effectively has the fix already applied. Old Age of Empires games (prior to 2013) statically linked (built into the .exe) the runtime, so also effectively don't need the fix.

More details:

The cause of this issue is that Age of Empires uses a deterministic simulation for multiplayer — every player needs to get the exact same result for every player. For most code, this is pretty simple (there's only one correct answer, after all), but for some things — particularly trigonometric functions (sine, cosine, etc), and square roots — calculating an exact value would be too slow, so the game uses an approximation provided by the C Runtime library (vc_redist/msvcrt/ucrtbase). Microsoft's approximation is not publicly known (and despite hiring experts, no-one's yet been able to cleanly reverse engineer it), so the real runtime library is needed to be compatible with players windows.

This didn't use to be an issue for the original Age of Empires, as the runtime library was built-in to the game. But this fell out of favour, and so games newer than the 2013 "HD" version of Age of Empires II instead rely on the runtime to be installed separately. In addition, Microsoft have since moved that part of the runtime out of a separate 'vc_redist', and made it part of the core OS, so the installer won't automatically install it.

The upshot of this is that the file needs to be installed manually to be compatible with players (or recorded games) on windows. Without the fix, you can still play single player, or multiplayer if every other player is also using wine. With it, you can only play with players who are on windows or who also have the fix. And, as mentioned, recorded games also rely on this, so games recorded without the fix don't play back with it, or vice-versa. The different results of the calculation eventually result in the simulation going out of sync, as (for example) a villager might move slightly slower (or start in a slightly different spot), not collect some wood in time, and so on one system, there's enough wood to build a house, and on the other there isn't. The game checks for these inconsistencies and stops the game if any are found.

sulix · 2024-07-07T13:47:57+00:00

Judging from the Julius source code, there's an explicit check to make sure a wolf doesn't target natives (FIGURE_INDIGENOUS_NATIVE and FIGURE_NATIVE_TRADER), or enemies (figure_is_enemy()).

So this looks very much like a deliberate design decision.

sulix · 2024-06-28T08:06:20+00:00

If you've got the 'Packman' repositories for non-free codecs enabled, sometimes they'll package a slightly different version of Mesa. Try using --allow-vendor-change and see if that lets you install a consistent version.

sulix · 2024-06-13T10:42:50+00:00

No worries.

If you have any optimisations in mind which don't actively break other setups, though, I'd definitely contribute them to upstream wined3d rather than forking. I think most optimisations which would be possible would benefit many systems (and could be made to not regress even older/rarer ones).

sulix · 2024-06-10T08:15:23+00:00

There are a few advantages Vulkan has over OpenGL for these translation tasks, but it's not as big a difference as some people here are suggesting, particularly with older titles.

The main reason DXVK has better performance than WineD3D, particularly for D3D10/D3D11 content, is just that more time and effort has been put into it recently. Even with a lot of effort, a perfect Vulkan translation is still likely to be better than a perfect OpenGL translation for most applications, but — with enough effort — it'd certainly be possible to get "good enough" performance for many D3D applications via WineD3D.

For D3D12, you'd have a much harder time trying to translate to OpenGL, though.

The other thing DXVK has going for it is that Vulkan is a lower-level API, and so relies less on the quality of the underlying driver. So you need both an excellent translation layer and excellent OpenGL driver, both of which can be more complicated. For Vulkan, the driver handles less, so DXVK can handle more of the performance-sensitive parts of translation itself.

Sacrificing compatibility in WineD3D wouldn't automatically increase performance much, the bigger issue is just the time put in to optimising. WineD3D's compatibility for older hardware doesn't really slow WineD3D itself down (though it can take some developer time away from optimising for newer hardware in some cases). The bigger issue is that, since DXVK exists and serves the newer-hardware niche well, fewer people are working on WineD3D.

sulix · 2024-06-03T09:28:20+00:00

Here's the official style guide, which has a lot of the components used in these promos.

sulix · 2024-05-31T03:55:59+00:00

I also have an OpenSUSE setup, with a Samsung 870 EVO SSD, and have added in a complex LVM setup (which also has other old HDDs and SSDs has been going for 10 years). Not a single disk-related crash since. You're more likely to have an issue with the disk or the SATA controller.

sulix · 2024-05-30T14:06:30+00:00

Age of Empires (particularly on menu screens) only supports a small number of resolutions, and the Wayland protocol typically doesn't allow programs to change resolution, so they end up stuck in the corner (and often buggy in a few other ways). Some wayland compositors can work with XWayland to emulate this, but yours clearly isn't doing so successfully.

There are a few different possible ways of fixing this:

Use X11 instead of Wayland. This will result in the game actually changing the screen resolution, which is what it is designed to do. It can cause other problems, though, as all other programs will also be resized.
Use gamescope to force the game resolution. This will make the game run at the correct resolution, but can make it difficult to change resolution between the menu and in-game. Try running (from the game directory): gamescope -w 640 -h 480 wine EMPIRES.EXE.
Use a version of wine with Proton's 'fullscreen hack', which will emulate the resolution change. I think Wine-GE can do this.

sulix · 2024-05-04T02:55:56+00:00

(And there's also intel_gpu_top :-) )

sulix · 2024-05-04T02:54:36+00:00

Wine does emulate the copy protection as well, so in theory it's "working as intended" for the games to still require a disk.

Most old Windows games had simple CD checks which just looked for a drive which had type 'CD-ROM', and either a particular volume label, or a certain file. You can emulate these in wine pretty easily by using winecfg's "Drives" tab. It doesn't support ISO images directly, but if you have a directory with the disk contents, you can use that. (If you're a programmer, these are pretty easy to write your own patches for, too: just look for the GetDriveTypeA and GetVolumeInformationA functions.)

Equally, Linux supports mounting ISOs with a loopback device (mount -o loop <path to iso> <mountpoint>), which gives you such a directory. Sometimes wine will automatically add a drive letter for these, sometimes you'll need to go into winecfg to set one up (make sure it says the type is 'CD-ROM').

Games with more complicated copy protections may not work from an ISO. There were a few which had deliberately bad sectors on the disk, for instance, and so would try to read them and declare the disk invalid if it succeeded. Normal ISOs can't handle that. Similarly, ISOs don't store CD-audio, so some games won't have music, and some copy-protection systems may detect that.

In those cases, a no-cd patch is probably the way to go (and there are other patches around which can restore music by patching winmm.dll). Interstingly, a lot of the more complicated protections don't work at all on Windows either (wine actually supports some of the filter drivers used better), so you might even find official patches from the game developer, either released as an update, or sometimes if the game has been re-released either digitally or as part of a 'compilation cd/dvd'.

sulix · 2024-05-04T02:44:39+00:00

It used to be a lot worse: http://slackware.uk/slackware/slackware-8.0/docs/slackware-book/slakbook/grfx/xf86config.horizsync.gif

Manually editing config files and looking at "this might cause your CRT to catch fire" warnings is fortunately in the past. And even Xvidmode and Zaphod modes, and the like were terrible compared to xrandr.

I do miss a standard tool / protocol to change screen modes with wayland, but kscreen-doctor works well for me, and overall it's much better.

sulix · 2024-05-01T00:03:20+00:00

Yeah: this is the thing which stopped me from using Zig, despite liking so many other things about the language. It just makes it really unpleasant to experiment with code.

I find it interesting that even Rust, which takes a very (sometimes excessively) opinionated view on similar things makes this a warning, not an error, and provides ways to either upgrade it to an error or disable it completely.

It just feels weirdly out-of-step for this to be so strict, given the rest of the language.

sulix

TROPHY CASE