What do you think about a "SteamBSD" machine ?

[Espionage724]

.

 

[LibreQuest]

There's no reason not to make a SteamBSD machine. I have a lot of machines that run Steam and even the R1 Alienware Steam Machine. And it can play a large amount of my library. There are some that don't work however. Just post pictures when it's done. In my experience Nvidia and Radeon as well as Intel iGPU work well with Steam on FreeBSD. And both X11 and Wayland work well in Steam gaming on FreeBSD.

 

[ZioMario]

Steam's mainly useful to me for PCVR, and I'm thinking that might have more latency doing Proton/Wine -> Linuxlator -> FreeBSD

Otherwise if a game doesn't need Steam DRM or Proton-specific fixes, it's more fun to run SteamCMD and games through FreeBSD Wine

you gave me a great idea : "Don't fix the Linuxulator missing / broken syscalls if the game runs correctly with Wine. Try to run it with Wine and not with Steam Client"

 

[ZioMario]

There's no reason not to make a SteamBSD machine. I have a lot of machines that run Steam and even the R1 Alienware Steam Machine. And it can play a large amount of my library. There are some that don't work however. Just post pictures when it's done. In my experience Nvidia and Radeon as well as Intel iGPU work well with Steam on FreeBSD. And both X11 and Wayland work well in Steam gaming on FreeBSD.

Come on. Why Linux always comes first and FreeBSD should be the second choice when we talk about multimedia / video games ? Our is a nice OS,it should not be second to anyone in / for something.

 

[LibreQuest]

Come on. Why Linux always comes first and FreeBSD should be the second choice when we talk about multimedia / video games ? Our is a nice OS,it should not be second to anyone in / for something.

I would agree, other than the lack of some kernel modules for digital rights management things work very well in gaming. And for multimedia it's great as well. I think Valve should just find a way to work some FreeBSD into their software.

I have noticed that some games are working with the latest version of LSU that were not previously working. So, not sure why they're working now. But it's cool that they are.

 

[resora]

I have an idea that I would like to discuss with the BSD community.

My long-term goal is to create a non-profit organization, somewhat inspired by the Mozilla Foundation, focused specifically on improving software and hardware support across the BSD ecosystem.

The idea has several directions:

1. Porting software to BSD

There is a lot of useful software that does not support BSD, including both open-source and commercial applications. The organization could coordinate or fund ports of such software to FreeBSD and, where possible, other BSD systems.

Examples could include engineering and reverse-engineering software such as QBlade, Binary Ninja, and many other applications.

2. Hardware drivers and cooperation with manufacturers

Another important goal would be to help fund BSD driver development and negotiate directly with hardware manufacturers.

Sometimes the biggest problem is not writing the driver itself, but obtaining hardware documentation legally. An organization could sign NDAs or other agreements with manufacturers and fund developers to implement support for GPUs, Wi-Fi adapters and other hardware.

Ideally the resulting driver would be open source. However, where this is impossible because of licensing or NDA restrictions, even an officially supported binary driver/package would still be much better than having no BSD support at all.

3. A public BSD build service

I would also like to build infrastructure where users could request packages to be compiled on servers.

For example, a user could select:

FreeBSD / NetBSD / another BSD
OS version and architecture
package or port
build options

The server would build it in a clean environment and provide the resulting package or repository.

This could be especially useful for users who do not have powerful machines or who need packages built with non-default options.

4. Work with existing package ecosystems

I don't want to invent another package manager.

The project should cooperate with and contribute to existing ecosystems such as FreeBSD Ports, pkgsrc and Ravenports, and potentially support OpenBSD and DragonFly BSD as well.

The important part for me is that this should not become "another BSD project competing with other BSD projects." The goal should be to provide shared infrastructure, funding and development resources that can benefit several BSD systems.

Obviously, this is much too large for one person. I cannot build such an organization alone.

So for now I am looking for people who find the idea interesting and would like to discuss it, improve it, or help start a small working group.

We don't need to begin with a foundation, large servers or major companies. We could start with a few people, a few ports, and one build server. If it works, we can grow from there.

