I saw this on Mastodon first and figured “well, I’m sure it’s nothing more than being able to run some basic Windows apps”, but no, I was shocked to learn that they got games up to AAA level running.
Of NetBSD and OpenBSD (since FreeBSD already can run Steam using its “linuxulator”), I much rather would’ve assumed NetBSD would get anything similar, with how particular OBSD is about security and whatnot.
I hope these efforts might cross-pollinate, it’d be fun to one day run NetBSD as a full (in the sense of able to do everything Linux today can) desktop OS.
Note that some bits of WINE really want custom support in the kernel. The implementation of WaitForMultipleObjects comes to mind. Linux and FreeBSD (not sure about macOS?) have custom kernel APIs specifically to make this efficient.
Anyone who has ever implemented a cross-platform “WaitForMultiple” that is inspired by Windows knows how incredibly cursed this is and how hard it is to get robust and right. I once had the (dis)pleasue of maintaining such a cross-platform API that supported Windows, Linux, QNX, FreeRTOS, MQX and Micrium OS. The Windows implementation of that part of the library was basically just a wrapper, but the other operating systems… Oh boy.
Unfortunately, I don’t have time to explain it in great detail, also it may contain some details of proprietary projects. Basically it was a library that provided:
Threading
Mutexes
Events
File system (including RAM file system)
Network communication
Logging
to Windows, Linux, QNX, FreeRTOS, MQX and Micrium OS. The exact same API providing all this functionality from machines ranging from desktop computer to embedded CPU with 1MB of on-chip RAM. Meaning all the code built on top of this library could be shared and identical between all these systems and architectures. And they all could communicate with each other with the same proprietary protocol that supported connections via:
Serial
USB
EtherCAT
TCP/IP
Bluetooth
It was pretty glorious. Despite the difficulties, I miss the elegance of this abstraction. Unfortunately, almost all the engineers who understood the elegance of it and how the entire thing works have left the company by now, so I guess future projects will have a gajillion different proprietary protocols again and all the implementations will be duplicated tenfold.
I hope these efforts might cross-pollinate, it’d be fun to one day run NetBSD as a full (in the sense of able to do everything Linux today can) desktop OS.
I used NetBSD as my main (and only) OS for over a decade, throughout college and even at work. I only stopped using it about 8 years ago because I got tired of dealing with some issues in pkgsrc. Of course, I didn’t care about Wine and Docker didn’t exist yet. It has a low-cost Linux syscall compatibility layer, so it is even possible to run Linux binaries if you must, but I don’t know how up-to-date it is.
Oh sure, that’s why I included the parts between the parentheses. I’ve heard multiple accounts that NetBSD can be used as a desktop OS, but most of them had an asterisk after them (in the sense of some important program being missing or something not working or simply being prohibitively slow), so I wanted to quantify what exactly a “full desktop OS” would mean for me.
It has a low-cost Linux syscall compatibility layer, so it is even possible to run Linux binaries if you must, but I don’t know how up-to-date it is.
As far as I understand, from reading others’ experiences it’s only a subset of calls and doesn’t support stuff like futexes and other modern kernel APIs, because that’d require more than simply mapping.
I got tired of dealing with some issues in pkgsrc
I’m curious, could you please elaborate what sort of issues you had? (I’m aware of what ports/pkgsrc is.)
At the time (don’t know if this is better now), pkgsrc had quarterly snapshots from which binaries were built and made available. When a vulnerability was found in a package, the corresponding binary would be removed from FTP. This led to the unfortunate case that one would have to recompile the package from source. And if it was a lower-level dependency like, say, libpng, this would cause a cascade of recompilations of everything and the kitchen sink (e.g. Emacs, Firefox, etc) leading to hours of recompiling.
Because you’d want to recompile a non-vulnerable version, you’d be compiling from CVS HEAD, which often meant there’d often be more (unrelated) breakage, so you wouldn’t even be able to continue.
And of course, my system would often be unusable because I wouldn’t have the package installed until the recompilation was done.
And sometimes, the binaries were unavailable because the package was broken or something else went wrong, so one would have to compile a package from source once in a while.
I saw this on Mastodon first and figured “well, I’m sure it’s nothing more than being able to run some basic Windows apps”, but no, I was shocked to learn that they got games up to AAA level running.
Of NetBSD and OpenBSD (since FreeBSD already can run Steam using its “linuxulator”), I much rather would’ve assumed NetBSD would get anything similar, with how particular OBSD is about security and whatnot.
I hope these efforts might cross-pollinate, it’d be fun to one day run NetBSD as a full (in the sense of able to do everything Linux today can) desktop OS.
score 3 · canonical
Steam’s linux gaming support is built on wine, so assuming a complete port of wine you’d get all of that
score 1 · canonical
Note that some bits of WINE really want custom support in the kernel. The implementation of
WaitForMultipleObjectscomes to mind. Linux and FreeBSD (not sure about macOS?) have custom kernel APIs specifically to make this efficient.score 1 · canonical
Anyone who has ever implemented a cross-platform “WaitForMultiple” that is inspired by Windows knows how incredibly cursed this is and how hard it is to get robust and right. I once had the (dis)pleasue of maintaining such a cross-platform API that supported Windows, Linux, QNX, FreeRTOS, MQX and Micrium OS. The Windows implementation of that part of the library was basically just a wrapper, but the other operating systems… Oh boy.
score 1 · canonical
You have any more details about this? Sounds like an interesting story!
score 1 · canonical
Unfortunately, I don’t have time to explain it in great detail, also it may contain some details of proprietary projects. Basically it was a library that provided:
to Windows, Linux, QNX, FreeRTOS, MQX and Micrium OS. The exact same API providing all this functionality from machines ranging from desktop computer to embedded CPU with 1MB of on-chip RAM. Meaning all the code built on top of this library could be shared and identical between all these systems and architectures. And they all could communicate with each other with the same proprietary protocol that supported connections via:
It was pretty glorious. Despite the difficulties, I miss the elegance of this abstraction. Unfortunately, almost all the engineers who understood the elegance of it and how the entire thing works have left the company by now, so I guess future projects will have a gajillion different proprietary protocols again and all the implementations will be duplicated tenfold.
score 1 · canonical
I used NetBSD as my main (and only) OS for over a decade, throughout college and even at work. I only stopped using it about 8 years ago because I got tired of dealing with some issues in pkgsrc. Of course, I didn’t care about Wine and Docker didn’t exist yet. It has a low-cost Linux syscall compatibility layer, so it is even possible to run Linux binaries if you must, but I don’t know how up-to-date it is.
score 1 · canonical
Oh sure, that’s why I included the parts between the parentheses. I’ve heard multiple accounts that NetBSD can be used as a desktop OS, but most of them had an asterisk after them (in the sense of some important program being missing or something not working or simply being prohibitively slow), so I wanted to quantify what exactly a “full desktop OS” would mean for me.
As far as I understand, from reading others’ experiences it’s only a subset of calls and doesn’t support stuff like futexes and other modern kernel APIs, because that’d require more than simply mapping.
I’m curious, could you please elaborate what sort of issues you had? (I’m aware of what ports/pkgsrc is.)
score 2 · canonical
At the time (don’t know if this is better now), pkgsrc had quarterly snapshots from which binaries were built and made available. When a vulnerability was found in a package, the corresponding binary would be removed from FTP. This led to the unfortunate case that one would have to recompile the package from source. And if it was a lower-level dependency like, say, libpng, this would cause a cascade of recompilations of everything and the kitchen sink (e.g. Emacs, Firefox, etc) leading to hours of recompiling.
Because you’d want to recompile a non-vulnerable version, you’d be compiling from CVS HEAD, which often meant there’d often be more (unrelated) breakage, so you wouldn’t even be able to continue.
And of course, my system would often be unusable because I wouldn’t have the package installed until the recompilation was done.
And sometimes, the binaries were unavailable because the package was broken or something else went wrong, so one would have to compile a package from source once in a while.
score 2 · canonical