I find the drive letter thing amusing... since Unix did it that way long before DOS even existed!

Mint is my go-to Linux of choice, but it's not perfect.

I've been using basically every OS under the Sun for years, and I'm currently rotating between Win98/Win10/Mint/OSX. Mint is really just usable for most workloads today. Aside from games working fine with Proton or Wine (I've played even Cyberpunk 2077 under it with slightly better performance than natively under Windows 10), it's somewhat slowly been getting support for more "serious" applications. The newest Photoshop that I can run without an error under Mint is PS2018; newer stuff just breaks in nasty ways. As long as things like Adobe software remain the industry standard, it'll be hard to switch away from at least dualbooting Windows. That to me is a bigger problem than just the drive letter/number confusion

You can install up to date Wine for Mint. There's an instruction for Ubuntu/Debian on the Wine site. Although there are newer ways to run some Windows applications.

Can you have auto-changing per-monitor desktop background on Cinammon like on KDE?

I've no idea if I should try another distro or go for newer KUbuntu at some point. Plus my PC is just becoming more retro with time. AMD Phenom II X4 920, NVIDIA GeForce GTX 750 Ti, 6 GB DDR2 RAM.

Slightly off-topic, but since it was mentioned before...

Rufus' option to setup Win11 installation media without MS account requirement still functions for 25H2. But, if you reboot during OOBE and don't finish it, the OOBE will want you to setup MS account afterwards. New way to get around that that works on 25H2, when you arrive on OOBE screen, SHIFT + F10 to open CMD, then type "start ms-cxh:localonly" (without quotes) and confirm. An app window will open, prompting for desired user name and password, after confirmation, it will set it up and log you on.

Just tested today since I had to setup once PC at work from scratch.

^Hi, thanks for the information! That's good to know! ^^

Kerr Avon wrote on 2025-10-12, 18:38:

God Of Gaming wrote on 2025-10-12, 08:22:

Mount points / drive letters are such a minor thing that I don't even see how it's an issue.

It's an issue to those new to Linux, because it's a change to something so basic, and the Linux way isn't intuitive to someone new to it. As I said, probably the Linux way is better, but why not also include Windows' way as a secondary method, to help ease people migrating from Windows use?

Hi! Actually, Windows NT uses device names internally for mass storage devices.
Windows 9x was the last line to use drive letters natively, I think.
Not sure about OS/2 Warp, though. It's strange, like an inbetween of Windows 95 and NT 4 in several ways.

https://superuser.com/questions/465730/access … tter-in-windows

https://plugable.com/blogs/news/throwback-lin … ows-nt-and-os-2

Jo22 wrote on 2025-10-10, 14:36:

But really, I'm still confused by the pro Win10/anti Win11 thinking on the internet. 🤔
They're basically same under the hood, like Vista/7 or 8/8.1.

I'd say newer is more practical in terms of newer software compatibility. I guess it comes to balancing good and bad parts and I suppose we try to hold on to a slightly older version until it works for us.

There are differences in number of places.

Today I tried to use Performance profiler in Visual Studio 2022 on work laptop, it runs older Win10 1809. VS 2022 is not officially supported on that version and installs with a warning. Regarding profiler, it gave an error that it couldn't be started and should try repair install.

After spending some time searching, I found that someone experiencing the same issue posted the log (logging is enabled through special registry setting) on one of Microsoft's discussions channels, the log said it failed to enable some security mitigation called RedirectionGuard. The person from Microsoft wrote it happens on unsupported Windows versions.

That gave me an idea, I opened .exe file of Visual Studio Standard Collector Service 150 (it fails to start, so profiler doesn't work) with x64dbg and looked for an error string from the log. Found it, nearby, I saw conditional jump instruction that is taken after mitigation is successfully enabled through an API call where it outputs success message and continues. I changed the jump so it always jumps and saved the patched file while keeping a copy of original.

Not expecting much, profiler actually started on first try.

So there can be all sorts of dependencies and these things tend to fail completely if something minor is not as expected.

UCyborg wrote on 2025-10-14, 10:27:

New way to get around that that works on 25H2, when you arrive on OOBE screen, SHIFT + F10 to open CMD, then type "start ms-cxh:localonly" (without quotes) and confirm. An app window will open, prompting for desired user name and password, after confirmation, it will set it up and log you on.

Just tested today since I had to setup once PC at work from scratch.

Make sure to keep the .ISO you used to do that, because it was just all over the tech news in the past week that Microsoft removed that loop hole from the Windows 11 installer, or they are in the process of doing so.

https://www.windowslatest.com/2025/10/07/micr … ng-oobe-tested/

Also, one thing that no one mentions is that there is a completely ridiculous privacy issue with using a local account on Windows 10\11. If you download apps in the Microsoft store with a local account, they will forever show up in the MS Store "Library" of *any* Windows account and *any* Windows 10\11 installation on *any* drive used on that motherboard\system, with no way to remove them. They say it is for the convenience of the user who owns the computer, but if you can remove the SSD and burn it in a fire, put a new SSD in the system and install Windows fresh and there is still a record of those apps being on the computer, I call that a privacy issue. It's possible that using a new Windows license key at install may work around this, but I'm not 100% sure.

So yeah, good times.

MS is out of control. Now may be a good time to fix Linux? Or ReactOS. 😉 Maybe in another reality.

Seriously though, all this on top that Windows licenses are still sold for the usual price.

UCyborg wrote on 2025-10-14, 19:15:

MS is out of control. Now may be a good time to fix Linux? Or ReactOS. 😉 Maybe in another reality.

Seriously though, all this on top that Windows licenses are still sold for the usual price.

Though, to be fair, some people have been buying Windows licenses for almost nothing on CD key sites or eBay for the entire life of Windows 8 and 10. Microsoft never seemed to be able to shut that down... most likely because they knew that more Windows activations means more guaranteed products... err... CUSTOMERS... I mean. Customers. More guaranteed customers...

It's really too bad. I am such a stickler for how my computer looks and operates. My Windows 10 system is so finely tuned and tweaked to how I want it to work... I cannot even imagine how long it'd take me to get to that point with Linux. Also, when there are issues, I work on them and research them until they are fixed. With Windows 10, I no longer have any issues. I have helped to fix or make workarounds for some very irritating issues (some of which I take time to document online).

Out of curiosity I have looked up whether Linux has similar issues, and what I find is that it probably doesn't... because the feature that needs fixed doesn't even exist in a well supported and functional form outside of Windows. And I use that feature.

I am planning to install Mint or if SteamOS is ever released, I will put that on an SSD to play with. But I highly doubt that I'd be able to switch to Linux any time soon.

I regularly use my main PC as a go-between for retro systems, I play obscure, often old games, I run some very old (almost 25 years old) programs regularly because that is what I like to use for a given task. And I run modern games and modern software that I expect to work to it's full potential while having full, detailed control of my PC's hardware (fans, undervolting, etc.). If every one of these things is possible on Linux with no compromises, it may be worth spending the time to fully switch. If any one of them isn't, it isn't worth it for me.

I check on the status of ReactOS every few years though... 🤣

UCyborg wrote on 2025-10-14, 19:15:

MS is out of control. Now may be a good time to fix Linux? Or ReactOS. 😉 Maybe in another reality.

Seriously though, all this on top that Windows licenses are still sold for the usual price.

All jokes aside, ReactOS is functional. 😃

It already was in 2012, when I ran an older version of MS Office and Visual Basic 5/6 on it. And shareware games/freeware utilities. And Firefox/IE5.
Most of my ham radio applications ran on ReactOS at the time, too.
That was a time in which Windows XP still was in wide use.

The main problem are missing drivers and 64-Bit support, I think.
Installing drivers brings back memories of Windows NT 4 times..
But the foundation is already built. Experimental 64-Bit support is being worked on, too.
An 32-Bit compatibility layer like WoW64 is still missing, though, I vaguely remember.

Unfortunately, the ReactOS Team is small and doesn't have the resources of other projects.
It's very niche, so to say. Haiku OS is still behind schedule, too, for similar reasons, I suppose.

Anyhow. The misconception is, I think, that people think that ReactOS
is years behind current Windows versions and thus must be hopelessly outdated.

But that's not that simple, I think, because ReactOS works in tandem with Wine project.
As Wine progresses, so does ReactOS.

Then there's. NET Framework, which many applications use. Or had used, not sure.
It's not directly part of Win32/Win64 API and can be implemented using Mono project.

It could be that ReactOS might catch up reasonably in the not so far future.
Especially if Windows nolonger adds new APIs but focuses on other things.

Of course, it won't replace Windows on the high-end gaming side.
3D engines and graphics APIs and graphics drivers are a mess with lots of hacks, workarounds etc.

But it can serve as an embedded-OS, to run office software, to play strategy games such as Anno, Sim City, and some FPS games too.
Especially if they have fallback to OpenGL, older DirectX such as Direct3D 8/9..

ReactOS is like Linux here. It's not a replacement to Windows, but rather an alternative.
Some things already work for years on ReactOS.

It could be used in an retro internet café, for example, to avoid issues with Windows licenses.
Or in a school lab, to run old control software for Lego robots or something.
Things like this..

PS: I can understand if my long posting reads like a boring lament..
I don’t mean to spoil the fun, either. I know that ReactOS is sort of an internet meme, too. And that's okay.
But ReactOS also has possibilities and it means freedom.

Those of us who grew up with Windows now have their own classic Windows that MS can't take away from them.
Also from a legal point of view, I mean. We can install ReactOS everywhere, openly, without being afraid of violating any rules.

Like in a local library of a small town, maybe.
Or as a safe, lightweight Windows substitute running in an embedded application.
ReactOS won't phone home, so it's great for any industrial machine running in a network, for example.

It's similar to FreeDOS here, I think. Most of us prefer using MS-DOS, I think, but having the option to use FreeDOS or its modern utilities is cool!

a bare debian on xfce4(chicago95 or xptc) + wine can probably do windows better than reactos can at this rate. Every time i've tried reactos it'd either hard lock, feel barren or bsod hard, real or virtual; so it's crap advice to suggest that to replace 10, especially as Steam doesn't support that (steam is still a major factor in keeping windows for many).
The only benefit i've had from reactos had been their winsock2 header allowing for win95 compiles in mingw32, eliminating that microsoft DDK dependency.

I was never lucky getting ReactOS running. It's far too Alpha or my retro boxes are too special. Besides that, FreeDOS 1.4 is absolutely rocket stable. I use it on every retro Box and I am missing nothing. No reason for me to use something propitary here.

Kerr Avon wrote on 2025-10-12, 18:38:

Maybe, but it's more complicated than in Windows. If I install (or boot with a live CD) Linux to my PC, then to access, say, my E: drive, I then have to somehow find out what /dev/SDA does, and what number my E: hard drive is. Granted, it's probably not too difficult to do so, but why not just allow Linux to also refer to /dev/SDA3 (or whatever it is) as E: ? It wouldn't be difficult to implement in Linux, surely? And it would make the first exposure to Linux a little less confusing.

It is not actually more complicated but just two imposed 'schemes' where just one feels familiar to you.

The Unix root hierarchy is much older than single letter disk labels. The Microsoft way imposes a correlation between labeling and physical layout hierarchy. Unix does not.

E.g. E: does actually denote a 'drive number'. C: is the active partition on the primary hard drive. E: will be the third 'understood' partition from Windows per BIOS drive sequence.

Using position/layout to map the filesystem has been passe for the last two or three decades. There are a multitude of better ways, for example FreeBSD today will give you /dev/ entry for each physical hard drive per its product it, such as /dev/WDC912039-BLABLA/p3

However I think the problem you have is using system-administrative mounting for desktop which is not the way to go. The desktop stuff should be mounted by userspace automounters and preferably via FUSE. If all that sounds complicated, note that KDE Plasma does it out of the box. You will see all your non-system-mounted partitions, fixed and removable, in the left pane of Dolphin FM. You can click to mount/dismount them. They will appear as special folder in Dolphin; automounted through userspace to /media/ point (depends on distro/config).

So either you
A) want to know exactly what's where and who it belongs to - use all available mechanisms for numbering, labeling, GUIDs, to manually setup everything
B) don't care, treating it as dumb storage - use desktop environment for seamless access.

