On a side note, _in the context of workstations_, I wonder if a hypothetical OS that reimplements the Windows APIs (like ReactOS, but with perfect modern hardware support) would be better for end users than a Linux distro with a modern DE.
In the past, this hypothetical OS would be a revolution. But I feel that, in recent years, this gap is not as big anymore and Linux supports way more apps than in the past. Such an OS might even not be relevant anymore, even if it exists.
Do I have a blind spot on this? Is there value in having a "working ReactOS" as of 2026 _for workstations_?
> Is there value in having a "working ReactOS" as of 2026 _for workstations_?
The ideas behind the NT kernels are much deeper than what many Linux fans think of it. Just to give some examples:
- the NT kernel is build around supporting multiple subsystems, even though currently only "1.5" are in active use: the Windows subsystem and WSL1 (the latter has for many purposes been replaced by WSL2)
- the NT kernel is not built around "everything is a file" (a very leaky and very incompletely implemented abstraction that is used in GNU/Linux); instead the central concept is the handle
- the I/O in NT kernel is built around the idea that the API is "completion-oriented" instead of being "readiness-oriented" as in Linux.
This manifests in concepts like I/O Completion Ports (IOCPs), Overlapped I/O, ...
Since this is a deeply technical topic, I refer to https://speakerdeck.com/trent/parallelism-and-concurrency-wi... (the most important information is in the backup slides (slides 43-54)).
And you can also argue that that's overengineered (the original NT design docs were posted on here a while ago), that the UNIX model (while much more primitive and simplified) has proven more successful in the real world, and that the original "clean, overengineered" NT design has been buried under a progressively bigger truckload of crap year upon year and is no longer as clean as it once was.
> the original "clean, overengineered" NT design has been buried under a progressively bigger truckload of crap year upon year and is no longer as clean as it once was.
The original UNIX model has (considering the current state of GNU/Linux) similarly buried under a progressively bigger truckload of crap year upon year and is no longer as clean as it once was.
A central difference is: the NT kernel stayed rather clean (the crapload rather happened in the Windows subsystem).
Once you've taken most all of the other subsystems out of NT (which they pretty much have), all you're left with is is the crapload in the Windows subsystem.
I should have mentioned that I am speaking from a Plan 9 point of view where some of the common mechanisms are provided via the kernel file servers such as /proc.
IMHO with a couple of fixes which allow Linux+Wine to better simulate some specific lowlevel Windows behaviours (like this one recently in the news: https://www.xda-developers.com/wine-11-rewrites-linux-runs-w...)... a Linux distro with a 'Windows personality' (e.g. running Windows Explorer as desktop) should be pretty much indistinguishable from native Windows.
In the end it's all about driver diversity and quality though...
Wouldn't that just be Linux with Wine? It would be less effort to implement further APIs/fix incompatibilities on Wine rather than reimplement a new OS from scratch.
In my opinion, Civ1 was fundamentally simpler than any other Civ game. It is like the difference between playing DOOM and Halo. Civ 1 has very few units, very few civ types, very few anything really. That means that it is easy to keep the whole game in your head at once. For me, its a totally different experience.
It's simple (both in terms of gameplay and graphics) and it's the fastest Civ game to complete a full playthrough. Later releases made the game slower and more complex.
I played a lot of Civ1, Colonization and Civ 2. First time I tried Civ 3 I lost some city due to some culture or religious influence and ragequit (I was also working my first job at that point so didn't have as much time to spare).
Played a bit of Civ 4 and 5(or 6?) but never was really as hooked on them.
Honestly it feels to me that Civ1 - Civ2 is the most direct upgrade in the series. Civ 2 was mostly just a better civ 1. From civ4 onwards, the series was a lot more willing to shake things up in its gameplay.
Civ 2 was without doubt a much uglier civ 1, though. Isometric graphics in win 3.11 wasn't a good bet.
Civ 1 had good pixel art (look at those mountains! Not to mention the intro), good colors (and more of them!) and clean iconography. For me the look was part of the magic, so I never got into Civ 2.
I don't have a stake on AI, but more and more I see the following patterns:
- people that give in to AI do so because the technical merits suddenly became too big to ignore (even for seasoned developers that were previously against it)
- people who avoid AI center their arguments on principles and personal discomfort
Just from that, you can kind of see where this is going.
Most arguments against it are built on some moral principle and not on objective reality of usefulness.
Crypto used to be the thing to hate but that made sense as the objective usefulness of crypto was meek. AI models were always crazy useful but prohibitively expensive. Youd need an entire team to build your models. Now you dont.
Kinda off-topic, but I wonder if a hypothetical OS that reimplements the Windows APIs (like ReactOS[0], but with perfect modern hardware support) would be better for end users than a Linux distro with a modern DE.
In the past, this hypothetical OS would be a revolution. But I feel that, in recent years, this gap is not as big anymore and Linux supports way more apps than in the past. Such an OS might even not be relevant anymore, even if it exists.
Do I have a blind spot on this? Is there value in having a "working ReactOS" as of 2026?
Western surveillance tech is superior because it gives you the option to choose your gender on a fluid scale when they're vacuuming your private data, whereas backwards eastern tech limits you to only male or female.
I was pretty surprised when I learned recently that the Java alternative for green threads doesn't use colored functions. It put Java in a higher place in my perception.
It doesn't completely solve function coloring though. Causing carrier threads to get pinned is still not good, similarly as calling blocking function from async function is not good in colored systems.
Any time you have a barrier between one function being able to call another. The original article on this called them red functions and green functions. A green function can call a red function but a red function can't call a green function.
In terms of async, it's when you have to have a function with "async" attached to it and making it so that only other async functions can call async functions.
It ends up creating a weird circumstance where you can end up with a lot of duplicated APIs, particularly in libraries, because you are providing both async and non-async versions of functions.
The coloring is a property of concurrency safety and whether the language enforces it.
For instance, if you resolve a future in the wrong context you'll still have problems - the coloring is just a compile time error that you are doing things wrong, rather than a runtime deadlock.
The term comes from an old blog post [0] about different kinds of effect systems. Every function has a color, and every colored function can only call functions that are compatible with it, usually of the same color. The net result is that you end up either duplicating a lot of your common code so you have compatible interfaces for all the different colors (let's call that "separate but equal" if we're feeling spicy), or you end up shoving round pegs into the square holes of your dominant function color.
The terminology is used to talk about languages that have async and sync functions where you declare (or color) the function as either async or sync.
In these languages it's pretty common for the language to enforce a constraint that async functions can only call other async functions. Javascript / Typescript, Python are popular examples of languages with colored functions.
No, it refers to a function that has constraints on how it can be called and composed. A classic example is functions tagged `async` in languages like Javascript or Rust.
(Technically, that's the symptom - the underlying cause is that it's a function that involves some effect, like asynchronicity, or, in some functional languages, IO.)
What alternative would they be referring to? Green threads were only (re-)introduced to Java in version 21 in 2023.
I think what they're trying to say is that Java's green thread implementation has special support for async I/O. Threads that block on I/O aren't polled for completion by the runtime, instead they use OS async features under the hood.
This allows Java's green threads to compete performance-wise with async/await solutions, but with cleaner code that doesn't need colored functions.
In older green thread implementations in other languages, I/O can actually cause significant CPU overhead due to polling threads that are blocked by I/O requests.
"green threads" is generally how I see these systems identify as "non-colored but with async-like performance" fwiw. or "fibers". otherwise it's "async" or "coroutines".
There are different types of coroutines. The C++ type are sometimes called "stackless coroutines". With stackless coroutines you can't yield from a nested function call. Stackless coroutines are basically generators where you can pass arguments through resume, and async/await is effectively a form of stackless coroutines with yield/resume semantics that aren't fully generalized as coroutines, but oriented toward some bespoke notion of concurrency rather than as an abstract control flow operator.
"Stackful coroutines" allow yielding from any arbitrary point. They're basically fibers, except with the explicit control transfer and value passing yield and resume operators; there's no hidden or implicit control transfer like with green threads. Though, some people would argue allowing any function to yield without announcing this in their type signature is tantamount to hidden control transfer. Personally, I don't see how that's different than allowing any function to call other functions, or to loop, but in any event languages are free to layer on additional typing constraints--constraints that can be tailored to the desired typing semantics, rather than dictated by implementation details.
Stackless coroutines are typically implemented as a special kind of function whose state is allocated and instantiated by the caller. In contrast, stackful coroutines are typically implemented by reifying the stack, similar to threads. The "stack" may or not be the same as the system's ABI stack.
In stackful coroutines, unless there are additional typing constraints imposed by the language for hygiene reasons, any function can typically be called as a coroutine or use yield and resume. There's no need to compile functions into special alternative forms as call frame management works the same whether invoked from a coroutine context or not.
In the past, this hypothetical OS would be a revolution. But I feel that, in recent years, this gap is not as big anymore and Linux supports way more apps than in the past. Such an OS might even not be relevant anymore, even if it exists.
Do I have a blind spot on this? Is there value in having a "working ReactOS" as of 2026 _for workstations_?
reply