Run GNU/Linux on a smaller computer for drivers and interface it with a FreeBSD system?

Is the absolute number of drivers important? Or the type of driver? What kind of driver are you hinting at? For what sort of device?

In my use case, I want the maximal compatibility layer, not just some compatibility layer. Or I want the drivers/kernel, rather than just apps.

Therefore I also think that suggestions like using bhyve or emulating FreeBSD on Linux are non-optimal, because:
  • One loses the best parts of both systems. One loses the well-engineered kernel of FreeBSD, for example.
  • One trades a minimal gain to a large loss. With separate devices, one can use Linux just for the drivers and FreeBSD for everything else. So technically one is still using the full FreeBSD + some drivers.
If one decides that the FreeBSD kernel is not useful, one can surely use the emulation approach. I do not think the FreeBSD kernel is useless, it just misses some parts.

I am going to trial this idea anyway using an old spare computer. So I would try, for example, if I can print from FreeBSD using a printer whose driver runs on the Linux computer.

KVM/QEMU is possibly appropriate for most use cases where one cannot afford a second computer. However, is it appropriate for this use case? I would still lose the FreeBSD kernel this way(?)

But OTOH, since it says that:

KVM provides the following emulated devices:
  • Virtual CPU and memory
  • VirtIO

then is it still possible that this is enough for a full-like FreeBSD experience?
 
However, since the SBCs are quite affordable already, then I am not entirely sure what the point of virtualization is when one could purchase a native system for very cheap. One could also purchase some cheap old computer to run just the Linux part.

I always thought the main use for virtualization was for servers to allow many different systems to run on the same base system. But the basic premise of this is that the workloads are somehow more limited than with dedicated servers. Also, the main motive for the server owner is to maximize the use of server resources.
 
However, since the SBCs are quite affordable already, then I am not entirely sure what the point of virtualization is when one could purchase a native system for very cheap. One could also purchase some cheap old computer to run just the Linux part.
Virtualization is free; better than cheap, isn't it? Also, you have the solution on hand, no need to purchase or dig up anything, it takes times and room.

Here, you have the example of my home router: https://forums.freebsd.org/threads/a-freebsd-box-for-home.70451/#post-695571

All is virtualized but the SELKS instance because it's too resource demanding to my opinion.
 
In my use case, I want the maximal compatibility layer, not just some compatibility layer. Or I want the drivers/kernel, rather than just apps.
Doesn't answer the question. What exactly are you missing? What's not working? What exactly do need? You want everything Linux offers? Then simply run Linux.
it just misses some parts.
Name them. What are you missing? You are simply making a lot of broad statements but cannot identify what exactly might be missing.

So I would try, for example, if I can print from FreeBSD using a printer whose driver runs on the Linux computer.
Remote print server. Done. No need for any complicated constructions.
 
My main idea is just about a platform that one can sell to Linux fanboys to make them consider FreeBSD more, rather than have it die as a "research OS" for mainstream desktop use. So if they can use both in tandem for added benefits, then it is the best of both worlds and it is good for FreeBSD too?

I am not an expert, but I find that FreeBSD offers very little on the desktop. But I would prefer it due to a nicer development experience. But there's no point in this when one considers how much more market share Linux has. That is, it's too costly (at least for me) to drop Linux totally in favor of FreeBSD. But one also needs to provide some incentives for people to develop for FreeBSD instead of Linux.

What I had in mind was:
  • Look, you can have your broad Linux support with this small computer, and then get higher performance, well-engineered tools, and clean code with no distro hell etc. with this other box.
Or well, this is what I am interested in. I do not like Debian except for the broad support. Otherwise, I think FreeBSD is nicer to use.

---

Why cannot we just discuss the hardware approach vs virtualized? The point is not to compare the OSes, but rather the approaches to run them both based on the premise that people are already using both of them.

I don't think I have posited FreeBSD "more like" Linux. I have asked about ways to run both of them so that they can communicate so that I can use the parts (that is, any part) from both that I want.

Specifically what is missing is that which virtualization like bhyve etc. does not offer. Another thing might be if it's reasonable to expect someone to learn virtualization if one already knows how to run different OSes natively. To me, it sounds like adding virtualization to the equation just complicates things more.

A lot of devices on the market come with Linux support out of the box. But what if I want to use this with FreeBSD out of the box because my main computer runs it? No, I don't want to use Linux, because my main environment is on FreeBSD. But I could maybe install the box on Linux and then use it from FreeBSD like I would use some other server remotely.