The power of Unix is giving options A and B to the user (sometimes even more of them). Windows for the most part gives you B (I'm not a basher, I'm a Windows user too).

On my FreeBSD I use both ways; I have number of drives in a manually configured hierarchy both under UFS and ZFS. And I have Windows drives and USB stuff that I don't taint the system with, but just use the desktop mounter in KDE Plasma.

zb10948 wrote on Yesterday, 13:40:

It is not actually more complicated but just two imposed 'schemes' where just one feels familiar to you. […]
Show full quote

Kerr Avon wrote on 2025-10-12, 18:38:

Maybe, but it's more complicated than in Windows. If I install (or boot with a live CD) Linux to my PC, then to access, say, my E: drive, I then have to somehow find out what /dev/SDA does, and what number my E: hard drive is. Granted, it's probably not too difficult to do so, but why not just allow Linux to also refer to /dev/SDA3 (or whatever it is) as E: ? It wouldn't be difficult to implement in Linux, surely? And it would make the first exposure to Linux a little less confusing.

It is not actually more complicated but just two imposed 'schemes' where just one feels familiar to you.

The Unix root hierarchy is much older than single letter disk labels. The Microsoft way imposes a correlation between labeling and physical layout hierarchy. Unix does not.

E.g. E: does actually denote a 'drive number'. C: is the active partition on the primary hard drive. E: will be the third 'understood' partition from Windows per BIOS drive sequence.

