Other FreeBSD look and feel on a major Linux like Debian?

I have this idea that I thought that Linuxulator is great when it runs a Linux program. But there exists programs which do not work with Linuxulator or are not developed with Linuxulator or FreeBSD in mind.

So when such software exists, I want to use Linux, because the program is made for it.

However, could there then exist a middle ground so that one could run Linux software, but feel similar to when using FreeBSD?

E.g. a Cygwin-like thing for, say, Debian where one can have FreeBSD terminal commands etc.

Any inputs on whether such has any real demand?
 
I run a laptop which has also Debian installed. That was from the time where the hardware did not work using FreeBSD. I do not use Linuxulator.
However, could there then exist a middle ground so that one could run Linux software, but feel similar to when using FreeBSD?

E.g. a Cygwin-like thing for, say, Debian where one can have FreeBSD terminal commands etc.
Beside a few options which might be different depending on the "incarnation" as GNU-extensions or not, the programms work similar from my user perspective. I guess that the Linuxulator - whatever that is - should not change that.
 
I run a laptop which has also Debian installed. That was from the time where the hardware did not work using FreeBSD. I do not use Linuxulator.

Beside a few options which might be different depending on the "incarnation" as GNU-extensions or not, the programms work similar from my user perspective. I guess that the Linuxulator - whatever that is - should not change that.

There are certainly going to be programs that will not run on the Linuxulator. Android Studio is one.

Do you like this ?


Yes, I was thinking of the Cosmopolitan Libc as a way to ensure a compatibility between a Linux and FreeBSD. However, there will certainly be programs that will not want to limit to such, but rather might use Linux features not available in Linuxulator. Then I would want to run the program, but feel more like running FreeBSD, even if it's Debian. So I could, for example, want to feel like I am working with Ports, even if it's really apt.
 
There are certainly going to be programs that will not run on the Linuxulator. Android Studio is one.
I believe javac, adb, aapt and Android NDK (clang) work fine. So you can still build Android apps on FreeBSD, just you will need to find a different text editor.
Then I would want to run the program, but feel more like running FreeBSD, even if it's Debian. So I could, for example, want to feel like I am working with Ports, even if it's really apt.
You can get a BSD userland (i.e BSD replacement of GNU coreutils) using:

https://github.com/dcantrell/bsdutils

Basically, something like Alpine Linux + BSDUtils would feel a little closer

For a ports clone, you can install PkgSrc (from NetBSD) on Linux:

https://pkgsrc.org/

Though be aware that loads of stuff won't have the correct patches required to build successfully.
There is also this project which is apparently meant to provide a more BSD userland:

https://chimera-linux.org/

Though it seems to have much more of a focus on desktop environments compared to most actual BSD projects.
 
Yes,me too. I did some tests some months ago and they failed. I haven't been able to understand what to do. And Jart didn't reply to my questions. It sounds too much complicated for me to have a good start.
 
The bhyve recommendation looks promising, and possibly it's possible to develop Android on FreeBSD too, but the core issue here is not the possibility, but that having Linuxes and FreeBSD not share goals would mean that there will be times of no guaranteed compatibility. Then it makes more sense to run each OS natively, rather than attempt to emulate, or run the OS that the software's devs targeted.

I do not know about you, but I am still a bit lost as to the real benefits of Linuxulator etc. Nice to have, but why cannot one just run the real thing for software that's Linux-only (such as many drivers)?

If same issues are true for bhyve as for e.g. VMWare etc., then there will still be programs that will not work or will not work as efficiently etc.

Chimera Linux? Well, will it build and run existing Linux apps? Void Linux looked good too, but it hardly works with .debs etc.

One possible issue is having double standards. Rather than having to read only Debian docs or FreeBSD docs, one would then need to also read this "FreeBSD-Debian"'s docs, unless the translation from it to Debian is straightforward. OTOH, if such layer would work properly, it would simplify the lives of people who use predominantly FreeBSD, but sometimes need an alternative runtime for certain programs.

Ultimately one could also run a separate computer for a Linux and just use it through a KVM in FreeBSD.

I am not an expert on the topic, but I believe that virtualizations etc. will always be dissimilar to the native OS.
 
However, could there then exist a middle ground so that one could run Linux software, but feel similar to when using FreeBSD?
Problem is this is very, very subjective. What does qualify as "feel simiar to FreeBSD"? Everybody has its own criteria for that. I could argue that from user perspective they are very similar - console, X, many commands are the same, some alike...

Last time I used linux ABI on FreeBSD was when I wanted to run skype, that was almost 20 years ago. I understand the benefit of it in general, it's just not for me.

I can't give you advice what to run, I can only share what I do. If my workload requires me to use Linux I use Linux. I don't force, hack around and waste my time trying to make it somewhat work on FreeBSD if it's not ment to be there. I waste my time on other stuff ;-). At home my FreeBSD boxes are only virtual, most of my benefits stem from qemu/kvm and/or native tools I want to run on Linux.