And perhaps much later, when we have something established and can demonstrate a real BSD user base, we could even start talking to companies such as Valve about better game and Steam support on BSD.

Would anyo
ne be interested in working on something like this?

 

[Ferocious1881]

It is possible to modify the steamclient to use wine when possible and change to linuxator when impossible?

 

[ZioMario]

Steam's mainly useful to me for PCVR, and I'm thinking that might have more latency doing Proton/Wine -> Linuxlator -> FreeBSD

Otherwise if a game doesn't need Steam DRM or Proton-specific fixes, it's more fun to run SteamCMD and games through FreeBSD Wine

This is the best idea that has come up in the whole conversation, and I'm not saying that to encourage you: there's a number behind it.

The data​

An overview of gaming on FreeBSD from April 2026 reports that Wine + DXVK on FreeBSD is 5 to 15% slower than Linux, with the gap having narrowed significantly since 2024, and that DXVK works on FreeBSD with AMD and Intel GPUs that have Vulkan support. A wine-proton port also exists: the FreeBSD documentation describes it as work under way to bring Valve's work to FreeBSD, and on the forums several users report far more success getting games to "just work" with wine-proton than with standard wine.

Translate that number: the native Wine path on FreeBSD is already within a hair of Linux. It isn't a hope, it's a configuration that runs. And the gap is closing on its own, without you doing anything.

Compare that to the state of the other path: Steam does not run natively on FreeBSD, there is no FreeBSD Steam client, and the Linux client under binary compatibility is fragile.

What it does to the project's thesis​

§3 says: Linux ABI → semantic translation → native FreeBSD primitives. Your idea adds a principle upstream of that:

Before translating the Linux ABI, ask whether that process has to cross it at all.

For a game that exists as a Windows PE, the chain becomes PE → native FreeBSD Wine → FreeBSD syscalls. The Linuxulator is not in the path. You're not fixing a divergence: you're routing around it, and in the right way — because the code doing the work is Wine, maintained upstream, with an in-tree FreeBSD backend.

The result is that the Linuxulator's surface shrinks from "the union of a hundred games' syscalls" to "one single program." The Steam client stays — it's needed for ownership, downloads and the DRM handshake — but it's one program, versioned, with a bounded surface that is stable over time. That one you can map in full. The union of a hundred games you cannot.

And it's the same thing LSU already does today with its native Wine integration, which is recommended over the Proton chroot. You aren't inventing an architecture: you're proposing to invest in this one instead of the other.

The advantage you should weigh above all the others​

The bugs you find on this path go to WineHQ, not to FreeBSD. Userspace, not kernel. No DCO on kernel code, no clean-room question from §4, no dependency on a committer to sponsor you, no involvement in the LLM argument that blocked you this week.

After four days spent mapping that wall, this is the road that simply doesn't run into it.

What gets worse, and belongs in the briefing​

Anti-cheat. EAC and BattlEye work on Linux because Proton is a sanctioned environment. Native FreeBSD Wine is in nobody's matrix. So §2.4-bis gets harder, not easier — which confirms what I said earlier: AC1 off the critical path.

32-bit, and this is the hard part. The Steam client is i386, and the WoW64 situation on FreeBSD is in bad shape: on the forums in June 2026 you can read that on 15.1 wine-devel only ran with WINEARCH win64/wow64 and the syswow64 folder stayed empty, and that getting a 32-bit game working with DXVK required installing wine from regular pkg plus pkg32. So the one thing you cannot route around — the client — is precisely the one sitting on the most fragile path. This needs to be measured first.

T1's diagnostic value. The thirty Linux natives were valuable because they isolated Linuxulator divergences from Wine ones. If you route everything through Wine, you lose that separation. But that's a research cost, not a product cost — and your goal is the product.

What I'd actually do​

This idea turns the project's biggest question — how much Linuxulator work is really needed? — from an estimate into a cheap measurement:

Install wine-proton on FreeBSD with an AMD GPU. Take the corpus titles that exist as Windows PE. Launch them outside Steam, one by one. Count how many run.