Using position/layout to map the filesystem has been passe for the last two or three decades. There are a multitude of better ways, for example FreeBSD today will give you /dev/ entry for each physical hard drive per its product it, such as /dev/WDC912039-BLABLA/p3

However I think the problem you have is using system-administrative mounting for desktop which is not the way to go. The desktop stuff should be mounted by userspace automounters and preferably via FUSE. If all that sounds complicated, note that KDE Plasma does it out of the box. You will see all your non-system-mounted partitions, fixed and removable, in the left pane of Dolphin FM. You can click to mount/dismount them. They will appear as special folder in Dolphin; automounted through userspace to /media/ point (depends on distro/config).

So either you
A) want to know exactly what's where and who it belongs to - use all available mechanisms for numbering, labeling, GUIDs, to manually setup everything
B) don't care, treating it as dumb storage - use desktop environment for seamless access.

The power of Unix is giving options A and B to the user (sometimes even more of them). Windows for the most part gives you B (I'm not a basher, I'm a Windows user too).

On my FreeBSD I use both ways; I have number of drives in a manually configured hierarchy both under UFS and ZFS. And I have Windows drives and USB stuff that I don't taint the system with, but just use the desktop mounter in KDE Plasma.

The thing I struggle with is also what some may consider the strengths of Linux\Unix. As you said above, there are so many different ways to do things as simple as organizing data, but that can be quite overwhelming, and it changes from distro to distro, maybe from version to version of that distro and even from person to person based on preferences. And the lack of unification in this regard makes everything far more complicated once you want to take that first step past what is visible on the desktop. I could talk to a person who has been using Linux for 30 years who knows how to navigate the command line the same as any Linux user, but may have absolutely no clue about some of the things you've mentioned (FUSE, KDE Plasma, Dolphin FM, etc.) because they've used completely different distros or features all that time. There is nothing wrong with this, and it's cool that the options exist, it just makes it that much harder to learn since each separate pool of people (and comments already existing online to help solve issues) is relatively tiny for any particular situation, compared to Windows.

