ch_123

It's definitely true that they do not have access to the original OS/2 source - this has been confirmed by people from Arca Noae in various interviews/presentations I've seen. I've never heard a definitive explanation for why, but two reasons are usually speculated:

1) Due to the amount of third party code in OS/2 (most notably, the DOS and Win 3.x layer) that IBM is unable to license out the code, or unwilling to go to the trouble to figure out the legal implications.

2) IBM has lost some or all of the source code.

There are roughly three categories:

1) There's a bunch of commercial software which only runs on OS/2. A lot of it was vertically integrated software either developed for a specific customer by IBM, or developed in an "IBM shop". The ticket machines for the New York subway were powered by OS/2 until relatively recently. There are also supposedly a bunch of banks which have OS/2 dependencies.

2) There are still hardcore OS/2 fans who use OS/2 as their main OS. As you correctly assume, getting something like a modern web browser to run on OS/2 is a challenge, but some people grin and bear with it anyway.

3) Strange people like me who run things like OS/2 on spare computers or VMs for the novelty value.

> So to me it seems that we don't want abstractions when trying to study certain things about a whole system. Instead, we want to view all of its components and then build our understanding from there. Abstractions hide the things that we care about.

I disagree. My experience is that most problems require a very thorough understanding of a specific slice of a system. It is rare (again, in my experience) that solving a problem involves understanding the whole system. This becomes more true the larger and more complex the system is. Abstractions allow you to ignore the irrelevant pieces and focus on what matters.

I feel like it's far easier to find more zealously anti-Rust people than zealously pro-Rust people - hating Rust has almost turned into a meme.

> After spending time on Apple’s M1/M2 Macs (coming from a large x86_64 desktop), going back to x86_64 feels like a regression, both in performance and battery life.

I have a Thinkpad X1 with a Lunar Lake CPU, running Fedora. Battery life is comparable to the Mx Macbook Pros I've owned or used. Performance is not as good on synthetic benchmarks, but more than good enough for my needs, even when running VMs or containers.

The VT1xx keyboards used linear switches, you may want to look at modern mechanical keyboards with linear switches as a rough approximation. Having tried typing on one in a museum, I recall the VT1xx as relatively scratchy compared with more modern keyboards, although that could have been a wear and tear issue.

The keyboards of the VT2xx/3xx series are awful, and the later ones had rubber dome keyboards which are among the nicer rubber dome keyboards I've tried. I own both a VT320 and VT420, and managed to get a new old stock keyboard for each.

Converting these keyboards to speak to a modern PC involves replacing the controller board with a new one with open source firmware. You can program the keys to send any scan code you like.

Because of cost - particularly given the current state of the RAM market. In order to have so much memory that you never hit memory spikes, you will deliberately need to buy RAM to never be used.

Note that simply buying more RAM than what you expect to use is not going to help. Going back to my post from earlier, I had a laptop with 8GB of RAM at a time where I would usually only need about 2-4GB of RAM for even relatively heavy usage. However, every once in a while, I would run something that would spike memory usage and make the system unresponsive. While I have much more than 8GB nowadays, I'm not convinced that it's enough to have completely outrun the risk of this sort of behaviour re-occuring.

You're implying that people are telling you to set up swap without any reason, when in fact there are good reasons - namely dealing with memory pressure. Maybe you could fit so much RAM into your computer that you never hit pressure - but why would you do that vs allocating a few GB of disk space for swap?

Also, as has been pointed out by another commenter, 8GB of swap for a system with 8GB of physical memory is overkill.

I've heard "square root of physical memory" as a heuristic, although in practice I use less than this with some of my larger systems.

I think it's some kind of misplaced desire to be "lightweight" and avoid allocating disk space that cannot be used for regular storage. My motivation way back when for wanting to avoid swap was due to concerns about SSD wear issues, but those have been solved for a long time ago.

I ran Linux without swap for some years on a laptop with a large-for-the-time amount of RAM (about 8GB). It _mostly_ worked, but sudden spikes of memory usage would render the system unresponsive. Usually it would recover, but it in some cases it required a power cycle.

Similarly, on a server where you might expect most of the physical memory to get used, it ends up being very important for stability. Think of VM or container hosts in particular.

They've been trying for nearly 30 years:

https://en.wikipedia.org/wiki/Intel740

Some folks have had success running it on certain server hardware (Usually HPE Proliant). There are no graphics drivers for x86, so it is X forwarding only.

> SP2 came out it was hated again with renewed vigor

Was it? My memory is that SP2 was the point at which most outlets considered to be "good".

> What "modern software support" do I lack here?

There is a growing list of software that which has discontinued support for Windows 10 on the latest versions (or the Server versions thereof). I'm not sure if your example of running a ~16 year old version of SQL Server on Server 2016 demonstrates.

To my original post - if you only need to run an old version of a software package, then an old version of Windows is fine. Just because something is old, it doesn't mean that it is not useful.

That's an interesting data point. I wonder if there is a hard technical reason why that logic could not be added to WINE, or if the WINE maintainers made a decision not to implement similar functionality.