No SUT needed, no ORCH, no REF, no differential. You need a machine, a graphics card, and a few days. And the result tells you how big the remaining problem is: if eighty out of a hundred run, the Linuxulator is a problem for the client alone, and the 63–113 person-months need to be redone from scratch, downward.

I'd put this measurement before P0.1, alongside P0.0. They're the two experiments that can shrink or kill the project, and both cost days instead of months.

One caveat about the number I started from: the 5–15% comes from an industry blog, not a reproducible benchmark suite. It's an order of magnitude, not a measurement. But it's an order of magnitude worth verifying yourself — and verifying it is, once again, far cheaper than continuing to write the document.

Claude.

 

[ZioMario]

It is possible to modify the steamclient to use wine when possible and change to linuxator when impossible?

The fork already exists, it has a name, and it's an official Steam extension point: the compatibility tool. You don't need to modify the client.

How it works in LSU today​

LSU registers several custom tools — chroots with legacy Steam Runtime, Sniper, Proton 8 — plus a hybrid "FreeBSD Wine" tool that substitutes Proton's Linux Wine binaries with native FreeBSD Wine binaries from the emulators/wine-proton port, while other Proton parts remain unchanged. Selection happens per title, in the game's Properties, Compatibility tab.

So the granularity is per appid, and the mechanism is the same one Valve uses for Proton itself.

One detail that makes the picture messier than you'd expect: inside Proton there are also Linux binaries that aren't Wine, and those are not replaced — they run through emulators/libc6-shim, which is another emulation thing, entirely independent from the Linuxulator. So the hybrid configuration has three layers: the Steam client under the Linuxulator, native FreeBSD Wine, and a userspace glibc shim for the remaining pieces.

And the field verdict is clear: the hybrid mode is recommended as more reliable than pure Linux Proton under emulation, thanks to working WoW64 and more stable 3D acceleration on Intel and AMD cards.

Where exactly the fork falls

Two distinct moments:

At install time — forcing a compat tool makes Steam download the Windows depot instead of the Linux one. This is where it's decided which binary will exist on disk. Not reversible without reinstalling.

At launch — Steam invokes the tool's script instead of directly executing the Linux ELF. The script is your code: it receives the command line and decides what to do.

Automatic, yes — but not the way you're thinking​

A runtime fallback — try Wine, and if it fails switch to the Linuxulator — doesn't work: you discover the failure after a crash, or worse, after thirty minutes of corrupted gameplay. And the depot choice was already made upstream of that.

What can be automated is the decision, not the switch: a table of appid → path, shipped alongside LSU and updated by measurement. A sort of ProtonDB for FreeBSD.

And this is where the 100-title corpus changes function. It stops being a sample for the syscall differential and becomes the routing table. That's a much more direct use of the same work, and it produces an artifact useful to anyone using LSU, not just to you.

Some rows of that table are already written, and they're instructive: the known issues of the FreeBSD Wine tool include incompatibility with the Steam overlay and with the Windows versions of Half-Life and Half-Life 2 engine games. Meaning Source on Windows → broken, so for Portal, HL2, TF2 and Left 4 Dead 2 you use the native Linux depot. Which is fine: those titles do have a Linux build, and it's precisely the case where the Linuxulator remains the right road.

I have to correct something I told you yesterday​

I wrote that the bugs on this path go to WineHQ and so you avoid the FreeBSD gate. That was too optimistic. LSU states explicitly that this hybrid configuration is quite different from both the official Linux Proton builds and vanilla Wine, and that any issues encountered with it cannot be reported directly to either project's bug tracker.

So the hybrid is no-man's land: not FreeBSD, not Wine, not Valve. The bugs stay with shkhln and whoever helps him. The "userspace, upstream, no gatekeeper" advantage holds for wine-proton used on its own — not for the configuration inside Steam.

What I'd do with it​

The question you asked has an answer that simplifies the project a great deal: the fork doesn't need to be built, it needs to be populated.

The mechanism is there, it works, and its own author recommends it. What's missing is the data: for each of the 100 titles, which of the four available tools works best, and why it fails when it fails. You measure that on a single machine with an AMD card — no SUT, no REF, no differential.