In contrast, someone can boot up a PC 5150 with DOS 3.3 and know that if there's a functioning hard drive in the PC, you type "c:", and anything you do from there is now related to the contents of that physical piece of hardware. If you pull the drive out of the computer, the contents of C: are gone, and all of the software on the computer is contained on C: because it physically is contained there. You cannot navigate to anything outside of a drive because there is nothing stored outside of drives.

If there is a floppy it is A: or B: usually (except for those oddball 4x floppy drive situations!). And any additional drives are going to be the D:, E:, ect.. Nothing in the file manager\explorer exists outside of them and if you pull a drive the PC, the drive letter is now gone. Moving to Windows 95 from DOS is a huge change visually, but the fundamentals of where things exist on the PC are still there. Of course, all of this is just what I am used to and what makes sense to me since I am very hardware oriented with regard to computers.

However, the point is that I can do this same thing on my Windows 10 PC, built 30-40 years later. I can attach a USB floppy drive and it is A:. My OS is installed on C:. I have two partitions on one physical drive, so they are C: and D:, but that is about the extent of the complications there.

It doesn't matter whether I'm on DOS 3.3, Windows 95 or Windows 10\11, FAT12, FAT16, FAT32, NTFS or ExFAT , the file system shows me what is on the computer in a way that makes sense from a physical standpoint (hard drive is inside PC, files are on hard drive), and the command prompt and File Explorer allow me to navigate the system in basically the same way across that entire span of time.

