
Steam on FreeBSD - vasili111
https://github.com/SteamOnFreeBSD/SteamOnFreeBSD
======
vasili111
Also see:

Steam on PC-BSD - How to Get Wine Running 3D Games:
[https://www.youtube.com/watch?v=B04EuZ9hpAI](https://www.youtube.com/watch?v=B04EuZ9hpAI)

Steam on PCBSD 2 - Using Wine as a Streaming Client:
[https://www.youtube.com/watch?v=BJ88B8aWdk0](https://www.youtube.com/watch?v=BJ88B8aWdk0)

~~~
andrewclunn
This raises an interesting question. Given that there's some emulation
involved either way, is there a performance reason to favor the linux on bsd
over the Windows on bsd approach?

~~~
ketralnis
FreeBSD emulating Linux has way less performance overhead than either
emulating Windows.

FreeBSD's Linux "emulator" consists in a substituted syscall table and a
kernel module for implementing syscalls that aren't native to FreeBSD (like
epoll).[0][1]

Here's an example of what that means. When a FreeBSD binary wants to delete a
file it calls the syscall unlink(2). So it's executing as a regular old
binary, does a regular syscall, specifies the unlink syscall number, the
kernel looks up that syscall number in that binary's (FreeBSD's) syscall
table, and jumps to that code.

When you execute a Linux binary on FreeBSD you also execute it as a regular
old binary except that you specify to use the Linux syscall table instead of
FreeBSD's (IIRC this is done by the elf loader, so you're not even saying
"linuxrun ./mybinary"; you're just saying "./mybinary"). It's executing more
or less identically to a FreeBSD binary except that when it's time to delete a
file it looks up the unlink system call in the Linux syscall table and jumps
to that instead. Some of the arguments or calling conventions are different so
most of the calls have a shim to rearrange stuff for the FreeBSD equivalents
before calling into the same code the FreeBSD binaries are using. This is the
same thing that FreeBSD does to support ABI versions for old versions of
itself, to support SysVR4 binaries[2], and it's the same trick that SmartOS's
Linux zones use as well[3]

What this means is that if your binary isn't using a lot of linuxisms, they
execute at nearly identical performance.

Wine is using a pretty similar trick--trying to directly execute the binary
while intercepting win32 API calls--but the impedance mismatch between posix
and win32 is much higher so the cost of those shims is going to be much
higher. The DeleteFile win32 API function takes a LPCTSTR that needs to be
decoded, its return values have different meanings, and its semantics around
files opened by other processes is different. And obviously for more complex
calls the difference widens: the difference between simply speaking x11 over a
socket vs calling MessageBox is much larger.

[0]:
[https://www.freebsd.org/doc/handbook/linuxemu.html](https://www.freebsd.org/doc/handbook/linuxemu.html)

[1]: [https://www.freebsd.org/doc/en/articles/linux-
emulation/insi...](https://www.freebsd.org/doc/en/articles/linux-
emulation/inside.html)

[2]: [https://people.freebsd.org/~newton/freebsd-
svr4/](https://people.freebsd.org/~newton/freebsd-svr4/)

[3]:
[https://www.youtube.com/watch?v=TrfD3pC0VSs](https://www.youtube.com/watch?v=TrfD3pC0VSs)

~~~
Longhanks
Also, Linux emulation is probably a lot easier to implement, since there is
complete source code access available. Emulating the Win32/NT kernel syscalls
is basically reverse engineering, which makes the progress much harder.

~~~
SolarNet
Hence why WINE is better for emulating older programs. Whereas the linux
subsystem is usually up to date.

~~~
ketralnis
The linuxulator tries to be compatible with Linux 2.6.16 (released March
2006). I'm not sure about Wine but at a glance they mention 64-bit support so
I'd guess at least Vista (also 2006)

~~~
asveikau
That's kernel abi though. My guess is a lot of code in glibc in particular
handles ENOSYS with some reasonable fallback and so you can have a newer
userland.

------
Retr0spectrum
> permit nopass keepenv yourusername

Isn't nopass a bad idea?

Edit: I'm not a BSD user - this is a genuine question, not a complaint.

~~~
mcpherrinm
This is Linux-based, because I don't have FreeBSD experience, but is related
in security posture. I have a more controversial opinion: If you're going to
use `sudo`, you shouldn't use passwords.

Your login passwords should only be given to the login prompt, which you
hopefully have some reasonable faith in its integrity (if not; game over
already).

If you're typing your password into terminals after login, that's a great
place to steal your password. I would much prefer to use pam_krb5 to "kinit on
login", and then by sudo to authenticate your session.

Then you shouldn't ever be tempted to type your password into potentially
untrusted programs.

Of course, if you're sure you have no malware on your computer, then there's
also no need for a sudo password -- nobody but yourself could be running
commands!

~~~
catern
What if your root password is different from your regular password? For
example - if you have a Kerberos root principal? That seems even better.

~~~
lmm
Sudo/doas never involves giving the root password. (Whether it's better not to
use sudo/doas at all is a separate question).

------
mistat
I feel my neck beard growing excitedly then I realise I don't run a GUI or
play games. This is a great achievement none the less. FreeBSD4Life.

------
akerro
[https://news.ycombinator.com/item?id=12187811](https://news.ycombinator.com/item?id=12187811)

------
lorenzfx
I'm curious: why not the Intel drivers?

~~~
morganvachon
Speaking from my own experience: Steam games don't perform all that well on
Linux using a Haswell Intel GPU when compared to Windows. I would imagine BSD
to be worse since Intel's focus is more on Linux, and the Intel BSD driver
tends to be a version or two behind. On the other hand, the proprietary Nvidia
driver for BSD is fast and stable, in some cases faster than its Linux
equivalent, and Nvidia seems interested in continually improving its driver
for all platforms simultaneously.

~~~
talideon
The situation with Intel GPUs is improving though. There's ongoing work to
make sure that Linux graphics drivers can be used on FreeBSD where no native
driver exists yet. Also, there's a good chance the work in Dragonfly BSD will
make it into FreeBSD: Dragonfly has pretty decent support of the more recent
Intel chipsets.