In a rudimentary sense, what I am looking for is not much different from the basic "ssh to another server" approach, but maybe I am looking for more bells and whistles.
I have used VMware Horizon briefly, and it is rather nice. But I would perhaps want even more native experience. In particular, e.g. the performance of running Windows software on Linux using Horizon is substandard. The programs are quite slow compared to running them natively. So I do not think that I would expect bhyve etc. to be much better. Some support for this, for example, here: https://b3n.org/vmware-vs-bhyve-performance-comparison/


So what is missing? Well, what is missing is the "ssh++" client application for FreeBSD.
 
I am not an expert, but I find that FreeBSD offers very little on the desktop.
If you want desktop software, FreeBSD offers a LOT of stuff in ports, it's the exact same stuff as what's available for Linux. KDE, GNOME, XFCE, the entire Apache/MySQL/Php stack... If you want software, ports are the place to look and see if it offers the functionality you want.

So what is missing? Well, what is missing is the "ssh++" client application for FreeBSD.
FreeBSD actually offers the SSH client AND server as part of the base install. Maybe you can read the manpages and figure out how to make use of the functionality already provided by that? It's got tons of options, BTW.
I always thought the main use for virtualization was for servers to allow many different systems to run on the same base system. But the basic premise of this is that the workloads are somehow more limited than with dedicated servers. Also, the main motive for the server owner is to maximize the use of server resources.
It's more about making a service safer. If the web server crashes, it should not take the rest of the machine down with it. But frankly, the enterprise approach is to have a dedicated hardware appliance. Sometimes, depending on the task at hand, a VM may be a better approach than a separate appliance.
My main idea is just about a platform that one can sell to Linux fanboys to make them consider FreeBSD more, rather than have it die as a "research OS" for mainstream desktop use. So if they can use both in tandem for added benefits, then it is the best of both worlds and it is good for FreeBSD too?
You already mentioned the 'distro hell'. And FreeBSD has been around since 1991, IIRC. Yeah, the premise that FreeBSD operates on is pretty different from Linux, even while offering largely the same software.
 
I wonder if X11 forwarding is enough for a protocol here.

I always thought that VMware Horizon or something does a bit more than that.
 
I have been thinking about the old problem of Linux having more drivers than BSDs. The drivers are, however, locked to the Linux kernel.

Then I thought, has it been explored that one would run GNU/Linux just for the drivers using, for example, something like a Raspberry Pi (specifically, an x86 equivalent), and then pipe this to a FreeBSD system using ethernet for sharing?
Is this something similar to this ? --->
View: https://www.youtube.com/watch?v=TuDrmq4RQzU


One would then want just an application for FreeBSD and an application for Linux that can manage these shared devices.
Im kinda having a hard time to understand this - but for me sounds like you just want Proxmox style of thing ?
 
It's more about making a service safer. If the web server crashes, it should not take the rest of the machine down with it. But frankly, the enterprise approach is to have a dedicated hardware appliance. Sometimes, depending on the task at hand, a VM may be a better approach than a separate appliance.
Virtualization on an enterprise level is more about consolidation of hardware. Back in the early days you'd have one server, big expensive box, running one application. Second application, new server hardware, etc. Turns out most of the time (90%) those servers are just idling. Using up power to convert to heat. Not very efficient. So, in comes virtualization, now you have one expensive box and both servers are virtualized within that box. Saves power. Things progressed from there, and you now have a cluster of hardware boxes and some management software that can move VMs (without interruption) from one physical host to the other. That makes the whole thing somewhat resilient to hardware issues. If one of those hardware boxes fails you simply move all the VMs off it, to other hosts, take that broken server out of the pool, replace the hardware, put it back in the pool. All without having to plan for any downtime, because the VMs themselves all kept running. And you have much less hardware in total to worry about, saves power, more efficient use of available resources, etc.
 
Well is FreeBSD on Proxmox the full FreeBSD experience?

It doesn't seem to be for VMs at least:

Not a very well-constructed test, lots of holes, poor presentation from a random blogger on the Internet. That would not fly for even undergrad essay at any accredited Computer Science program, certainly not at Berkeley (The 'B' in any BSD, BTW! 😏)

But even with all that, it's kind of hard to miss the conclusion the blogger reached.

Having played with FreeBSD on both metals and VMs, I can tell you that what matters is the hardware specs the OS can 'see'. And beyond that, it's the full FreeBSD experience, complete with ZFS, networking, software, process management, you name it. It's standard practice to spin up a VM for OS development, be it Windows, Android, or FreeBSD.

