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

mavavilj said:
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.
Click to expand...
Nothing quite says "fundamental" like LibreOffice ;)

No. This is available for nearly all platforms because a *shedload* of work is spent porting and maintaining it. If you want desktop-centric software on FreeBSD, then you need to port it.
mavavilj said:
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.
Click to expand...
Absolutely. And Windows is commonly cited as being better still. Both of those solutions are easily available to you if all you want is a desktop which matches your personal set of expectations.
 
kpedersen said:
No. This is available for nearly all platforms because a *shedload* of work is spent porting and maintaining it. If you want desktop-centric software on FreeBSD, then you need to port it.

Absolutely. And Windows is commonly cited as being better still. Both of those solutions are easily available to you if all you want is a desktop which matches your personal set of expectations.
Click to expand...
Well, but why don't begin to make Linux more like FreeBSD instead of throwing Linux to FreeBSD? For mainstream desktop users at least.
 
mavavilj said:
Well, but why don't begin to make Linux more like FreeBSD instead of throwing Linux to FreeBSD? For mainstream desktop users at least.
Click to expand...
I agree with the idea in principle. But I suspect it is not feasible, the Linux community are too full of bad ideas which are almost completely orthogonal to BSD. Things in the GNU world tend to be large and tangled rather than small and simple.

Put another way, if you do put some great work in to achieve this, it likely wouldn't be uptaken with the wider Linux ecosystem so you will still end up with incompatibilities with Linux-centric software. Alpine is a good example of having to maintain compatibility themelves due to:
  • busybox rather than GNU coreutils
  • musl rather than gnu libc
  • openrc rather than systemd
  • mdev+eudev rather than systemd
  • mkinitfs rather than dracut
  • many, many more
This work alone is a considerable amount. If you don't move *with* Linux, then you certainly don't get an easy ride.

But as I said, I do like the concept. Linux userland is disgusting and if we can ditch it whilst still benefiting from the kernel, I would certainly explore it. I think things like Debian GNU/kfreebsd went the wrong way round; we don't want the Debian GNU shite, we just want the Linux kernel whilst keeping the BSD userland!
 
It is also possibly wrong to believe that one needs to mirror FreeBSD in Linux. Rather, make Linux outwardly more like FreeBSD. So issues like "it's too large or the wrong shape" are not faults, but something that such "FreeBSD on Linux" layer would need to solve and live with. But it doesn't mean that one's goal is necessarily to replicate FreeBSD on Linux, but carve a "LinuxBSD" command line and what not. Like Cygwin etc. do in Windows. One's goal is more about "FreeBSD-like environment on Linux", not "make Linux into FreeBSD".

When it comes to portability, then Cosmopolitan libc etc. are about it, but this is a different problem. I was not necessarily discussing portability of low-level sources or binaries here, but user experience. I would not care how the software is built or what it runs on, but I would care it to feel similar in usage in both OSes. In this case also the same user space scripts would be nice.

Compare to:

en.wikipedia.org

Cygwin - Wikipedia

en.wikipedia.org en.wikipedia.org
 
kpedersen said:
I think things like Debian GNU/kfreebsd went the wrong way round; we don't want the Debian GNU shite, we just want the Linux kernel whilst keeping the BSD userland!
Click to expand...
How is that the kernel isn't shite as well? :)

mavavilj said:
I was not necessarily discussing portability of low-level sources or binaries here, but user experience. I would not care how the software is built or what it runs on, but I would care it to feel similar in usage in both OSes. In this case also the same user space scripts would be nice.
Click to expand...
There are many abstract concepts in this thread already, so may I ask one more time: do you have any real examples of any particular issues in mind? I mean, in your experience, with concrete examples like "I tried to run this thing but failed because of these errors". How can we discuss any potential solution to a problem that is not clearly defined?
 
I think the best approach is the Linux kernel with the FreeBSD userland. Isn't this the approach used by Chimera Linux ? What's wrong with it ?
 
mavavilj said:
It is also possibly wrong to believe that one needs to mirror FreeBSD in Linux. Rather, make Linux outwardly more like FreeBSD.
Click to expand...

Don't forget that when we talk about Linux,we are talking about its kernel. So,it has perfectly sense to use a FreeBSD userland with the kernel Linux.
 
eseipi said:
How is that the kernel isn't shite as well? :)
Click to expand...
Based on the rest of the Linux ecosystem, it probably is. But I think its because I rarely deal with it directly. I interact with programs instead that hide the mess.

Plus, I have to admit, the kernel is a great driver dump. These days I actually find Linux has better hardware support than Windows for the kinds of hardware I end up with. I would love a mystical way to "bolt" the driver parts of Linux onto BSD.
 
