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.
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.
Author here: I get where you’re coming from and long term, I agree. I don’t want FreeBSD to slowly turn into "Linux but different."
For me though, the Linuxulator is about practicality today, not philosophy. It lets me use one or two tools (like the VS Code server) without changing how I actually run my system. Everything else stays native FreeBSD.
It's optional, isolated, and doesn't pollute the base system. If native ports exist and work well, I'll always prefer those. But when something critical doesn't, the compatibility layer keeps FreeBSD usable in modern workflows instead of becoming limiting.
So yeah.. I see it more as a bridge, not a direction.
Which is the same reason I don't like Proton, as it in the end doesn't change Windows status quo as the platform for game developers, and hardly any different from using MAME, Vice, Stella, Mesen, Linux-UAE,....
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. 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"
No you're not wrong, if you're comparing ARM CPUs on Linux to one specific Intel CPU, the Lunar Lake V ones. Then yeah you're not wrong, it's very much a case of optimisation for CPUs like the Snapdragon X Elite CPUs in comparison.
But if you widened the scope a bit more, then I think there's plenty of more energy hungry x86_64 CPUs compared to ARM.
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.)
>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 the parent maybe was off base, but that is literally all the reasoning.
For guidance the arch doesn't impact battery life or performance as much as a specific process node and model. There are slow as shit x86 chips from VIA(maybe? I just retired a node that ran on one.) and fast ARM64 chips, but any high end Ryzen will blow an ARM64 chip out of the water on most real benchmarks I run(HPC stuff, lotsa matrix multiplications and such(CUDA and double float performance is too much premium and yes I have done alot of profiling and benchmarking.))
> 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.
I have a Strix Halo laptop, HP ZBook Ultra G1a. (HP is a weird brand. I'm not a loyal customer, but every once in a while they create a product with really good reviews, I buy it, and it delivers.) Performance is almost on par with Apple's best, but battery life under light load is much worse :P, 6:30 or so.
Under full load, battery life is an hour or so, similar to Apple actually! If the numbers I've seen are correct, they also use a lot of power under full load.
Also, thank $deity for engineered noise signatures. Whooshing is not so bad. Whining fans are the worst. Last heard in better laptops several years ago.
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.
We build and sell multi-service business gateways, basically devices that do networking, VoIP, etc. all in one box. https://difuse.io/ if you're interested!
> 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)
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.
wolvoleo|7 days ago
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.
vermaden|7 days ago
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
drzaiusx11|7 days ago
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.)
wutwutwat|7 days ago
arch1e|7 days ago
For me though, the Linuxulator is about practicality today, not philosophy. It lets me use one or two tools (like the VS Code server) without changing how I actually run my system. Everything else stays native FreeBSD.
It's optional, isolated, and doesn't pollute the base system. If native ports exist and work well, I'll always prefer those. But when something critical doesn't, the compatibility layer keeps FreeBSD usable in modern workflows instead of becoming limiting.
So yeah.. I see it more as a bridge, not a direction.
pjmlp|7 days ago
musicale|7 days ago
But I wouldn't mind if macOS (a BSD-flavored Unix) added support for linuxlator, and jails, pledge, and various other BSD-flavored things.
drewg123|7 days ago
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.
teekert|6 days ago
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?
intothemild|6 days ago
But if you widened the scope a bit more, then I think there's plenty of more energy hungry x86_64 CPUs compared to ARM.
foldr|6 days ago
eqvinox|7 days ago
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.)
DaveCharlieLen|7 days ago
>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 the parent maybe was off base, but that is literally all the reasoning.
For guidance the arch doesn't impact battery life or performance as much as a specific process node and model. There are slow as shit x86 chips from VIA(maybe? I just retired a node that ran on one.) and fast ARM64 chips, but any high end Ryzen will blow an ARM64 chip out of the water on most real benchmarks I run(HPC stuff, lotsa matrix multiplications and such(CUDA and double float performance is too much premium and yes I have done alot of profiling and benchmarking.))
matja|7 days ago
Yeah, I don't think the architecture is going to help a bad storage/network setup too much. I'd be troubleshooting that before jumping machines/OSs.
ch_123|7 days ago
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.
ahartmetz|7 days ago
Under full load, battery life is an hour or so, similar to Apple actually! If the numbers I've seen are correct, they also use a lot of power under full load.
Also, thank $deity for engineered noise signatures. Whooshing is not so bad. Whining fans are the worst. Last heard in better laptops several years ago.
jrmg|7 days ago
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?
throwa356262|7 days ago
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.
swiftcoder|7 days ago
bzmrgonz|7 days ago
arch1e|7 days ago
unknown|7 days ago
[deleted]
metadat|7 days ago
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!
throawayonthe|7 days ago
DaveCharlieLen|7 days ago
throw0101a|7 days ago
* https://en.wikipedia.org/wiki/Return_to_Castle_Wolfenstein
lamuswawir|7 days ago
Gud|7 days ago
kleiba|7 days ago