Y'know, I can see that you do have ideas on what to do, but you are in fact falling into the trap of phrasing the questions incorrectly. If you ask "How can I do this or that with FreeBSD?", you'll get much more constructive replies and suggestions than if you ask "How/why is FreeBSD similar/different from...". Yeah, FreeBSD is different from Linux and other BSDs on many accounts, and it's impractical to cover them all.

It's far more practical to figure out how to accomplish same ideas using what FreeBSD has to offer. And if in the process, you discover that ideas you get in the BSD camp differ from ideas that you get in the Linux camp - that's OK. It's your machine, you decide what you can live with.

As a personal example, I came to FreeBSD in 2017. I like to say that ZFS is what got me attracted, it solved a Linux pain point that UFS did not, but a working Xorg (that was not a pain to configure) was also critically important. What got me to stay is the Ports system. On Linux, it was surprisingly difficult to adjust the Makefile options to get software features I like without making a mess somewhere. On FreeBSD, I learned how to make use of the system to manage that situation in a clean manner that is standards-compliant and well-documented, and manuals do not get obsolete in a hurry. Still, I got this far by asking "How can I do this or that with FreeBSD?". If I were asking "How will it be different if I try using FreeBSD instead?", I'd get nowhere.
 
Well is FreeBSD on Proxmox the full FreeBSD experience?
Today im struggling with my brain activity.
What is full FreeBSD experience and what is not ?
Currently my FreeBSD is inside Proxmox VM ( due to lack of gpu card in my possession and i need Linux with CUDA ) but OS is installed directly to passed SSD`s not inside Proxmox zfs pool ( so when i ran FreeBSD installer and came up to the option to choose storage - my 2 ssd`s was shown so i could use mirrored zfs pool )
I have 2 network nics inside my motherboard so i dedicated one to FreeBSD. I have usb passtrough , have gpu passtrough only one thing im still not done - is to make sure if my Proxmox goes tits up - i have ability to power on my pc and boot directly into FreeBSD.
But i passed things only i need to my FreeBSD as i dont see the reason to pass whole bunch of them if im not using and automatically if i want something Linux related i can quickly spin LXC inside Proxmox or if i need some sort of containerization ( and dont need nothing specifically Linux or Linux jail will enough) - i will spin a jail.


lsblk command:
Code:
  lsblk
DEVICE         MAJ:MIN SIZE TYPE                                          LABEL MOUNT
da0              0:125 1.0G -                                                 - -
da1              0:124 447G GPT                                               - -
  da1p1          0:127 260M efi                                    gpt/efiboot0 /boot/efi
  <FREE>         -:-   1.0M -                                                 - -
  da1p2          0:128 8.0G freebsd-swap                              gpt/swap0 SWAP
  da1p3          0:129 439G freebsd-zfs                                gpt/zfs0 <ZFS>
  <FREE>         -:-   836K -                                                 - -
da2              0:126 466G GPT                                               - -
  da2p1          0:130 260M efi                                    gpt/efiboot1 -
  <FREE>         -:-   1.0M -                                                 - -
  da2p2          0:131 8.0G freebsd-swap                              gpt/swap1 SWAP
  da2p3          0:132 458G freebsd-zfs                                gpt/zfs1 <ZFS>
  <FREE>         -:-   4.0K -                                                 - -
 
A full FreeBSD experience is close enough to running FreeBSD natively.
A VM experience is a full FreeBSD experience if the VM does not throw away something that one might need.

Based on the benchmarks given above one would lose a significant amount of performance by running on Proxmox instead of running on bhyve.
 
A VM experience is a full FreeBSD experience if the VM does not throw away something that one might need.
oh? like what? a VM only gets a subset of the metal it lives on, the rest is the same. There's no difference in the software experience.

But it does get annoying when somebody tries to pretend to know more than they actually do. OP's earlier comments already demonstrated the level of knowledge. On FreeBSD's Forums, we do try to talk some sense into people like that.
 
Based on the benchmarks given above one would lose a significant amount of performance by running on Proxmox instead of running on bhyve.
Im not a guru but i had to experiment a bit to get things going .. enabling some extra things, disabling some extra thing, passing drives directly etc to get things going to the right direction. There is a thread where person had slow IO as he used ZFS on ZFS. changed to UFS on ZFS and his performance tripled ( VM inside Proxmox ). Dont forget file systems are not equal and you have to choose one for your needs and you have to sacrifice one part to have a gains on another....also ram usage etc.
And Ram ? Unused RAM is wasted RAM :)
 
There is a thread where person had slow IO as he used ZFS on ZFS. changed to UFS on ZFS and his performance tripled
that part doesn't make sense to me, because I have ZFS on metal, I use ZFS in VMs, and in my case, the VMs were quite snappy. The only trouble I had inside VMs was compiling deve/llvm18, I had to disable the FLANG option so that the linking portion of the compilation process could complete... Well, 16 GB of RAM was a limiting factor in my case.
 
