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.
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?
> 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!
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.
> 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.
This feels a little off base; what the author needs is a fast and efficient machine. Why would the architecture matter?
It may be the current state of affairs that Apple ARM systems are great at this. But (1.) that doesn't mean other ARM systems are good at it, and (2.) doesn't mean it's going to stay that way.
(And in all honesty, a lot of non-Apple ARM systems are just garbage in either performance, efficiency, or both.)
I want to love FreeBSD I have run it for multiple years on my servers. But there is always something off. The linuxulator works okay, but not great, and not great isn't good enough. Like WSL1 worked better than Linuxulator at least as of last Jan when I tried. The WINE story was even worse(do a jail for x32 things and run x64 normal). I do love FreeBSD but it is hard to take seriously as a desktop OS when some regular things are way too hard to get working.
"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. Unfortunately, there’s currently no FreeBSD-supported (or even Linux, as far as I can tell) ARM64 laptop that truly rivals Apple Silicon. I really hope Framework or someone else changes that in the coming years."
I thought it was now well established that it's not neccessarily ARM vs x86, but more "All the optimization of MacOS" vs "Bloated Windows" and "Sub-optimal (hardware control wise) Linux"
12 comments
[ 2.8 ms ] story [ 30.5 ms ] threadBedides, 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.
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?
* https://en.wikipedia.org/wiki/Return_to_Castle_Wolfenstein
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!
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 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.
This feels a little off base; what the author needs is a fast and efficient machine. Why would the architecture matter?
It may be the current state of affairs that Apple ARM systems are great at this. But (1.) that doesn't mean other ARM systems are good at it, and (2.) doesn't mean it's going to stay that way.
(And in all honesty, a lot of non-Apple ARM systems are just garbage in either performance, efficiency, or both.)
I thought it was now well established that it's not neccessarily ARM vs x86, but more "All the optimization of MacOS" vs "Bloated Windows" and "Sub-optimal (hardware control wise) Linux"
Am I wrong?