You could use bhyve/VirtualBox and install Linux VM and benefit from both worlds. But in the past I did have issues passing through USB devices (jlink debugger) to VM. It was just not worth it.

And then, there's the good oldie - dual boot.
 
Problem is this is very, very subjective. What does qualify as "feel simiar to FreeBSD"? Everybody has its own criteria for that. I could argue that from user perspective they are very similar - console, X, many commands are the same, some alike...
Ultimately that the userland behaves as much like FreeBSD, even if the OS is Debian and the kernel is Linux?

Yes my use case is essentially similar. I have software that is developed for Debian and software that is developed for FreeBSD. I do not believe that any sort of virtualization layer will work 100% of the time, so I prefer to run both natively. But while doing this I also want some "common layer" between them. One such is that one could make the other feel like the other so that one doesn't have to memorize different console commands etc.

Rather, I could e.g. write a FreeBSD console command on Debian and find that it calls whatever the thing is really called, even if I used a FreeBSD convention for calling it. How much this benefits is up to debate of course. Possibly I could also use FreeBSD shell scripts directly on Debian using such layer. Then I could test deploying things on both systems while using common scripts, even if the underlying implementations or binaries are different.

Ultimately I'd like a React Native kind of thing of native OSes tbh.
 
Ultimately that the userland behaves as much like FreeBSD, even if the OS is Debian and the kernel is Linux?
Yes and no, depending on your definition. ls behaves /almost/ the same on both. WM will give you very alike experience too. python/perl/.. scripting would be the same too.
But no, it does things differently under the hood and you can't ignore that.

In the end they are different OSs so you do need to be familiar with both of them. How much depends on your workload -- that basically defines all your needs.
 
Yes and no, depending on your definition. ls behaves /almost/ the same on both. WM will give you very alike experience too. python/perl/.. scripting would be the same too.
But no, it does things differently under the hood and you can't ignore that.

In the end they are different OSs so you do need to be familiar with both of them. How much depends on your workload -- that basically defines all your needs.
Yes, but this is still far less than what's required in order to use Linuxulator effectively or in order to port software between the two OSes.

E.g. since Android Studio already runs on Linuxes, then I find that attempting to run it on FreeBSD is not worth the effort. Not unless Google or something begins to support it officially.
 
I do not know about you, but I am still a bit lost as to the real benefits of Linuxulator etc. Nice to have, but why cannot one just run the real thing for software that's Linux-only (such as many drivers)?

The Linuxulator doesn't run a Linux kernel and drivers are in the kernel.

It's not that we wouldn't like to run all Linux software, including drivers, but the effort to write a Linuxulator that can do that is great.

In addition the interface between the Linux kernel and Linux drivers constantly changes, so any FreeBSD effort would have to be updated as well. And since most Linux drivers are GPLed they wouldn't find their way into the FreeBSD source tree either way.
 
I do not know about you, but I am still a bit lost as to the real benefits of Linuxulator etc. Nice to have, but why cannot one just run the real thing for software that's Linux-only (such as many drivers)?

The Linuxulator is just a system call translator that allows running Linux binaries on FreeBSD, unmodified. Because the Linux community doesn't care to write portable software, third party developers are forced to use linux centric services and interfaces. Just look at the software hosted under freedesktop.org and you'll see what I mean. When you install a typical application from ports; you're likely to grab a bunch of Linux cruft along with it, in order for it to work on FreeBSD. The FreeBSD community isn't responsible for that design flaw.
 
Chimera Linux? Well, will it build and run existing Linux apps?
Yes. Because it is linux.

The Linuxulator is quite close in concept to Wine. It wont work with drivers but it can sometimes work well enough to run software you need so that you can avoid fscking around with Linux (or Windows). They both work well enough to be able to build / develop Android apps. Especially since FreeBSD has a native adb in ports for debugging via USB (also remember that adb can be set to communicate via TCP).

Void Linux looked good too, but it hardly works with .debs etc.
Is .deb support another requirement? Quite a trivial one to extract them and get the files out.

Though this is verging dangerously close to the concept of "I can't run XXXX because it isn't Debian". You will never find a solution to that problem unless you run... Debian.
 
Yes. Because it is linux.
No, because file paths and names etc. can still change between distros. So while it should technically run, it could still require a large porting effort compared to running the software on the distro it was written for.

The Linuxulator doesn't run a Linux kernel and drivers are in the kernel.

It's not that we wouldn't like to run all Linux software, including drivers, but the effort to write a Linuxulator that can do that is great.

In addition the interface between the Linux kernel and Linux drivers constantly changes, so any FreeBSD effort would have to be updated as well. And since most Linux drivers are GPLed they wouldn't find their way into the FreeBSD source tree either way.
Yes, so what's the second best thing in such case? I proposed to make Debian feel like FreeBSD. So even when one cannot alter the runtime, one could at least feel like not using Linux.
 
Yes. Because it is linux.
[...]
Is .deb support another requirement? Quite a trivial one to extract them and get the files out.
I think the main issue here might be musl, which could be troublesome if you don't know what you're doing and are seeking an OOTB experience.