And the result tells you two things at once: the routing table (useful to everyone, immediately) and the real size of the Linuxulator remainder — that is, how many titles have no working path at all, which is the only set for which the 63–113 person-months of kernel work are genuinely necessary.

I suspect that set is much smaller than a hundred. But it's a suspicion, and it's measurable in days.

Claude.

 

[Maturin]

Come on. Why Linux always comes first and FreeBSD should be the second choice when we talk about multimedia / video games ? Our is a nice OS,it should not be second to anyone in / for something.

That's right. But the point simply is popularity. Everybody knows Linux, but only a very few know BSD.
It's like everywhere else: You get enough choices of clothes in sizes for people between 1.68 m to 1.86 m everywhwere, but if you are taller than 1,95m it's getting difficult to get a new pair of trousers, because almost nobody produces for small market segments.
Plus, what fahrenheit already mentioned, don't underestimate the issues all this DRM stuff causes.

My advice was, to take a very close look at what Sony actually did taking FreeBSD as the platform for their PlayStation. It's not about to rebuild a PS, but you will learn a lot, how it's done. I'm pretty sure they not only modified FreeBSD a lot (stripped it down to the max to all what's really needed, only) but also did a lot of programming of their own stuff that runs on FreeBSD, which is the true nature of the PS.

Anyway don't underestimate the requirements for running computergames: 2D, 3D comes second, What you must provide above all is max speed available, and not only speed, but perfect smooth running, there must be absolutely no lags.
Some tiny lags seldom happen while using a desktop environment under full load are often not even recognized, nor are they of real importance, when they are short and seldom. But while playing a realtime game, particulary online multiplayer, those are a absolute no-go, a killer, must not happen at all.

 

[Maturin]

32-bit, and this is the hard part

You don't have to support all games. No gaming platform is capable to run every game. You have to make selections.

 

[fahrenheit]