That's (part of) my point. A project like ReactOS which clones Windows down to the kernel level solves for a very small set of practical use cases which are not covered by real Windows, or Linux+WINE.

It's worth noting that 30 years ago, there was a definite advantage to an open source operating system which could reuse proprietary Windows drivers - even Linux had a mechanism for using Windows drivers for certain types of hardware. Nowadays, Linux provides excellent support for modern PC hardware with little to no tinkering required in most cases. I have seen many cases where Linux provided full support out-of-the-box for a computer, whereas Windows required drivers to be downloaded and installed.

Yes, exactly my point - thanks for elaborating on it.

I would like to see ReactOS succeed for various reasons, mainly philosophical. On the other hand, for practical real-world use cases, it has to compete with several alternative solutions:

1. Just use Windows 11. Yes, it sucks and MS occasionally breaks stuff - but at least hardware and software vendors will develop their code against Win 11 and test it. In other words, you have the highest likelihood that your computer will work as expected with contemporary Windows applications and drivers.

2. Use an older version of Windows. If you want to use old hardware or software, odds are you will get the best experience with whatever version of Windows they were developed/tested against. You have to accept the lack of support for modern software, and you will need to take appropriate security measures such as not connecting it to the internet - but at the same time, it's unlikely that your Windows 98 retro gaming rig is your only computer, so that's probably an acceptable tradeoff.

3. Run WINE on top of Linux (or some other mature open source operating system). This might not be a good solution for the average person, but ticks the box for people who feel strongly pro-open source, or anti-Microsoft. Since Windows compatibility is dictated by Windows' libraries and frameworks and not the kernel, compatibility is likely to be comparable to ReactOS.

I am not saying that this covers every possible use case for ReactOS, but I would posit it covers enough that the majority of people who might contribute or invest into ReactOS will instead pick one of the above options and invest their time and energy elsewhere.

If MS abandons WinNT, then people will likely continue to use the existing versions of Windows which are out there for any existing software (just as people continue to use MS-DOS and Win 9x for old games and software).

As for new software - I think it's open to debate just how much new Win32 software will be created after a hypothetical abandonment by Microsoft of Windows.

We might have to agree to disagree here, but I think the scenario where the IT guy uses XP and "finds" a license for it is the approach I would take if I was put in this situation. If the vendor for the CNC machine certified/tested their machine against Windows XP, and does not offer any support for new operating systems, I would be very reluctant to use anything else - whether it is another version of Windows which could accept the same drivers, or an open source clone. Again, I'm assuming that ReactOS manages to be a perfect clone, which is may or may not be in practice.

> That's much more relevant to industrial applications where some device is controlled by an ancient computer because the vendor originally provided drivers for NT 5.0 or 5.1 which don't work on anything modern.

In most of those applications, you just leave the computer be and don't touch it. In some cases (especially medical devices) you may not even be allowed to touch it for legal/compliance reasons. If the hardware dies, you most likely find the exact same machine (or something equivalent) and run the same OS - there are many scenarios where replacing the computer with something modern is not viable (lack of the correct I/O interfaces, computer is too fast, etc.)

If there were software bugs which could impact operations, they probably would have arisen during the first few years when there was a support contract. As for security issues - you lock down access and disconnect from any network with public internet access.

All that assumes that ReactOS is a perfect drop-in replacement for whatever version of Windows you are replacing, and that is probably not a good assumption.

As someone who generally uses metric units, but grew up around English Imperial units - if an American says that a person weighs a certain number of pounds, I need to convert to stone and pounds in my head in order to get a meaningful mental model of how much that person weighs.

It was originally created as a CDE clone (thus the original name "XForms Common Environment")

> Use Claude Code if you

> a) never plan on learning and just care about outputs, or

> b) are an abstraction maximilist.

As a Claude Code user for about 6 months, I don't identify with either of these categories. Personally I switched to Claude Code because I don't particularly enjoy VScode (or forks thereof). I got used to a two window workflow - Claude Code for AI-driven development, and Goland for making manual edits to the codebase. As of a few months ago, Claude Code can show diffs in Goland, making my workflow even smoother.

After reading this article, it is unclear to me what "The Myth of the Thinkpad" is. The author laid out a series of desirable attributes about Thinkpads, and proceeds to explain how they are all true. We are reminded that all these desirable qualities arise from business realities, which is generally true for any desirable attribute in a commercially successful product. In the end, there's a conclusion that Thinkpads are a good choice, but that they are not "magic", as if this was something that needed explanation.

> May be better with a native PCI-e or PCI HBA and 700W power supply and a junker ATX Linux machine to provide network shares.

Agreed. Even if it's possible to get a combination of adapters to allow a SCSI interface to be attached to a Mac (and assuming the correct driver support is present), I think getting an old PC and an old SCSI adapter card may be cheaper.

Looking at "scsi to usb" on amazon.com, most of the options I see are SATA, IDE or even parallel printer port adapters, but nothing which allows a SCSI device to be connected to a USB port.

That's fair, and I suspect that if I either A) had a different hardware configuration at the time or B) had tried Vista about a year later than I did, I may have ended up with an entirely different opinion of it.