I have dabbled in Linux-derived things by tinkering with and rooting Android devices for close to 14 years now (my first Android device was an HP Touchpad flashed with Cyanogenmod Android back in 2011), but I still find navigating the file system so obscure and confusing compared to DOS or Windows. Would I want full fat Windows on my cell phone? Absolutely not... there's too many things that could change or happen when I just need it to be a phone. I also have almost completely stopped digging deep into mobile devices in the past 2 years aside from running a few apps, browsing the web and taking pictures. It just isn't an environment I like to work in.

All that said. I am planning to try to branch out a bit with Linux at some point soon. I'll throw it on a spare SSD and insert it into my SATA dock to boot from it when I want to tinker. I am not against learning new things, and I hope that I will gradually become more familiar with Linux since it will probably be more common over time... but I am very much set in my ways after all these years. 😁

Ozzuneoj wrote on Yesterday, 19:53:

The thing I struggle with is also what some may consider the strengths of Linux\Unix. As you said above, there are so many diffe […]
Show full quote

zb10948 wrote on Yesterday, 13:40:

It is not actually more complicated but just two imposed 'schemes' where just one feels familiar to you. […]
Show full quote

Kerr Avon wrote on 2025-10-12, 18:38:

Maybe, but it's more complicated than in Windows. If I install (or boot with a live CD) Linux to my PC, then to access, say, my E: drive, I then have to somehow find out what /dev/SDA does, and what number my E: hard drive is. Granted, it's probably not too difficult to do so, but why not just allow Linux to also refer to /dev/SDA3 (or whatever it is) as E: ? It wouldn't be difficult to implement in Linux, surely? And it would make the first exposure to Linux a little less confusing.

It is not actually more complicated but just two imposed 'schemes' where just one feels familiar to you.

The Unix root hierarchy is much older than single letter disk labels. The Microsoft way imposes a correlation between labeling and physical layout hierarchy. Unix does not.

E.g. E: does actually denote a 'drive number'. C: is the active partition on the primary hard drive. E: will be the third 'understood' partition from Windows per BIOS drive sequence.

Using position/layout to map the filesystem has been passe for the last two or three decades. There are a multitude of better ways, for example FreeBSD today will give you /dev/ entry for each physical hard drive per its product it, such as /dev/WDC912039-BLABLA/p3

However I think the problem you have is using system-administrative mounting for desktop which is not the way to go. The desktop stuff should be mounted by userspace automounters and preferably via FUSE. If all that sounds complicated, note that KDE Plasma does it out of the box. You will see all your non-system-mounted partitions, fixed and removable, in the left pane of Dolphin FM. You can click to mount/dismount them. They will appear as special folder in Dolphin; automounted through userspace to /media/ point (depends on distro/config).