Regarding Steam, runtimes are only needed for linux native games (i.e. those that run on top of linuxlator, either the default or shkhln's), so here you have whatever compat/linux (or shkhln's) libs are available plus the steam runtime libs required by the game (rt1 to 4) but you will still hit missing syscalls and/or lack of drm support. Runtime 4 may have an additional issue of being loaded as a container (so missing cgroups and namespaces), I'm not sure about the actual implications of what valve has documented.
Regarding windows games, which are the majority (and growing because linux native is mostly dead because of proton), like you found out there's wine (of which we have exactly one version available), proton (of which, again, we have one version available) and an hybrid of the two.
Steam works by offering users the option of changing the proton version per game because what works for someone may not work for another. But in our case, you have exactly one version. Wine has limited upstream support for FreeBSD (patches welcomed, but we can't realy validate it), Proton has 0 upstream support and works because of FreeBSD users that maintain the port, likewise for steam.

So, the work would not only be does this game work? And what is the best path for it to work?
But instead, this game works by this method on this freebsd release with this wine and this proton (ports) version. And you will have to do this for any change of game version, fbsd and ports.
Then you will have to figure out if the game is actually playable or crashes after the intro, or it only works for drm-612-kmod for kabylake users but not for rx 7600 users.

So, back to what is doable and what is not:

1. Doable, build a, user-sourced, database of game status (similar to protondb but for freebsd) that covers all the above
2. Doable, help with the validation and merging of existing PRs that improve on existing issues
3. Not doable (pratical without valve resources), what you are trying to do

 

[dkh]

If something relies on Linuxulator it's not really a FreeBSD system imo. The Linuxulator is a nice feature to have available as an escape hatch if you really need an non-bsd compatible app on your machine
it but it doesn't make something like the Steam Machine a FreeBSD thing. You might as well run it in a linux jail or bhyve instance imo.

 

[NapoleonWils0n]

Linux jails also use the Linuxulator,
and applications can still see they arent running on real linux which in Steams case would stop it working

So you have the same issue as if you use the Linuxulator directly

Podman can be set so the os type is linux which does trick applications into thinking they are running on Linux
but Podman still uses the Linuxulator so you still have the same issue of missing sys calls

If you use Bhyve then you would have to pass through an external graphics card and display
to have hardware accelerated graphics

And by the time you have paid for an external graphics card and monitor you might as well just buy a steam machine

 

[Ferocious1881]

Linux jails also use the Linuxulator,
and applications can still see they arent running on real linux which in Steams case would stop it working

So you have the same issue as if you use the Linuxulator directly

Podman can be set so the os type is linux which does trick applications into thinking they are running on Linux
but Podman still uses the Linuxulator so you still have the same issue of missing sys calls

If you use Bhyve then you would have to pass through an external graphics card and display
to have hardware accelerated graphics

And by the time you have paid for an external graphics card and monitor you might as well just buy a steam machine

It is not possible to graphical redirection from a graphics card to another?

 

[ZioMario]

You might as well run it in a linux jail or bhyve instance imo.

if I use a Linux jail or a bhyve vm based on Linux,aren't these ones, FreeBSD things ?

 

[ZioMario]

And by the time you have paid for an external graphics card and monitor you might as well just buy a steam machine

Not yet. The steam machine costs 1400+ euros ! an used Radeon rx 6600 + a monitor cost 500 euros,less of the half of the price of the Steam machine. But anyway,the scope of the project is not something like "you like to win easily". Plus. Today,all the modern motherboards have one integrated iGPU inside. So,you already start with one GPU on board. You should buy only a dedicated GPU. But even in t his case,a lot of users have one of them,AMD or nVidia. I think this is not the problem. If I want to remove one monitor,I can do it. When I have "re-implemented" Looking Glass on FreeBSD,we could play the Steam games using one only monitor.

 

[Ferocious1881]

Looking Glass

Is what is was saying?

It is not possible to graphical redirection from a graphics card to another?

 

[ZioMario]

1. Not doable (pratical without valve resources), what you are trying to do

What is technically not doable about what I'm doing ?

 

[ZioMario]

It is not possible to graphical redirection from a graphics card to another?

I think that for this project the right configuration should respect the KISS philosophy (Keep It Simple Stupid) : a GPU,a monitor attached to it and a open source driver. Every piece that I add is a variable that I should exclude if / when something will fail.

 

[LibreQuest]

Multiple issues with the idea

How are you going to get round the anti cheat measures

Steam checks if its running on real linux and will instantly see its not
and its running using the linuxulator then probably triggers a ban

Vibe coding and constantly playing catch up to fix issues with Freebsd updates
and how it works with the Linuxulator or with updates to Steam

Poor hardware support for Freebsd

Just using Freebsd for the sake of it

When I used to use Linux I would use wine to play games and use Steam. It seemed rather pointless to Windows users. But it worked well sometimes. haha There are several projects that make Steam run on FreeBSD very well. There's no reason not to use FreeBSD for gaming if it's Steam, Epic, GOG etc. I moved from Linux to FreeBSD because it was able to do the things I was used to doing on Linux back in 2023. And gaming is one thing that it does very well. Not all games. But many games and at high fps and high resolution. In fact there are games that I have played on FreeBSD that never worked on Linux. It really just depends on the game and the technology you're using to play. I do wish Mizuma still worked with Steam. But it's great for Epic and GOG and UrbanTerror! Woo! Also the hardware support issue is not accurate. I have systems with Nvidia, Radeon and integrated Intel. Each system performs very well in gaming, when the games work of course. I think out of my entire library more work than don't. I only have 324 games in my Steam library and I know there are at least 40 that don't work. :/ But that's mostly because of anti cheat or the lack of kernel modules that don't exist for FreeBSD. And some have started working, partially lately.

 

[Maturin]

What is technically not doable about what I'm doing ?

Something being technically doable only means, all needed technical requirements are given, so in theory technically it can be done. Or to put in other words, it's not science fiction, so completely unrealistic.
But it needs more to realize something, not theory only, e.g. time is a very important factor many projects fail about, because not realistic estimated.
Silly example:
To remove a mountain by somebody just using a spoon is technically doable. But you see on the instant: Bogus. Not doable within a decent time, so unrealistic.
That's what I meant with:

get some realistic idea of what amount of different kinds of work needed to be done, how many effort is needed for each (hours to work on), and then estimate added up hours needed to be done divided by the amount of people working X hours per day on it, gives the estimated months/years until it's finished, and so if it's realistically doable, or not.

Such are fundamental basics of project planning.
As you said, your are ambitious, have enough time, and don't need to meet no time schedule, so you might not use any sophisticated project planning, but you could just start on it and see how far you get. But even if so, you might at least check out, if something is really realistic or you run into an endless desert, and perhaps one day may look back on many years, still not are where you wanted to get, and just have that frustration of wasted time and effort, and maybe even money. (mountain and the spoon - better don't start on that in the first place.)