that part doesn't make sense to me, because I have ZFS on metal, I use ZFS in VMs, and in my case, the VMs were quite snappy. The only trouble I had inside VMs was compiling deve/llvm18, I had to disable the FLANG option so that the linking portion of the compilation process could complete... Well, 16 GB of RAM was a limiting factor in my case.
It was not like THIS IS THE WAY :) it was as an example that wrong option/setup/setting can cause issues and in this particular thing was needed to change file system. Its like you mentioned your issue: needed to disable FLANG so disabling FLANG is an option. Or im wrong ?
Sorry have no idea how to explain better.
 
Today im struggling with my brain activity.
What is full FreeBSD experience and what is not ?
FreeBSD is all about "The power to serve..." ergo... I'd say the 'experience' is just what you make of it. It can be different for everyone.

For me, personally, it's all about control. Full control: try removing wireless tools from a Linux distrbution and you'll most likely see dozens of other very much needed packages disappear. Rebuild your FreeBSD system with "WITHOUT_WIRELESS=" in /etc/src.conf and... no issues. Feel free to throw in a GENERIC kernel into that mix: no problem.

But there's more to this story... because if you ask me it's also about that same total control & freedom working both ways. Meaning? FreeBSD no mind if you like to shoot yourself in the foot:
Code:
peter@bsd:/home/peter $ dtrace -h
dtrace: failed to establish error handler: "/usr/lib/dtrace/psinfo.d", line 37: syntax error near "uid_t"
It'll happily comply with your wishes.

Guess who disabled one too many options in his kernel configuration? ;) That's also FreeBSD for you.
 
It was not like THIS IS THE WAY :) it was as an example that wrong option/setup/setting can cause issues and in this particular thing was needed to change file system. Its like you mentioned your issue: needed to disable FLANG so disabling FLANG is an option. Or im wrong ?
Sorry have no idea how to explain better.
Nah, I do get you. VMs are supposed to be flexible and to be capable of supporting anything that the guest OS supports. In reality, they do end up being surprisingly fickle about what they allow the guest OS to see and use. It's not out of question that a sysctl needs to be set differently on host and on guest.
 
A VM is not the full experience if the thread is originally about drivers. What if driver A exists for Linux and driver B exists for FreeBSD?
A VM might be the full experience for some apps, but even in this case, the benchmarks might suggest that bhyve is much more performant than a Proxmox Linux host.
 
In my use case, I want the maximal compatibility layer, not just some compatibility layer. Or I want the drivers/kernel, rather than just apps.

Therefore I also think that suggestions like using bhyve or emulating FreeBSD on Linux are non-optimal, because:
  • One loses the best parts of both systems. One loses the well-engineered kernel of FreeBSD, for example.
  • One trades a minimal gain to a large loss. With separate devices, one can use Linux just for the drivers and FreeBSD for everything else. So technically one is still using the full FreeBSD + some drivers.
Considering I was not able to run FreeBSD on a device which is not supported by FreeBSD, having the possibility to run FreeBSD on that device at least in a hypervisor, I would not call that "minimal gain to large loss". The problem you are describing was exactly the reason why virtualization and emulation was developed. If you want to run FreeBSD on a platform it does not support or use a hardware that it does not support, why not simply write a driver or the platform-specific code for it? You are trying to create a Frankenstein/monster which does not belong to FreeBSD, there are enough of those beasts in Linux land.
 
I have been thinking about the old problem of Linux having more drivers than BSDs. The drivers are, however, locked to the Linux kernel.

Then I thought, has it been explored that one would run GNU/Linux just for the drivers using, for example, something like a Raspberry Pi (specifically, an x86 equivalent), and then pipe this to a FreeBSD system using ethernet for sharing?

One would then want just an application for FreeBSD and an application for Linux that can manage these shared devices.

By pure happenstance I read this (old) article on theregister.com about Chimera, a Linux that is not GNU/Linux. A quote from the article read:

Chimera is compiled with LLVM, uses the same musl C library and packaging tools as the lightweight Alpine Linux distro, the new Dinit init system, and much of the rest of the userland is drawn from the current version of FreeBSD.

It is not exactly what you have in mind, but it is a mix between the two operating systems.

The article is from 2023 and I do not know the current state of the project.
 
Yes, I know, Chimera is covered already in the other slightly related thread that considers the high-level user experience between the two systems:


However, Chimera certainly means abandoning FreeBSD on the desktop platform.
 
Back
Top