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.

▲ vermaden 4 hours ago | parent | next [-]

    > (are those different?)

Its the same thing - just different naming.

    > 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.

Hope that helps.

[1] https://freebsd.org/press/press-rel-1/

[2] https://youtube.com/watch?v=lK6eRbz9DkM

	▲	jabbywocker 4 hours ago \| parent [-]
		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

▲ drzaiusx11 4 hours ago | parent | prev | next [-]

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.)

	▲	tomth 3 hours ago \| parent [-]
		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.

▲ wutwutwat 4 hours ago | parent | prev [-]

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.

▲

wolvoleo 4 hours ago | parent [-]

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.

▲

wutwutwat 3 hours ago | parent [-]

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...

▲

wolvoleo 3 hours ago | parent [-]

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.

▲

torstenvl 2 hours ago | parent [-]

> 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.

▲

wolvoleo 2 hours ago | parent | next [-]

I'm aware of its lineage but there's really precious little left from its BSD origins.

	▲	netbsdusers 11 minutes ago \| parent [-]
		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.

▲

spijdar 2 hours ago | parent | prev [-]

"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.