So either you
A) want to know exactly what's where and who it belongs to - use all available mechanisms for numbering, labeling, GUIDs, to manually setup everything
B) don't care, treating it as dumb storage - use desktop environment for seamless access.

The power of Unix is giving options A and B to the user (sometimes even more of them). Windows for the most part gives you B (I'm not a basher, I'm a Windows user too).

On my FreeBSD I use both ways; I have number of drives in a manually configured hierarchy both under UFS and ZFS. And I have Windows drives and USB stuff that I don't taint the system with, but just use the desktop mounter in KDE Plasma.

The thing I struggle with is also what some may consider the strengths of Linux\Unix. As you said above, there are so many different ways to do things as simple as organizing data, but that can be quite overwhelming, and it changes from distro to distro, maybe from version to version of that distro and even from person to person based on preferences. And the lack of unification in this regard makes everything far more complicated once you want to take that first step past what is visible on the desktop. I could talk to a person who has been using Linux for 30 years who knows how to navigate the command line the same as any Linux user, but may have absolutely no clue about some of the things you've mentioned (FUSE, KDE Plasma, Dolphin FM, etc.) because they've used completely different distros or features all that time. There is nothing wrong with this, and it's cool that the options exist, it just makes it that much harder to learn since each separate pool of people (and comments already existing online to help solve issues) is relatively tiny for any particular situation, compared to Windows.

In contrast, someone can boot up a PC 5150 with DOS 3.3 and know that if there's a functioning hard drive in the PC, you type "c:", and anything you do from there is now related to the contents of that physical piece of hardware. If you pull the drive out of the computer, the contents of C: are gone, and all of the software on the computer is contained on C: because it physically is contained there. You cannot navigate to anything outside of a drive because there is nothing stored outside of drives.

If there is a floppy it is A: or B: usually (except for those oddball 4x floppy drive situations!). And any additional drives are going to be the D:, E:, ect.. Nothing in the file manager\explorer exists outside of them and if you pull a drive the PC, the drive letter is now gone. Moving to Windows 95 from DOS is a huge change visually, but the fundamentals of where things exist on the PC are still there. Of course, all of this is just what I am used to and what makes sense to me since I am very hardware oriented with regard to computers.

However, the point is that I can do this same thing on my Windows 10 PC, built 30-40 years later. I can attach a USB floppy drive and it is A:. My OS is installed on C:. I have two partitions on one physical drive, so they are C: and D:, but that is about the extent of the complications there.

It doesn't matter whether I'm on DOS 3.3, Windows 95 or Windows 10\11, FAT12, FAT16, FAT32, NTFS or ExFAT , the file system shows me what is on the computer in a way that makes sense from a physical standpoint (hard drive is inside PC, files are on hard drive), and the command prompt and File Explorer allow me to navigate the system in basically the same way across that entire span of time.

I have dabbled in Linux-derived things by tinkering with and rooting Android devices for close to 14 years now (my first Android device was an HP Touchpad flashed with Cyanogenmod Android back in 2011), but I still find navigating the file system so obscure and confusing compared to DOS or Windows. Would I want full fat Windows on my cell phone? Absolutely not... there's too many things that could change or happen when I just need it to be a phone. I also have almost completely stopped digging deep into mobile devices in the past 2 years aside from running a few apps, browsing the web and taking pictures. It just isn't an environment I like to work in.

All that said. I am planning to try to branch out a bit with Linux at some point soon. I'll throw it on a spare SSD and insert it into my SATA dock to boot from it when I want to tinker. I am not against learning new things, and I hope that I will gradually become more familiar with Linux since it will probably be more common over time... but I am very much set in my ways after all these years. 😁

Listen, I literally never touched Linux until the beginning of this year, when I installed Linux Mint. I don't know what exactly Linux Mint has done, but I swear they've made it so that when I start typing the windows version of some system setting app "Drive Manager" for example, it knows what I'm looking for and suggest the "Disk" Linux App. It took me literally 10 seconds of just trying to find that app, open it up, and fiddle with where my drives were mounted.