kpedersen said:
programs instead that hide the mess.
...
to "bolt" the driver parts of Linux onto BSD.
Click to expand...
This is one way to look at this. However, what other ways to accomplish it are there than creating a FreeBSD-like "lens" on that thing that moves chaotically? There are Linux drivers that are undocumented, and the driver exists mostly only for Linux, so their porting is impossible or very difficult. Further, porting is not worth anything, if one can use it via Linux instead.

The Linux community does move in an unorganized way, but rather than expecting to make the community behave like FreeBSD's, I think it's better to understand that Linux's strong point is that there is undocumented code and a collection of random projects. It reflects one model, and that model seems to at least progress far faster than FreeBSD's. So I think, respect the Linux model, but implement a way to view and use it through a different lens. Best of both worlds?

The bolting would probably be feasible, in theory. However in practice it seems that some Linux driver writer does not care about FreeBSD compatibility. While it could be possible to port it, then does it really add to much?

These people seem to think that Chimera Linux is that thing:

Chimera Linux: a Linux distribution based on FreeBSD userland and LLVM | Lobsters

lobste.rs lobste.rs

Chimera Linux - About

Chimera Linux
chimera-linux.org chimera-linux.org

www.theregister.com

Chimera – a Linux that <em>isn't</em> GNU/Linux

FOSDEM: It's not yet reached alpha, but it's already breaking new ground
www.theregister.com www.theregister.com
Chimera is an attempt to bring some of that design clarity to Linux. It's not all FreeBSD all the way down: this is still a Linux-based OS, and it remains binary-compatible with Linux. In a way, Chimera is the inverse of the now unmaintained Debian GNU/kFreeBSD. That project put the GNU userland and Debian tools on top of a BSD kernel.
Click to expand...
We will see though, if it is too much to maintain.
 
mavavilj said:
This is one way to look at this. However, what other ways to accomplish it are there than creating a FreeBSD-like "lens" on that thing that moves chaotically? There are Linux drivers that are undocumented, and the driver exists mostly only for Linux, so their porting is impossible or very difficult. Further, porting is not worth anything, if one can use it via Linux instead.

The Linux community does move in an unorganized way, but rather than expecting to make the community behave like FreeBSD's, I think it's better to understand that Linux's strong point is that there is undocumented code and a collection of random projects. It reflects one model, and that model seems to at least progress far faster than FreeBSD's. So I think, respect the Linux model, but implement a way to view and use it through a different lens. Best of both worlds?

The bolting would probably be feasible, in theory. However in practice it seems that some Linux driver writer does not care about FreeBSD compatibility. While it could be possible to port it, then does it really add to much?

These people seem to think that Chimera Linux is that thing:

Chimera Linux: a Linux distribution based on FreeBSD userland and LLVM | Lobsters

lobste.rs lobste.rs

Chimera Linux - About

Chimera Linux
chimera-linux.org chimera-linux.org

www.theregister.com

Chimera – a Linux that <em>isn't</em> GNU/Linux

FOSDEM: It's not yet reached alpha, but it's already breaking new ground
www.theregister.com www.theregister.com

We will see though, if it is too much to maintain.
Click to expand...

One of my old projects was based to this idea :

Let's choose an almost recent phone that can be "hacked",in the sense that we can enable kvm on the linux kernel baypassing the level 1 hypervisor restriction (or level 2,I'm not sure) and then booting the Android / Linux kernel. With a kernel where we can enable kvm,we can also use qemu or bhyve to virtualize the FreeBSD kernel and userland on the same phone using only the parts of the Android code that we need. For sure the drivers,the rest of the OS can be cut and removed,because we don't need it if we want to run FreeBSD on that phone. We can't use Linux,speaking of phones,because Android has more drivers than Linux in this area. For sure,this approach is not for purist ; it does not allow FreeBSD to run natively on that phone,but it allows to boot and run using the boot code and the drivers. Its a matter of compromises. If at the moment we can't have exactly what we want,it's not correct that we don't want to try a temporary compromise. Not sure,but I suspect that this approach can be valid not only for phones,but also for handheld,notebook,netbook and some other interesting "mobile" middle devices.
 
For the average desktop user I would say:

How much does it matter whether this or that is Linux kernel or something else? For example, GNU/Linux is often quite inefficient, but since the difference for practical use is rather small, then who cares and when?

I could personally work fine with the Linux kernel and a virtualized FreeBSD user space, even if the user space would run even 20% slower than the native. Because it is likely still capable of 60 fps. On the other hand, I would get compatibility with Linux and e.g. Android to some extent.

