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

mavavilj said:
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.
Click to expand...

Even if you are willing to make a GPLed BSD kernel to take Linux drivers...

... you still face the problem that the driver interface in Linux changes very often. Your drivers won't live long, compilation-wise.
 
cracauer@ said:
Even if you are willing to make a GPLed BSD kernel to take Linux drivers...

... you still face the problem that the driver interface in Linux changes very often. Your drivers won't live long, compilation-wise.
Click to expand...

What if instead of taking the Linux drivers,we take the Android drivers ? Is a better choice ?
 
ZioMario said:
What if instead of taking the Linux drivers,we take the Android drivers ? Is a better choice ?
Click to expand...

No idea. I imagine the Android driver interface changes less than the upstream Linux kernel. But now you can't take driivers for devices that Android does not support neither from Linux nor FreeBSD.
 
cracauer@ said:
No idea. I imagine the Android driver interface changes less than the upstream Linux kernel. But now you can't take driivers for devices that Android does not support neither from Linux nor FreeBSD.
Click to expand...

Android supports a lot of drivers,more on the mobile area,where Linux is not yet good.

If you consider Android X66 Bliss-OS,you will see that it supports even the AMD and Nvidia GPU drivers....there are developers who are working for creating a better integration between Android and Linux even on the Desktop area,since Android X86 can run on the Desktop PC. They use houdini,a library that makes a bridge between Arm and the X86-X64 applications.
 
How would one ever get around the issue of non-matching syscall interfaces?

I don't know how one can even expect that one could model another (operating) system 1:1 on another one. They would have to be the same system in that case?

Also, possibly, such effort would be better to be done towards GNU Hurd/Mach:


which also bakes in the drivers available for Linux, or writing the drivers for FreeBSD.

Also, in this context one would desire "portable drivers".

BTW,
I'd rather port the BSD userspace tools (coreutils, what not) to Linux than have GNU fork the BSD kernel
Click to expand...
https://www.reddit.com/r/linux/comments/n235c/comment/c35qskq/ 13 years ago.

ZioMario said:
Android supports a lot of drivers,more on the mobile area,where Linux is not yet good.
Click to expand...
And it might never be, if you've followed the development of postmarketOS. The issues there are similar to this one. The driver code is simply not portable, but some of it has been written "only for this particular OS (or even device configuration)" in mind. The Linux of pmOS does not include drivers for common mobile device tasks like doing calls or using the camera most of the time.

While writing the drivers might be possible, is it worth the effort, since some things already work? Why hasn't the GNU community moved onto FreeBSD?

I think it's far more useful to focus on creating usable high-level interfaces on several moving targets (Debian, FreeBSD, Android) than expect a kernel-level compatibility at some point, because at that point they have to be the same OS, which does not even make sense, because then they would stagnate, rather than innovate (using their chosen model of development).

E.g.
usable high-level interfaces on several moving targets (Debian, FreeBSD, Android)
Click to expand...
means e.g. that if my setup is:

Linux (desktop), Android (mobile), FreeBSD (cloud/server or high-performance desktop workload), then I need tools to:

deploy from Linux to Android (already exists)
deploy from Linux to FreeBSD, if it's a served app that can be served from Linux OR FreeBSD depending on preferences
read/write from FreeBSD on Android, if it's a client-server app
read/write to/from and monitor FreeBSD, if it's a client-server app
replicate on FreeBSD, if it's an "unix app", but for which I want a high-performance implementation
...

TBH, I feel like for most of the use cases, connecting the OSes using different computers and networking between them is a good solution.

Now I just need a minimal "Linux box" so that I can host the most fundamental kernel functions and have the BSD user space with it.
That is, I wish to use all of them, but at certain portions.

When it comes to Android though, I am not sure why one'd want or need FreeBSD on Android.
 
Last edited:
Anyone have input as to whether Chimera or patching Debian is more reasonable?

Again, the goal is not to make Linux FreeBSD, but make it usable in a similar way and hide the mess of it.
 
mavavilj said:
Anyone have input as to whether Chimera or patching Debian is more reasonable?
Click to expand...
Looking at just a small part of it. Debian's i.e login(1) program has many hooks like selinux / PAM / etc. If Chimera is truly using a large proportion of the BSD userland (rather than just busybox and a fork of bsdutils), then it is probably the closer approach because it wont have that cruft being dragged in (or less at least).
 
kpedersen said:
Looking at just a small part of it. Debian's i.e login(1) program has many hooks like selinux / PAM / etc. If Chimera is truly using a large proportion of the BSD userland (rather than just busybox and a fork of bsdutils), then it is probably the closer approach because it wont have that cruft being dragged in (or less at least).
Click to expand...

As I have imagined. As soon as I have found Chimera Linux I've suddenly thought that was a good idea to try to create some kind of uniformity between the Chimera Linux userland and the FreeBSD userland.
 
This is slightly off-topic, but

How much of FreeBSD could live as Linux kernel modules? Any insight?

The kernel modules should give some level of access to the drivers, so this might be a very fruitful path anyways.

