> 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 difference is that with the standard linuxulator, the linux env. is maintained by the FreeBSD package manager, and can sometimes be out of date. Further, the standard linux compat package will install a red hat based distro, which is often not the easiest to deal with in terms of compat with random things you might want to run. I often found I had libraries that were either missing, or were a version out of date when trying to run stuff with linux compat from packages/ports. With a linux jail, you can install an ubuntu based distro & let it keep itself up to date via apt.
I really don't like using projects like linuxulator or the linux compatibility layer (are those different?). I'm running FreeBSD because I prefer it over Linux. I don't want to make it like Linux. If we give in to that we'll end up importing more and more linuxisms and in the end everything will require those.
Bedides, the FreeBSD port of codium works fine and with a few setting changes you can install even the proprietary extensions like the Remote SSH.
There's a few tools I don't use because they don't have a FreeBSD port. I've asked the developers and they were like 'just use the compatibility layer'. But nope, then I'll just pick something else.
Right now I have nothing using the Linux compatibility layer at all which is great.
> I'm running FreeBSD because I prefer it over Linux.
Me too but there are things that will not be ported (at least soon) anyway ... that is where Linux Compat Layer helps. Even simple watching movies with DRM bullshit (Widevine) or using a Brave browser that is not in the FreeBSD Ports ... or running Linux games ... or CUDA workaround ... and no NopeVidia will not provide official CUDA support anytime soon.
Also please remember that entire The Matrix (1999) movie was rendered [1] on FreeBSD machines in Linux Compat Layer because the software used to do that was not natively available on FreeBSD an yet it sill run faster on FreeBSD in Linux Compat Layer then natively on Linux. Let that sink in.
Even today [2] playing Linux games in Linux Compat Layer is faster then natively on Linux - with more FPS and more 'stable' gameplay.
In the reference video you posted he literally states that the FreeBSD version was less stable than Linux, that he experienced repeated game crashes in FreeBSD, that frame rates would drop 50% without explanation and that the overall experience was better on Linux than FreeBSD or Windows.
It should also be noted that it’s also not native on Linux either as he’s using Wine on both Linux and FreeBSD
Do the "linuxisms" inherent in a compatibility shim like linuxlator get exposed to users in day to day application use?
I figured it'd be more like how proton provides windows APIs on Linux and applications "just work" as per normal.
I admire your purist approach, but most folks don't have that luxury and just need to make do with what works today for their tooling of choice (or more common, what their employer thrusts upon them.)
Leaving a potential solution on the table that could make your own life easier is silly to me. You don't have to use it for everything and you shouldn't worry about some Linux takeover. Id imagine that for user-land desktop environment related stuff there isn't much difference. Gnome on FreeBSD and gnome on Ubuntu can't be doing things that different from one another.
Well if I wanted to make my life easier I would just use ubuntu or something. Or even Windows? Because even between Linux distros there's a lot of difference in terms of usability. FreeBSD is not something you can run without investing time to figure things out, you really have to be willing to think different. But that's good for me, I don't like going with the flow, I'm an anti-team player :)
But by supporting options that have real ports, I stimulate those. By giving in to the easy way I will make that more palatable for developers.
And Gnome and KDE have native ports. I really hate the opinionated design of Gnome so I don't use it, but I do use KDE. It does have a lot of cool tweaks by the maintainer to make it work properly.
> 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.
This seems like a flawed premise.
Battery:
Yes, MacBook battery life is really good, but only when you're not doing CPU-intensive tasks. Browsing the web, watching Tube or Netflix, it's amazing. Once you're compiling a bunch of stuff the battery performance tanks and seems just like any other notebook computer.
CPU: Intel Mac performance was horrible, M* is terrific. And so are the latest from AMD Ryzen.
Regardless, FreeBSD is a fantastic OS in so many ways!
Definitely true that the battery life is not at all inherent to arm, but "Once you're compiling a bunch of stuff the battery performance tanks and seems just like any other notebook computer" is not that true i think, apple silicon is still fairly power efficient even at full throttle compared to most x86 chips (though again yes the latest mobile amd chips are catching up)
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.
Isn’t it still the case that, for speeds comparable to an Apple system, x86_64 is still more power/performance efficient than basically any other ARM-based system you can buy?
In raw power x64 is still the king, has always been.
You can skew things by looking only at single core performance (where apples most expensive cpus might win because of their strategy of having fewer but more powerful cores + memory latency gains are much more visible with only one core).
With that said, things are changing in the PC landscape and some extremely powerful and power efficient ARM designs are coming soon. We have already seen a small glimpse of that with MediaTek.
> 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 best way to run linux compat on FreeBSD is in an Linux jail. See https://wiki.freebsd.org/LinuxJails
The difference is that with the standard linuxulator, the linux env. is maintained by the FreeBSD package manager, and can sometimes be out of date. Further, the standard linux compat package will install a red hat based distro, which is often not the easiest to deal with in terms of compat with random things you might want to run. I often found I had libraries that were either missing, or were a version out of date when trying to run stuff with linux compat from packages/ports. With a linux jail, you can install an ubuntu based distro & let it keep itself up to date via apt.
I really don't like using projects like linuxulator or the linux compatibility layer (are those different?). I'm running FreeBSD because I prefer it over Linux. I don't want to make it like Linux. If we give in to that we'll end up importing more and more linuxisms and in the end everything will require those.
Bedides, the FreeBSD port of codium works fine and with a few setting changes you can install even the proprietary extensions like the Remote SSH.
There's a few tools I don't use because they don't have a FreeBSD port. I've asked the developers and they were like 'just use the compatibility layer'. But nope, then I'll just pick something else.
Right now I have nothing using the Linux compatibility layer at all which is great.
Its the same thing - just different naming.
Me too but there are things that will not be ported (at least soon) anyway ... that is where Linux Compat Layer helps. Even simple watching movies with DRM bullshit (Widevine) or using a Brave browser that is not in the FreeBSD Ports ... or running Linux games ... or CUDA workaround ... and no NopeVidia will not provide official CUDA support anytime soon.
Also please remember that entire The Matrix (1999) movie was rendered [1] on FreeBSD machines in Linux Compat Layer because the software used to do that was not natively available on FreeBSD an yet it sill run faster on FreeBSD in Linux Compat Layer then natively on Linux. Let that sink in.
Even today [2] playing Linux games in Linux Compat Layer is faster then natively on Linux - with more FPS and more 'stable' gameplay.
Hope that helps.
[1] https://freebsd.org/press/press-rel-1/
[2] https://youtube.com/watch?v=lK6eRbz9DkM
In the reference video you posted he literally states that the FreeBSD version was less stable than Linux, that he experienced repeated game crashes in FreeBSD, that frame rates would drop 50% without explanation and that the overall experience was better on Linux than FreeBSD or Windows.
It should also be noted that it’s also not native on Linux either as he’s using Wine on both Linux and FreeBSD
Do the "linuxisms" inherent in a compatibility shim like linuxlator get exposed to users in day to day application use?
I figured it'd be more like how proton provides windows APIs on Linux and applications "just work" as per normal.
I admire your purist approach, but most folks don't have that luxury and just need to make do with what works today for their tooling of choice (or more common, what their employer thrusts upon them.)
Compatibility layers can also introduce security bugs. One of the reasons why it was removed from OpenBSD.
BSD is more for purists anyway. Virtualization seems to be a better option than compatibility layers for the odd program that doesn't work natively.
Maybe that it's different for Windows API's on Linux, because by virtualizing Windows, you're still dealing with an unfree OS.
Leaving a potential solution on the table that could make your own life easier is silly to me. You don't have to use it for everything and you shouldn't worry about some Linux takeover. Id imagine that for user-land desktop environment related stuff there isn't much difference. Gnome on FreeBSD and gnome on Ubuntu can't be doing things that different from one another.
Well if I wanted to make my life easier I would just use ubuntu or something. Or even Windows? Because even between Linux distros there's a lot of difference in terms of usability. FreeBSD is not something you can run without investing time to figure things out, you really have to be willing to think different. But that's good for me, I don't like going with the flow, I'm an anti-team player :)
But by supporting options that have real ports, I stimulate those. By giving in to the easy way I will make that more palatable for developers.
And Gnome and KDE have native ports. I really hate the opinionated design of Gnome so I don't use it, but I do use KDE. It does have a lot of cool tweaks by the maintainer to make it work properly.
5 replies →
> 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.
This seems like a flawed premise.
Battery:
Yes, MacBook battery life is really good, but only when you're not doing CPU-intensive tasks. Browsing the web, watching Tube or Netflix, it's amazing. Once you're compiling a bunch of stuff the battery performance tanks and seems just like any other notebook computer.
CPU: Intel Mac performance was horrible, M* is terrific. And so are the latest from AMD Ryzen.
Regardless, FreeBSD is a fantastic OS in so many ways!
Definitely true that the battery life is not at all inherent to arm, but "Once you're compiling a bunch of stuff the battery performance tanks and seems just like any other notebook computer" is not that true i think, apple silicon is still fairly power efficient even at full throttle compared to most x86 chips (though again yes the latest mobile amd chips are catching up)
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.
Isn’t it still the case that, for speeds comparable to an Apple system, x86_64 is still more power/performance efficient than basically any other ARM-based system you can buy?
In raw power x64 is still the king, has always been.
You can skew things by looking only at single core performance (where apples most expensive cpus might win because of their strategy of having fewer but more powerful cores + memory latency gains are much more visible with only one core).
With that said, things are changing in the PC landscape and some extremely powerful and power efficient ARM designs are coming soon. We have already seen a small glimpse of that with MediaTek.
For the most part, yes, which is why he's using a Mac as his daily driver, and ssh'ing into the BSD box
Back in the day I used to run the Linux client of RtCW on FreeBSD with Nvidia drivers:
* https://en.wikipedia.org/wiki/Return_to_Castle_Wolfenstein
Cool! Reminds me of how some 18 years ago or so, I was using TRAMP in Emacs to do remote development over ssh. Some things never change, apparently.