Yes, it's about trade-offs one's willing to take and recognizing that it could be very, very difficult to match Linux drivers and software fully.

In a broader sense, I think it's a flawed goal to attempt to "compete" with Linux. Rather, one could respect the strengths of what is available.
 
mavavilj said:
But without truly common APIs you will get programs that even the Linuxulator will not run.
Click to expand...
Such as?

BSD userland programs (like ls, ld, rm, and more) are functionally equivalent to the GNU userland programs by the same names. Yeah, there's some differences in the exact source code implementations behind those userland programs, and a few differences in syntax rules, but come on, you'd need to know how to write compilers and assembler subroutines (oh, and know a bit of brainfuck) before you run into something that has not been ironed out to run on both platforms.

Oh, and hardware drivers in BSD are mostly provided by Linux anyway!
 
astyle said:
Such as?

BSD userland programs (like ls, ld, rm, and more) are functionally equivalent to the GNU userland programs by the same names. Yeah, there's some differences in the exact source code implementations behind those userland programs, and a few differences in syntax rules, but come on, you'd need to know how to write compilers and assembler subroutines (oh, and know a bit of brainfuck) before you run into something that has not been ironed out to run on both platforms.

Oh, and hardware drivers in BSD are mostly provided by Linux anyway!
Click to expand...

What's the % of the GNU code that actually is used in FreeBSD ?
 
ZioMario said:
What's the % of the GNU code that actually is used in FreeBSD ?
Click to expand...
I'm not a developer, and I certainly don't spend my time analyzing kernel code and asking questions like that. It would be a time-consuming effort for me to develop such a skill.

I've seen manpages for both sets of userland programs, they are slightly different.

And BTW, what metric are you using to determine "% of code" ? Is it LOC (Lines of Code), size of compiled modules on disk (relative to total size of on-disk installation or absolute), in terms of Gigibytes? or something else altogether?
 
astyle said:
Oh, and hardware drivers in BSD are mostly provided by Linux anyway!
Click to expand...

No, just some graphics and some wifi drivers.

The rest of the Linux drivers is GPLed and hence couldn't be used even if we wanted to go through the adaption effort.
 
cracauer@ said:
No, just some graphics and some wifi drivers.

The rest of the Linux drivers is GPLed and hence couldn't be used even if we wanted to go through the adaption effort.
Click to expand...
Well, surely by providing a GPL version of all of the FreeBSD tree too. But even that will not get around the fact that the Linux community does not seem to be focused on providing compatibility for FreeBSD.

superuser.com

Running FreeBSD binaries on Linux

In general, will binaries built on FreeBSD run on Linux operating systems, especially Ubuntu?
superuser.com superuser.com
 
Well. Maybe someone could want a similar thing for Windows too, but then it would not even be FOSS. I do not know how popular Cygwin is. But:

The brand motto is "Get that Linux feeling – on Windows"
Click to expand...
en.wikipedia.org

Cygwin - Wikipedia

en.wikipedia.org en.wikipedia.org

I am going to test Chimera Linux soon to see if it's better than Debian.
 
mavavilj said:
Well. Maybe someone could want a similar thing for Windows too, but then it would not even be FOSS. I do not know how popular Cygwin is. But:


en.wikipedia.org

Cygwin - Wikipedia

en.wikipedia.org en.wikipedia.org

I am going to test Chimera Linux soon to see if it's better than Debian.
Click to expand...

Some ideas : to emulate cygwin with wine on FreeBSD (with the help of Mizutamari) or use Chimera Linux with the Linuxulator instead of CentOS or Debian or Ubuntu...or even to see how well work the Ubuntu (or Debian) version shipped by Canonical for the WSL2 integrated with the Linuxulator...I see a lot of fun coming out from these experiments...
 
ZioMario said:
Some ideas : to emulate cygwin with wine on FreeBSD
Click to expand...
Cygwin is supposed to be a UNIX emulator for Windows so that Xorg can run on Windows... what's the point of going through 2 emuation layers (FreeBSD->wine->UNIX) only to end up with same stuff as what's on metal already? 🤣
 
astyle said:
Cygwin is supposed to be a UNIX emulator for Windows so that Xorg can run on Windows... what's the point of going through 2 emuation layers (FreeBSD->wine->UNIX) only to end up with same stuff as what's on metal already? 🤣
Click to expand...

Not to go from FreeBSD->wine->UNIX , but from FreeBSD->wine-> Linux , since Linux Is Not UniX and GNU stands for GNU's Not UNIX.

astyle
 
Last edited:
You must log in or register to reply here.
Back
Top