I think that for this project the right configuration should respect the KISS philosophy (Keep It Simple Stupid) : a GPU,a monitor attached to it and a open source driver. Every piece that I add is a variable that I should exclude if / when something will fail.

KISS is basic fundamental engineering. Of course it should be respected. Anything not respecting KISS is bad engineering.
KISS means, not to add any unneeded junk, not to complicate things more than just needed. But this does not mean, just because something is not unneccessarily complicated, then it's automatically simple, so trivial, so quick and easy to do.

To create some special hardware, that will be cheap to buy, and then adapt your software and FreeBSD to it, comes later. If you start with the hardware, you put the cart before the horse.
And looking for cheap but sufficient hardware is already optimizing. Never ever start optimizing unless you already have the essentials solid working.
"Premature optimizing is the root of all evil." [Donald Knuth]
This is true for any kind of engineering, not software, only.

My advice was, before you start tinkering with any hardware, just see how to get steam games running on your FreeBSD machine at all. No need to tinker some own computer for that (yet.) And better more power than what you might expect for the future (optimization.)
You need to do that anyway, and that's also where the most work is.
You need your hardware fit the job shall be done, not adapt the job to the hardware.

See, what's already there, how it works, where it fails, if it fails, and why, what can you use or learn from it, so encircle and minimize the amount of work you need to do. But first start to make it run on FreeBSD at all, don't bother the hardware.
There are several attempts for this already, like Mizutamari, as I already mentioned.
If you already get this far, provide to play steam games on FreeBSD, even on ambitious hardware, without much tinkering for the user to get it up and running, and not everything gets ripped apart when there is an update, you already reached a lot.
If it was easy, we already had it.

But you also need to check, if the games really run. You say, you are not a player. I am. So I know what to look for. Just see some splash screen occurs at the start doesn't mean the game runs. Just see the game technically starts to run doesn't mean it runs. You need to really play it, to figure out if it runs playable, not snail slow and/or full of lags, not crashing at some certain points, having some graphics errors/artifacts or suddenly see nothing at all anymore etc. etc. etc.
As I said:

Computer games are technically most ambitious and pretty tricky at the same time.

And they vary very much in how they work, and what they need.
They are not some deskto App consisting of some python code assembled with some GTK library.

 

[T-Daemon]

ZioMario, I didn't catch in your thread if this is some kind of a pet project or proof of concept, or are you planning to develop a commercial product for sale?

 

[fahrenheit]

What is technically not doable about what I'm doing ?

What you have highlighted to do, check 100 games on amd hardware (your posts #33 amd #34). Plus I didn't say technically not doable, I said practically not doable. (I.e. it's doable, you can do it, it's just not pratical in the long run).

Besides of the obvious 100 game question: Which 100 games? Steam top 100 most sold games? Top 100 games that you are interested?

 

[ZioMario]

Update.

This would unequivocally be the case for our SteamBSD machine :

DB4 - Fanless ITX Case

The DB4 is a design masterpiece featuring a bi-symmetrical design that blurs the lines between technology and art. Every element of this case subtly screams premium, from the 13mm thick extruded aluminium side panels to the precision CNC’d internal frame, all perfectly blended together with our...

shop.streacom.com

As secondary option,this one :

AZZA Cube 802 CSAZ-802 Black Computer Case - Newegg.com

Buy AZZA Cube 802 CSAZ-802 Black SPCC ATX Cube Case Computer Case with fast shipping and top-rated customer service. Once you know, you Newegg!

www.newegg.com

Which of the two do you prefer ?