I repeat, I'd never used Linux before ever.

This is such a peculiar thing to get hung up on.

Jo22 wrote on Yesterday, 11:19:

Unfortunately, the ReactOS Team is small and doesn't have the resources of other projects.
It's very niche, so to say. Haiku OS is still behind schedule, too, for similar reasons, I suppose.

I think present day Haiku OS takes a good amount of drivers from FreeBSD so devices already working well in FreeBSD should work on Haiku also.

It's constantly improving. If stable releases aren't working as expected you can always try nightly.

So far the only issue is graphics. Some older generation AMD video cards are supported with acceleration, while nVidia support is mostly nonexistent and has to rely on default VESA driver. As for audio and networking, most onboard audio and common network adapters should work fine.

AncapDude wrote on Yesterday, 13:23:

I was never lucky getting ReactOS running. It's far too Alpha or my retro boxes are too special. Besides that, FreeDOS 1.4 is absolutely rocket stable. I use it on every retro Box and I am missing nothing. No reason for me to use something propitary here.

I think ReactOS is still lacking on supporting advanced CPU and memory related stuffs. Not too long ago I took a nightly build to check out the progresses on aspects such as SMP using a VirtualBox VM and no, it was far from ready. Installation went fine but as soon as it tries to boot the installed ReactOS instance the VM crashed with a Guru Meditation.

Guess it's still going to be a while before it can be booted on most if not all hardware configurations without serious compromises.

Namrok wrote on Yesterday, 20:10:

Listen, I literally never touched Linux until the beginning of this year, when I installed Linux Mint. I don't know what exactly Linux Mint has done, but I swear they've made it so that when I start typing the windows version of some system setting app "Drive Manager" for example, it knows what I'm looking for and suggest the "Disk" Linux App. It took me literally 10 seconds of just trying to find that app, open it up, and fiddle with where my drives were mounted.

I repeat, I'd never used Linux before ever.

This is such a peculiar thing to get hung up on.

Linux Mint was the first Linux distro I used actually as a daily driver. I've used both XFCE and Cinnamon flavors and they are very friendly to users coming from Windows. Both are good. Just that Cinnamon is better when it comes to GUI scaling (for HiDPI such as with 4K resolution).

At first I used it mainly to run some build scripts for stuffs that required a Linux environment. When Win10 just came out, my system hardware had a hard time getting working correctly so I switched back to Win7 for a short time then eventually started using Linux Mint as main.

After getting myself familiar with using Linux on Linux Mint, I've since switched to Arch-based distros for accessing more up-to-date software.

LSS10999 wrote on Today, 07:05:

I think present day Haiku OS takes a good amount of drivers from FreeBSD so devices already working well in FreeBSD should work […]
Show full quote

Jo22 wrote on Yesterday, 11:19:

Unfortunately, the ReactOS Team is small and doesn't have the resources of other projects.
It's very niche, so to say. Haiku OS is still behind schedule, too, for similar reasons, I suppose.

I think present day Haiku OS takes a good amount of drivers from FreeBSD so devices already working well in FreeBSD should work on Haiku also.

It's constantly improving. If stable releases aren't working as expected you can always try nightly.

So far the only issue is graphics. Some older generation AMD video cards are supported with acceleration, while nVidia support is mostly nonexistent and has to rely on default VESA driver. As for audio and networking, most onboard audio and common network adapters should work fine.

Traditionally, Linux has had issues with nVidia, too.
I vaguely remember it was related to open-source vs close-source driver policy.

LSS10999 wrote on Today, 07:05:

AncapDude wrote on Yesterday, 13:23:

I was never lucky getting ReactOS running. It's far too Alpha or my retro boxes are too special. Besides that, FreeDOS 1.4 is absolutely rocket stable. I use it on every retro Box and I am missing nothing. No reason for me to use something propitary here.