Also, a possibly interesting point of view, since it's not against GPL to connect non-GPL systems over a network to a GPL system and exchange data, then would it be possible to write kernel modules that interface the drivers over a local network to non-GPL software(?)

Some idea: that could allow one to run Linux binaries on Linux with FreeBSD kernel modules rather than Linux binaries on FreeBSD with foreign syscall interfaces.

Possibly also, can one write a blob on Linux that would verify/prove Linuxulator? So that one can test binary compatibility of FreeBSD and Linux on Linux already? Or if one wishes, one could target Linuxulator without having to run FreeBSD.

Maybe there are even some examples of this already?

In particular, these could target Chimera.

We can move this topic to another thread.
 
I've just installed Chimera Linux as Linux distro with the Linuxulator. I'm trying to fix the first problems. My goal is not using Chimera Linux as a bhyve vm,but experimentinh a little bit with Chimera Linux and the Linuxulator ; more specifically I want to understand if I can install a Chimera Linux apk file in the FreeBSD system as a package ;). To be able to do this will help to improve the number of software that can be used natively in FreeBSD,because we can grab new tools from the Chimera Linux repo,that's in fact a Linux distro and for this reason,it produces some tools before and/or only in Linux and maybe never or later for FreeBSD. Furthermore,what about the drivers used by Chimera Linux ? How hard is to use them in FreeBSD ?
Could they be converted 4 FreeBSD spending a reasonable amount of time and energy ?
 
ZioMario said:
I've just installed Chimera Linux as Linux distro with the Linuxulator. I'm trying to fix the first problems. My goal is not using Chimera Linux as a bhyve vm,but experimentinh a little bit with Chimera Linux and the Linuxulator ; more specifically I want to understand if I can install a Chimera Linux apk file in the FreeBSD system as a package ;). To be able to do this will help to improve the number of software that can be used natively in FreeBSD,because we can grab new tools from the Chimera Linux repo,that's in fact a Linux distro and for this reason,it produces some tools before and/or only in Linux and maybe never or later for FreeBSD. Furthermore,what about the drivers used by Chimera Linux ? How hard is to use them in FreeBSD ?
Could they be converted 4 FreeBSD spending a reasonable amount of time and energy ?
Click to expand...
Nobody's gonna stop you from messing around on your personal hardware and blogging about it. If you can pull it off, show it off, and maintain it, to boot, that would be impressive.

Try pulling something together under your own steam first. You have a defined goal, great. You have a fresh copy of FreeBSD, great. But it's on you to figure out what technical puzzles need solving.

For example, at one point, I wanted to make KDE easy to upgrade in isolation from the rest of the FreeBSD system. For that, I needed to get familiar with how ports are compiled, how Poudriere works, and how to tell Poudriere to compile KDE only against an existing system. It was a very time-consuming affair that took up a lot of my brain power, and I had to abandon the project due to competing demands on my time and brainpower.

The divide-and-conquer approach is one I'd recommend for your project. Sometimes, you'd need to re-frame a puzzle several times until you see a solution that you can implement under your own steam.

APK's are Android packages, you can't install them on FreeBSD. You'll have to understand how to go from source code to an APK, and then to think under your own steam how to modify that workflow so that it produces something that compiles and runs on FreeBSD. This is kind of the basics that you'd need to be aware of before asking if an APK can be installed on FreeBSD.

BTW, this is not the first time I see you pull this - just having an out-there idea to play with, but expecting others to do your thinking for you on how to make it happen. The questions are not even framed/worded right.
 
Chimera uses apk-tools (Alpine Package Keeper) as its system packagemanager. Since Chimera uses the next-generation version 3 of the packagemanager which Alpine is not yet using, there are some differences. Additionally, there are some things to currently keep in mind because of Chimera being in an early state.
Click to expand...
 
Y'know, even if I got it wrong about Android vs Alpine, I think you should have been able to understand the general idea (of needing to understand how to go from source code to a working system package, no matter the OS).

If you don't understand the need to understand basics (and the broad overview of the software development process), then the project is out of reach for you.
 
astyle said:
Y'know, even if I got it wrong about Android vs Alpine, I think you should have been able to understand the general idea (of needing to understand how to go from source code to a working system package, no matter the OS).

If you don't understand the need to understand basics (and the broad overview of the software development process), then the project is out of reach for you.
Click to expand...

Thanks for giving me a good general idea. Regarding your "this is not the first time I see you pull this,just having an out-there idea to play with, but expecting others to do your thinking for you on how to make it happen" I want only say that its due to my enthusiasm and unawareness in understanding whether a project is within my reach or not. So I don't want to feel like I'm wrong if I take on projects beyond my possibilities.
 
astyle said:
Sometimes, it's a battle just to get to the starting line of a race.
Click to expand...

That's really true. Someone else said that a battle is win or lost even before to start fighting,when you create the strategy on the paper. If I were to take this literally, though, maybe I shouldn't start this project at all. However, even just being a sower of ideas is not a bad role either.
 
You must log in or register to reply here.
Back
Top