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
Maybe with games from 2004 and the like, the ones built to run with a single thread. With ntsync (and previously, esync/fsync) that's not true anymore with games designed for multiple cores.
Brave does fall under crypto, yeah, but I don't know about it being a scam. You don't need to engage with the crypto/web3 and all of those can be disabled.
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.)
Theo de Raadt, 2010, on the removal of emulation: “we no longer focus on binary compatibility for executables from other operating systems. we live in a source code world.”
(Since then, OpenBSD has gained support for virtualization for some operating systems including Linux, through the vmm(4) hypervisor.)
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.
I was just saying, is your goal for the os to get out of the way so you can get a job done, or is your job tinkering with your os. I've ran opensense which is a freebsd derivative, and I daily macOS/Darwin which is bsd. Honestly until I need to mess with some systemctl flags I get the same experience from bsd and Linux. Posix and all...
macOS is not BSD. It's a common misunderstanding, it borrows some userland but the kernel is radically different.
But yeah my OS should get out of the way but I don't mind investing a little time in getting things working right. That includes picking the right tools. I was looking for a notetaking app and one of them was like 'just use the compatibility layer'. I think it was notesnook. I just picked obsidian instead which has a port. Still not ideal as it's electron but pretty much all these notetaking apps seem to be electron somehow. And I needed compatibility with android too.
If there's something I could really not do without I would consider it but there's nothing like that right now.
No. This is a common contrarian take, but it's nonsense. macOS is built on Darwin which, along with XNU, traces its lineage through NeXTSTEP to 4.3BSD.
macOS is every bit as much of a BSD derivative as FreeBSD is.
Here's a contrarian-squared take: in reality, the question "Is macOS a BSD" is malformed. It makes some sens, but is more confusing than it's worth.
Yes, NeXT was built on Mach, which was itself basically an evolution of the Accent microkernel married with BSD, when BSD was a proper noun.
In fact, NextStep 0.8, the first public "pre-release", has left support in for A.OUT executables. The included ex and vi binaries are indeed A.OUT executables taken straight from BSD! In the very next release, support for A.OUT was removed, leaving only the Mach-O loader.
XNU is not derived from the Mach that NeXT was, though, but from the OSF Mach kernel, which was continued at the University of Utah. The BSD "bits" were selectively copied from the extent continuations of BSD, or rewritten from scratch. The XNU kernel doesn't strongly resemble any particular *BSD tree, to my knowledge.
Darwin's origins are messier, since it looks like it was a direct continuation of the existing NeXT packaging (but only Apple would know for sure). NeXT, very much unlike BSD, split its userland into distinct packages, which were versioned independently. This practice has carried on to this day, where e.g. Darwin's libc is packaged and versioned separately from the kernel and other utilities.
For that matter, for a very brief period of history, Darwin used Debian's dpkg for building and installing packages. Evidence of this stayed until OS X 10.4-ish, in the Darwin releases, but they returned to NeXT style BOM files for package management.
All that to say, does NeXT/macOS have a BSD-like userland? Yes, but so does Chimera Linux. Does the kernel resemble BSD? In some ways yes, but in many ways no, it's very semantically different.
And is it descendant from BSD? Again, "yes", but it also doesn't really "come" directly from BSD anymore than, say, OSF/1 did. There's no specific BSD it forked from, and no specific point at which it ever really looked like BSD, in terms of userland, packaging, or kernel semantics.
So I think the question just doesn't make much sense to ask.
- Darwin has no direct BSD ancestor. Unlike {Net,Free,Open}BSD and the more obscure ones (Bitrig, anyone?) there was never a point in time where it directly "connects" to the BSD lineage. The other BSDs all can trace their repositories back to CSRG's BSD.
- Darwin isn't stored or built like a BSD. The BSDs have massive monorepos containing all of the source, traditionally checked out to /usr/src, while Darwin is split into many independently versioned packages, (usually) compiled with Project Builder/Xcode.
Yes, the C API is derived from and supposed to resemble BSD, and much of the userspace was copied from a BSD-derivative (this has grown over time, as Apple (and the BSDs) replaced GNU utilities).
But that's why I would call macOS/Darwin "BSD-like" or "BSD-derived" rather than "a BSD".
Also, this isn't meant to be taken too seriously. I just like "OS taxonomy", and I think macOS/Darwin is distinct enough to qualify as a separate species ;-)
Yeah, I probably went too far in saying it's just the userland, but I'll insist it's more complicated than saying it was based on 4.4BSD-Lite2. I haven't done a proper deep dive yet, but I can tell that it wasn't strictly based on the Lite2 release. Take a look at XNU 123.5's (OS X 10.0) kern/tty.c:
You'll also see the source has been reorganized, with e.g. the VFS source being regrouped into bsd/vfs, instead of being left in bsd/kern. This coincidentally mirrors how OSF/1 was organized (no other source relation though, just an interesting observation):
This file had to be reimplemented by all of the BSDs. In this case, this version appears distinct from the FreeBSD and NetBSD versions I can find.
If you grep around for the `NeXT` ifndef/ifdefs in XNU, too, you'll see some code of which some appears to have been copied/adapted from the NeXT source tree, itself derived from Mach/CMU sources. (and 4.3BSD ;-)
I say all this to draw attention to the ways XNU differs from BSD, which is pretty interesting, at least to me.
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,....
And now is subject to the whims of Microsoft, wherever Windows, DirectX, Visual Studio go, Valve must follow.
Additionally, everyone is betting on Valve as if Steam would be around forever serving Linux gaming with Proton, except no one lives forever, and who knows what will happen to Valve, when current management passes the torch.
"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.
You should be comparing to AMD, at that. There's hope for the upcoming Intel chips - but anything current isn't competitive. Furthermore, M* is good for a specific form-factor, but don't for a second suggest that 4 P-Cores will outdo the 16 hyper threaded cores on a 9950x
The only like for like comparison you can do is comparing an M1 MacBook to one of its Intel Mac contemporaries (which were present day Intel systems at the time).
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.
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.))
amd64 definitely beats any aarch64 when it comes to performance, but the trick Apple (and if proper Linux driver support ever lands, Qualcomm) pull is that they get 80% of amd64 performance at 25% of the battery cost.
Not a lot of people are running intensive calculations all day. My day-to-day usage is 90% thinking/planning/writing/reviewing code and maybe 10% of time spent on running that software.
There are two factors that blow up Apple's aarch64 chips above the competition: false comparisons ($1000 cobbled-togerher PCs versus $3000 Macbooks) and Enterprise Hardware vendors like Dell and Lenovo raising their prices to match Apple's without the hardware or software to match (i.e. $2000 Thinkpad workstation laptops that are slow, overheat, and draw huge amounts of power, but are priced as "workstations" because they have a GPU with fp64 support).
For the people who spend a lot of money on a computer for the first time, Apple's aarch64 chips are more likely to be a good deal than the treacherous landscape of high-end laptops and prebuilts. Even in Apple's price, competing range vendors still dare sell 1080p60 displays. Buying desktop/workstation units, 10gbps ports seem to be made of solid gold and actual, full-speed Thunderbolt/USB4 support is restricted to one specific port, often placed at an inconvenient location.
You can exceed Apple's performance in general and their performance-per-dollar as well, but it requires time and attention to look through marketing bullshits and hidden-away spec sheets. That's especially the case now that every store page has four popups about "AI" and "NPU" and "Copilot" for some absurd reason.
> I really hope Framework or someone else changes that in the coming years.
Building a custom CPU like Apple Silicon is plain impossible for a company like Framework. The best they can do is have support for ARM motherboards and sell those with the best CPUs on the open market.
Specifically the M series from Apple have a very wide, very fast interface to DRAM, which is connected to DRAM chips soldered basically next to the CPU. That makes it possible to use the entire unified RAM as the GPU RAM, and reasonably run decent ML models (for code, text, audio, pictures) locally. No CUDA, no kilowatt power supplies. This is the real differentiator.
> That makes it possible to use the entire unified RAM as the GPU RAM, and reasonably run decent ML models (for code, text, audio, pictures) locally. No CUDA, no kilowatt power supplies. This is the real differentiator.
That might be relevant and a differentiator in your circles; it is entirely irrelevant in mine. Plain basic integer performance wins here.
> any high end Ryzen will blow an ARM64 chip out of the water
I'm very skeptical about this. I've read that many benchmarks show ~40% better performance per watt on ARM than the best x64 machines. Do you have any sources that say differently?
Performance per watt isn't the same as performance. On the high end (think Threadripper), amd64 still wins most performance tests by having many high-performance cores working all at once (at the cost of single-core performance).
I disagree with "any high-end Ryzen" blowing an ARM64 chip out of the water, though, it takes quite a beefy CPU to beat an M4 Max.
> 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.
I just looked into that for this thread, but the highest-end Apple chips (M4 Max/M5) outperform the fastest normal Ryzens in both single core and multi core tests.
They're awful for gaming, which most benchmarks online are run for, but it takes a Threadripper to dethrone Apple's impressive CPU performance.
Of course, this also has to do with their integrated memory architecture, which isn't very popular with high-end PC customers who like the ability to upgrade their RAM.
It is hard to compare apples to oranges, sometimes people benchmark different software (e.g. Safari on osx vs Edge on windows) or software that on one platform is more optimised. But in general it looks like AMD despite using an older process node is doing fairly good.
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.
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.
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
Maybe with games from 2004 and the like, the ones built to run with a single thread. With ntsync (and previously, esync/fsync) that's not true anymore with games designed for multiple cores.
Why are you using a scam crypto browser?
Brave does fall under crypto, yeah, but I don't know about it being a scam. You don't need to engage with the crypto/web3 and all of those can be disabled.
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.
Technically any software abstraction layer can have bugs (security or otherwise.) That doesn't mean we should abandon higher level abstractions.
If the bsd posix equivalent is the highest layer your willing to use, you'll miss out on some great software.
Theo de Raadt, 2010, on the removal of emulation: “we no longer focus on binary compatibility for executables from other operating systems. we live in a source code world.”
(Since then, OpenBSD has gained support for virtualization for some operating systems including Linux, through the vmm(4) hypervisor.)
> Linux: Win32 is the only stable Linux ABI :(
> OpenBSD: Whatever the C compiler produced last is the only OpenBSD ABI :D
FreeBSD used to have compat libraries for old FreeBSD releases itself. With NetBSD it used to be the same.
OpenBSD, well, by policy running old, insecure binaries it's basically a no-no.
Imagine my surprise when I removed these in the kernel-conf, and then the 3C905 didn't work anymore, because it relied on these!
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.
Sometimes it's better to have some discomfort now if it means there is a better chance of things working properly in the future.
Making your life a little easier without having a bigger picture is how you get trapped in local optimums.
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.
I was just saying, is your goal for the os to get out of the way so you can get a job done, or is your job tinkering with your os. I've ran opensense which is a freebsd derivative, and I daily macOS/Darwin which is bsd. Honestly until I need to mess with some systemctl flags I get the same experience from bsd and Linux. Posix and all...
macOS is not BSD. It's a common misunderstanding, it borrows some userland but the kernel is radically different.
But yeah my OS should get out of the way but I don't mind investing a little time in getting things working right. That includes picking the right tools. I was looking for a notetaking app and one of them was like 'just use the compatibility layer'. I think it was notesnook. I just picked obsidian instead which has a port. Still not ideal as it's electron but pretty much all these notetaking apps seem to be electron somehow. And I needed compatibility with android too.
If there's something I could really not do without I would consider it but there's nothing like that right now.
> macOS is not BSD
No. This is a common contrarian take, but it's nonsense. macOS is built on Darwin which, along with XNU, traces its lineage through NeXTSTEP to 4.3BSD.
macOS is every bit as much of a BSD derivative as FreeBSD is.
I'm aware of its lineage but there's really precious little left from its BSD origins.
https://github.com/apple-oss-distributions/xnu/tree
You'll find there's a great deal left. Have a look at all the fundamental datastructures (proc, vnode, tty, file to name a few) for a starting point.
"Nonsense" is a strong word ;-)
Here's a contrarian-squared take: in reality, the question "Is macOS a BSD" is malformed. It makes some sens, but is more confusing than it's worth.
Yes, NeXT was built on Mach, which was itself basically an evolution of the Accent microkernel married with BSD, when BSD was a proper noun.
In fact, NextStep 0.8, the first public "pre-release", has left support in for A.OUT executables. The included ex and vi binaries are indeed A.OUT executables taken straight from BSD! In the very next release, support for A.OUT was removed, leaving only the Mach-O loader.
XNU is not derived from the Mach that NeXT was, though, but from the OSF Mach kernel, which was continued at the University of Utah. The BSD "bits" were selectively copied from the extent continuations of BSD, or rewritten from scratch. The XNU kernel doesn't strongly resemble any particular *BSD tree, to my knowledge.
Darwin's origins are messier, since it looks like it was a direct continuation of the existing NeXT packaging (but only Apple would know for sure). NeXT, very much unlike BSD, split its userland into distinct packages, which were versioned independently. This practice has carried on to this day, where e.g. Darwin's libc is packaged and versioned separately from the kernel and other utilities.
For that matter, for a very brief period of history, Darwin used Debian's dpkg for building and installing packages. Evidence of this stayed until OS X 10.4-ish, in the Darwin releases, but they returned to NeXT style BOM files for package management.
All that to say, does NeXT/macOS have a BSD-like userland? Yes, but so does Chimera Linux. Does the kernel resemble BSD? In some ways yes, but in many ways no, it's very semantically different.
And is it descendant from BSD? Again, "yes", but it also doesn't really "come" directly from BSD anymore than, say, OSF/1 did. There's no specific BSD it forked from, and no specific point at which it ever really looked like BSD, in terms of userland, packaging, or kernel semantics.
So I think the question just doesn't make much sense to ask.
It is a BSD. It has always been a BSD.
Saying "It's not like a *BSD" is a category error.
Is a wolf not a dog just because it's different from dog breeds with "Dog" in the name?
More succinctly:
- Darwin has no direct BSD ancestor. Unlike {Net,Free,Open}BSD and the more obscure ones (Bitrig, anyone?) there was never a point in time where it directly "connects" to the BSD lineage. The other BSDs all can trace their repositories back to CSRG's BSD.
- Darwin isn't stored or built like a BSD. The BSDs have massive monorepos containing all of the source, traditionally checked out to /usr/src, while Darwin is split into many independently versioned packages, (usually) compiled with Project Builder/Xcode.
Yes, the C API is derived from and supposed to resemble BSD, and much of the userspace was copied from a BSD-derivative (this has grown over time, as Apple (and the BSDs) replaced GNU utilities).
But that's why I would call macOS/Darwin "BSD-like" or "BSD-derived" rather than "a BSD".
Also, this isn't meant to be taken too seriously. I just like "OS taxonomy", and I think macOS/Darwin is distinct enough to qualify as a separate species ;-)
It's rather a bit more BSD than merely having a "C API that resembles BSD" or a "BSD userland".
https://github.com/apple-oss-distributions/xnu/tree/main/bsd
You can find there the better part of a whole BSD kernel, including the fundamental datastructures like proc, tty, vnode, and user.
The point of departure is 4.4BSD-Lite2. The majority of the core of the BSD kernel carries the relevant notices for that.
Yeah, I probably went too far in saying it's just the userland, but I'll insist it's more complicated than saying it was based on 4.4BSD-Lite2. I haven't done a proper deep dive yet, but I can tell that it wasn't strictly based on the Lite2 release. Take a look at XNU 123.5's (OS X 10.0) kern/tty.c:
https://github.com/apple/darwin-xnu/blob/xnu-123.5/bsd/kern/...
Notice the SCCS version info dates the file 1/21/94. Now look at the Lite2 equivalent:
https://github.com/sergev/4.4BSD-Lite2/blob/master/usr/src/s...
The SCCS date on this file is 1/9/95, a year later. It appears the XNU copy is from Lite1 instead:
https://github.com/dspinellis/unix-history-repo/blob/BSD-4_4...
You'll also see the source has been reorganized, with e.g. the VFS source being regrouped into bsd/vfs, instead of being left in bsd/kern. This coincidentally mirrors how OSF/1 was organized (no other source relation though, just an interesting observation):
https://github.com/Arquivotheca/OSF1/tree/OSC200/src/kernel/...
For that matter, compare the the differences between vfs_bio.c in XNU:
https://github.com/apple-oss-distributions/xnu/blob/rel/xnu-...
With Lite2's, where most function bodies have been replaced with the comment "Body deleted.", presumably due to use of encumbered code:
https://github.com/sergev/4.4BSD-Lite2/blob/master/usr/src/s...
This file had to be reimplemented by all of the BSDs. In this case, this version appears distinct from the FreeBSD and NetBSD versions I can find.
If you grep around for the `NeXT` ifndef/ifdefs in XNU, too, you'll see some code of which some appears to have been copied/adapted from the NeXT source tree, itself derived from Mach/CMU sources. (and 4.3BSD ;-)
I say all this to draw attention to the ways XNU differs from BSD, which is pretty interesting, at least to me.
No person acting in good faith can argue that having similarities to 4.3BSD-Lite1 or 4.3BSD-Reno (the basis for OSF/1) make something less of a BSD.
These are not ways it "differs from BSD." These are ways it is identical to BSD.
That's objectively false. You're just trolling at this point.
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,....
Valve tried really hard to steer the world into native Linux ports, it simply didn't pan out, that ship has already sailed.
And now is subject to the whims of Microsoft, wherever Windows, DirectX, Visual Studio go, Valve must follow.
Additionally, everyone is betting on Valve as if Steam would be around forever serving Linux gaming with Proton, except no one lives forever, and who knows what will happen to Valve, when current management passes the torch.
I'm running macOS because it runs desktop applications, and the macOS desktop itself, fairly well.
But I wouldn't mind if macOS (a BSD-flavored Unix) added support for linuxlator, and jails, pledge, and various other BSD-flavored things.
"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"
Am I wrong?
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.
Compare an M1 MacBook to one of its Intel predecessors. It’s not just software.
But you should compare it to a present day Intel system, and you should then also ask Apple to make the same optimizations...
I know, it's a difficult comparison. But OP stating "I just want ARM" will disappoint for any non Apple ARM (at the moment, I'd say due to software).
You should be comparing to AMD, at that. There's hope for the upcoming Intel chips - but anything current isn't competitive. Furthermore, M* is good for a specific form-factor, but don't for a second suggest that 4 P-Cores will outdo the 16 hyper threaded cores on a 9950x
The only like for like comparison you can do is comparing an M1 MacBook to one of its Intel Mac contemporaries (which were present day Intel systems at the time).
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 need an ARM64 machine. Period.
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 need an ARM64 machine. Period.
>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.))
amd64 definitely beats any aarch64 when it comes to performance, but the trick Apple (and if proper Linux driver support ever lands, Qualcomm) pull is that they get 80% of amd64 performance at 25% of the battery cost.
Not a lot of people are running intensive calculations all day. My day-to-day usage is 90% thinking/planning/writing/reviewing code and maybe 10% of time spent on running that software.
There are two factors that blow up Apple's aarch64 chips above the competition: false comparisons ($1000 cobbled-togerher PCs versus $3000 Macbooks) and Enterprise Hardware vendors like Dell and Lenovo raising their prices to match Apple's without the hardware or software to match (i.e. $2000 Thinkpad workstation laptops that are slow, overheat, and draw huge amounts of power, but are priced as "workstations" because they have a GPU with fp64 support).
For the people who spend a lot of money on a computer for the first time, Apple's aarch64 chips are more likely to be a good deal than the treacherous landscape of high-end laptops and prebuilts. Even in Apple's price, competing range vendors still dare sell 1080p60 displays. Buying desktop/workstation units, 10gbps ports seem to be made of solid gold and actual, full-speed Thunderbolt/USB4 support is restricted to one specific port, often placed at an inconvenient location.
You can exceed Apple's performance in general and their performance-per-dollar as well, but it requires time and attention to look through marketing bullshits and hidden-away spec sheets. That's especially the case now that every store page has four popups about "AI" and "NPU" and "Copilot" for some absurd reason.
> I really hope Framework or someone else changes that in the coming years.
Building a custom CPU like Apple Silicon is plain impossible for a company like Framework. The best they can do is have support for ARM motherboards and sell those with the best CPUs on the open market.
I’m hearing good things about Snapdragon nowadays. I’ll certainly give it a try in a bit.
Specifically the M series from Apple have a very wide, very fast interface to DRAM, which is connected to DRAM chips soldered basically next to the CPU. That makes it possible to use the entire unified RAM as the GPU RAM, and reasonably run decent ML models (for code, text, audio, pictures) locally. No CUDA, no kilowatt power supplies. This is the real differentiator.
Notably, this is also Qualcomm's X2 architecture.
> That makes it possible to use the entire unified RAM as the GPU RAM, and reasonably run decent ML models (for code, text, audio, pictures) locally. No CUDA, no kilowatt power supplies. This is the real differentiator.
That might be relevant and a differentiator in your circles; it is entirely irrelevant in mine. Plain basic integer performance wins here.
>> performance and battery life
> any high end Ryzen will blow an ARM64 chip out of the water
I'm very skeptical about this. I've read that many benchmarks show ~40% better performance per watt on ARM than the best x64 machines. Do you have any sources that say differently?
Performance per watt isn't the same as performance. On the high end (think Threadripper), amd64 still wins most performance tests by having many high-performance cores working all at once (at the cost of single-core performance).
I disagree with "any high-end Ryzen" blowing an ARM64 chip out of the water, though, it takes quite a beefy CPU to beat an M4 Max.
> it took 5–10 minutes just to open a file
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.
> 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.
I just looked into that for this thread, but the highest-end Apple chips (M4 Max/M5) outperform the fastest normal Ryzens in both single core and multi core tests.
They're awful for gaming, which most benchmarks online are run for, but it takes a Threadripper to dethrone Apple's impressive CPU performance.
Of course, this also has to do with their integrated memory architecture, which isn't very popular with high-end PC customers who like the ability to upgrade their RAM.
Are you sure? Top searches for M5 vs Ryzen:
https://nanoreview.net/en/cpu-compare/apple-m5-vs-amd-ryzen-...
https://www.cpu-monkey.com/en/compare_cpu-apple_m5_10_cpu-vs...
It is hard to compare apples to oranges, sometimes people benchmark different software (e.g. Safari on osx vs Edge on windows) or software that on one platform is more optimised. But in general it looks like AMD despite using an older process node is doing fairly good.
For the most part, yes, which is why he's using a Mac as his daily driver, and ssh'ing into the BSD box
I'm curious OP, what are you doing with openwrt? Does it have anything to do with openWISP??
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.
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
Linuxulator feels like magic for most things, until said thing works with systemd.
Then it feels like black magic
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.