I think ReactOS is still lacking on supporting advanced CPU and memory related stuffs. Not too long ago I took a nightly build to check out the progresses on aspects such as SMP using a VirtualBox VM and no, it was far from ready. Installation went fine but as soon as it tries to boot the installed ReactOS instance the VM crashed with a Guru Meditation.

Guess it's still going to be a while before it can be booted on most if not all hardware configurations without serious compromises.

Hm. SMP seems to be functional in principle, at the very least.

https://www.theregister.com/2022/03/14/reactos_smp/

That being said, support for SMP and SIMDs or CPU power-savings features always had been the more tricky/more sophisticated things.

Linux when it was little, had issues with ACPI and APIC, for example.
I remember, how I had to add noapic noacpi on the kernal loader (boot=) about 20 years ago.

AncapDude wrote on Yesterday, 13:23:

I was never lucky getting ReactOS running. It's far too Alpha or my retro boxes are too special. Besides that, FreeDOS 1.4 is absolutely rocket stable. I use it on every retro Box and I am missing nothing. No reason for me to use something propitary here.

Hi, it depends how retro or how much industry-standard your retro boxes are.

These, um, "retro" OSes want "good" hardware, that follows industry standards.

The kind of traditional server or workstation hardware that could boot NT4 or OS/2 Warp without a hassle..

Something like a Pentium II/III motherboard with intel 440BX chipset.
Virtual PC 2004/2007 uses that, for example.

Or PIIX3 or ICH9 chipset, like VirtualBox does provide.

Or a generic 486 era PC/AT mainboard without any PCI slots, a pure ISA bus system.
QEMU supports this through the "ISA PC" setting.

These are the the kind of, um, "idealistic" edit: "idealised" reference hardware platforms these OSes are being developed on/for.

A random Dell PC from late 2000s or 2010s won't do it, thus.
Its on-board ATA controller or weird BIOS might not be compatible enough, even.

Especially SATA controllers are/were tricky, I think, because some mainboards supported IDE or legacy mode, some the normal AHCI mode, and some a native mode (nvidia nForce 6 comes to mind)..

Jo22 wrote on Today, 11:46:

Traditionally, Linux has had issues with nVidia, too.
I vaguely remember it was related to open-source vs close-source driver policy.

This still holds true today. Although nVidia did open the kernel modules, you must have at least a Turing to use them. Older cards still need the closed ones.

Some Linux distros such as Manjaro maintain their own nVidia driver packages against certain kernel versions so one don't have deal with all the hassles. Things can get complicated with outdated drivers meant for old EOL'd cards that are still relevant performance-wise, however.

Jo22 wrote on Today, 11:46:

Hm. SMP seems to be functional in principle, at the very least. […]
Show full quote

Hm. SMP seems to be functional in principle, at the very least.

The attachment rtos_smp.jpg is no longer available

https://www.theregister.com/2022/03/14/reactos_smp/

That being said, support for SMP and SIMDs or CPU power-savings features always had been the more tricky/more sophisticated things.

Linux when it was little, had issues with ACPI and APIC, for example.
I remember, how I had to add noapic noacpi on the kernal loader (boot=) about 20 years ago.

Maybe I should pick another build and give it a try. Don't know what might be the real reason behind the Guru Meditation I encountered. After all, nightly builds may or may not work depending on what has been changed.

Jo22 wrote on Today, 11:46:

Especially SATA controllers are/were tricky, I think, because some mainboards supported IDE or legacy mode, some the normal AHCI mode, and some a native mode (nvidia nForce 6 comes to mind)..

I think ReactOS mainly relies on UniATA, which supported a good amount of controllers. I once read some recent progresses on getting third-party drivers (meant for Windows) to work with ReactOS but not sure if other disk drivers (e.g. Intel or AMD AHCI drivers) can be used.

TBH I haven't really tested ReactOS much with real hardware at the moment. Will probably give it a try once third-party driver support is mature enough to get things like audio and networking usable, as well as disk controllers (so the instance can be installed and actually boot without getting a 0x7B bugcheck).