Though this is verging dangerously close to the concept of "I can't run XXXX because it isn't Debian". You will never find a solution to that problem unless you run... Debian.
Agreed.
 
I think the main issue here might be musl, which could be troublesome if you don't know what you're doing and are seeking an OOTB experience.
Perhaps. Though I believed they were referring to Void Linux at that point which supports both musl and GNU libc.

As per Alpine (which is also musl), one note that might be useful is that the gcompat layer works well for all Android tools minus javac itself. But luckily Alpine has a native openjdk. The more layers the better!: Linuxulator -> Alpine -> gcompat.

OOTB experience is a very "dynamic" thing for both Linux and BSD ;)

No, because file paths and names etc. can still change between distros. So while it should technically run, it could still require a large porting effort compared to running the software on the distro it was written for.

Its not really so bad. In my experience, environment variables such as PATH and LD_LIBRARY_PATH resolve much of that. And besides, different versions of Debian also move things around. One of mainstream Linux's best features is trying to copy UNIX which has a mostly consistent Filesystem Hierarchy.
For 3rd party, out of tree software on Linux (i.e Chrome, Firefox, Android *DK), they tend to be more self-contained / statically linked anyway, minimizing the issue further.
The biggest issue is when library versions don't match. But this means that the API is fundamentally incompatible, in which case a build of the specific version is needed anyway for all Linux.
 
One is also not guaranteed that what is done now will remain compatible. If Linux wanted FreeBSD support, then the Linux community would also produce it.

Therefore I thought that the least effort is just a thin user space translation layer. Like a FreeBSD to Linux auto-dictionary. While continuing to use both OSes as separate things.

I don't really hate Linux overall, but there are parts like FreeBSD having nicer user experience, which I do not like to lose.
 
I don't really hate Linux overall, but there are parts like FreeBSD having nicer user experience, which I do not like to lose.
Can you specify which parts you're referring to?

Rather, I could e.g. write a FreeBSD console command on Debian and find that it calls whatever the thing is really called, even if I used a FreeBSD convention for calling it. [...] Possibly I could also use FreeBSD shell scripts directly on Debian using such layer.
[...]
Therefore I thought that the least effort is just a thin user space translation layer. Like a FreeBSD to Linux auto-dictionary. While continuing to use both OSes as separate things.
Sticking to POSIX? If it's not enough, then what's wrong with bsdutils mentioned earlier by kpedersen?
 
Nothing. In fact bsdutils sounds very similar to what I had in mind here. Maybe someone could want more though.

E.g. I think the file system of FreeBSD is much cleaner.

Possibly, someone would want to alias a Debian file system so that it looks like FreeBSD's.

Also, like I said earlier, it would be nice if one could use the same bash scripts for Debian and FreeBSD.
 
but that having Linuxes and FreeBSD not share goals
That's a funny way to put it... KDE runs on both Linux and BSDs, and provides convenient features. The web services stack (Apache/MySQL/PHP) also runs fine. LibreOffice runs fine, with very minimal patching needed for compilation. Even Perl/Python/Ruby/whatever.

If the goal is to provide a set of userland software that is easy to install and run, that goal is already accomplished pretty nicely.

If the goal is for both to use systemd to boot - nah, don't bother.

If the goal is to run each other's binaries - virtualization software is already available (albeit with FreeBSD lagging a bit - VBox is on v. 6.1 in ports, while on Linux, it's past v. 7. Yeah, there are reasons for that, but long story short, even 6.1 works pretty adequately.


Possibly, someone would want to alias a Debian file system so that it looks like FreeBSD's.

I don't see how this can work.
You can use NFS for that... NFS daemon is part of FreeBSD's base, too, just read the Handbook before complaining that FreeBSD can't do something. The NFS chapter is here: https://docs.freebsd.org/en/books/handbook/network-servers/#network-nfs
 
That's a funny way to put it... KDE runs on both Linux and BSDs, and provides convenient features. The web services stack (Apache/MySQL/PHP) also runs fine. LibreOffice runs fine, with very minimal patching needed for compilation. Even Perl/Python/Ruby/whatever.
Yes, because you only look at software which is too fundamental so that it's available for nearly all platforms. But without truly common APIs you will get programs that even the Linuxulator will not run.

However, if one can use software on Debian with FreeBSD-like userland, then the problem is almost solved already for most users who only really care about the user space part.

Virtualization is okay, when the software works reasonably with it.

So with enough interest I would still personally recommend working out a "FreeBSD user space" on Debian. It is possibly even more standards conformant, because I believe Linuxulator is not really endorsed by the Linux community, which is also demonstrated by the fact that Linuxulator does not implement all calls.

Possibly, in a larger scheme one could also study the possibility of hosting a minimal Linux kernel on a small computer only for the missing kernel functions.

POSIX would be a solution, if it was followed.

---

Also in some sense I have already begun to believe that Linux is generally far more useful for desktop at least, so then my question is about how to make FreeBSD viable at all for desktop.
 
Back
Top