FreeBSD with Linux Kernel

Status
Not open for further replies.
Hello,
Is it possible to use the FreeBSD base with the Linux kernel? If so, has anybody done it before?

Thank you for your time.
 
There was kfreebsd but that's the opposite of what you seek. Either way I think it's a silly notion, but hey, I'm all for people wasting their time. :D
 
There was also https://wiki.gentoo.org/wiki/Gentoo_FreeBSD

I'm not sure what Linux with a Freebsd kernel would be. Linux is the kernel.

Maybe you mean a Freebsd kernel with glibc as the C library (or maybe musl) and a GNU toolchain? I doubt the C libraries could be made to work for the reasons Vigole mentions. Gentoo-Freebsd used the GNU toolchain, but that was before clang got imported into Freebsd base as the compiler of choice. I expect there would be serious problems trying to compile Freebsd base with gcc nowadays.
 
Is it possible to use the FreeBSD base with the Linux kernel? If so, has anybody done it before?
Why would someone want to do that? What's wrong with the FreeBSD kernel?
Thank you for your time.
You could, in return, start to figure out/brainstorm/research a list of tasks, pitfalls, notes & links for transforming the FreeBSD kernel to
  • add microkernel-features, or become a microkernel eventually (while keeping good performance)
  • add the D language to write new code & evolutionary rewrite old parts
  • evaluate if there's a better alternative language than D.
 
  • Like
Reactions: a6h
Not a FreeBSD base but some distributions provide a kind of base.

For example Arch Linux provides a "base" meta package which only pulls in packages from their core repository. Although this is not nearly as clean as FreeBSD sets, for example due to an unresolved bug in gettext packaging, it requires 1 extra package from the extra repository (libcroco, dependency from gettext). They might have fixed this by now but I am sure things like it will crop up again.

Alpine Linux fairs a little better if you get the "extended" version. This allows for an offline install of a bare minimum set of packages you can think of as a "base". However unlike FreeBSD sets, these will likely update over time just like normal packages so you lose a little deterministic behavior there.

In theory there is a Linux Standard Base (LSB) but I don't think anyone follows it.
 
I'm not aware of any kind of "sets". FreeBSD uses meta-packages as well.


Each one of these is a distribution set. Nothing to do with packages.

The name more comes from older sysinstall era FreeBSDs (i.e https://docs.freebsd.org/doc/4.4-RELEASE/usr/share/doc/handbook/x1517.html)

Offtopic: It sucks for a lot of other peoples use-cases but I would love to see a return of the X11 related base distribution sets. I found it to be more elegant than pulling in loads of unnecessary dependencies from packages (even for xorg-minimal).
 
Offtopic: It sucks for a lot of other peoples use-cases but I would love to see a return of the X11 related base distribution sets. I found it to be more elegant than pulling in loads of unnecessary dependencies from packages (even for xorg-minimal).
You're not alone there; I for one agree with you.
 
Each one of these is a distribution set. Nothing to do with packages.

Then this Arch comparison is pretty pointless, the difference comes to FreeBSD stuff being developed in one repo vs multiple repos with different non-cooperating maintainers. How exactly the end result is packaged doesn't matter. Although, to be fair, this whole thread is a sequence of nonsensical posts.

Offtopic: It sucks for a lot of other peoples use-cases but I would love to see a return of the X11 related base distribution sets. I found it to be more elegant than pulling in loads of unnecessary dependencies from packages (even for xorg-minimal).

Aren't we are going into the packaged base direction? And, again, you'll probably have to fork X11 if you want consistent experience.
 
for god..no! and big no!
dont tell to anyone this crazy fetish please,is disgusting
but anyone if free to do what they want..so good luck
 
Then this Arch comparison is pretty pointless

Kinda but with FreeBSD, you know that running a pkg upgrade isn't going to touch anything from base. I.e vi, awk, etc. On Arch anything could happen. Your init system might even disappear before your very eyes ;)

Aren't we are going into the packaged base direction? And, again, you'll probably have to fork X11 if you want consistent experience.

It used to be done this way. One of its benefits was that it was something your package manager cannot touch (/ break). OpenBSD with their Xenocara "semi-fork" is a good example. Monolithic and self contained in /usr/X11R6 and you know that a breakage in something stupid like python isn't going to cause problems. Of course this won't be ideal for everyone.
 
Offtopic: It sucks for a lot of other peoples use-cases but I would love to see a return of the X11 related base distribution sets. I found it to be more elegant than pulling in loads of unnecessary dependencies from packages (even for xorg-minimal).
No. Please don't do that. The non-standard (or non Linux like) location of X11 on other BSD (OpenBSD and NetBSD) caused many problems for porting of Linux developed software to them. The fact is FreeBSD followed Linux (even though ours is on /usr/local) eased the porting a lot.
 
No. Please don't do that. The non-standard (or non Linux like) location of X11

We could put it at any location but yep, /usr/X11R6 is the standard place for it. For example you can see that Solaris also put it there for a reason. Linux is non-standard here. Its funny because even the Linux Standard Base suggests it should be placed there: https://www.kernel.org/doc/ols/2005/ols2005v1-pages-9-20.pdf

The fact is that more and more Linux distros are copying off FreeBSD's /usr/local path idea so their non-standard Linux Makefiles happen to work on FreeBSD. It is a compromise I suppose.

Luckily once Linux regresses to Wayland we won't need to worry about babysitting it anymore :)

caused many problems for porting of Linux developed software to them.

Linux developers are fairly incompetent when it comes to portability. That is why our powerful ports framework allows us to patch their broken code.
 
I dont understand; is X that insecure and inefficient that it necessitates a whole new protocol design? Would it be feasible if we managed our own ‘semi-fork’ like OpenBSD? I think having a display server ABI/API compatibility would be nice alone. I’d wager 90% of open source apps are still based on X anyway; so creating a new Wayland Compositor for FreeBSD would be pain.
 
We could put it at any location but yep, /usr/X11R6 is the standard place for it. For example you can see that Solaris also put it there for a reason. Linux is non-standard here. Its funny because even the Linux Standard Base suggests it should be placed there: https://www.kernel.org/doc/ols/2005/ols2005v1-pages-9-20.pdf

The fact is that more and more Linux distros are copying off FreeBSD's /usr/local path idea so their non-standard Linux Makefiles happen to work on FreeBSD. It is a compromise I suppose.

Luckily once Linux regresses to Wayland we won't need to worry about babysitting it anymore :)
Nowadays, Linux is the standard itself! Sadly, but true.

BTW, I don't think if Linux switch to Wayland, you could free from worry. It only means FreeBSD has to adopt Wayland, too, just like what happened with KMS, to catch the never ending game with Linux. Linux is the leader of the game, you have to follow it, regardless of if you wanting it or not.

We have to keep following Linux to keep relevant. Even Windows, the old king, now has to suffer from Linux's domination, too:


OpenBSD is always a joke (or a toy?). They are free to keep playing with their Xenocara. They have a very successful marketing plan indeed. But I lost all faith on them when I realized that they still not support TRIM for SSD and their home growth virtualization solution, vmd, is just a joke! It's a toy at most! Who on earth would use a hypervisor that only supports one core for each guest?

The following features are not available at this time:
  • graphics
  • snapshots
  • guest SMP support
  • hardware passthrough
  • live migration across hosts
  • live hardware change


This has to be so for a long time without any real improvements!

View: https://www.reddit.com/r/openbsd/comments/81vaz1/can_vmd_allocate_cpu_cores/


Meanwhile NetBSD come up with both HAXM and NVMM!



Both of them are superior to that vmd toy!
 
IGC is an MIT licence compiler. What does that have to do with Linux?
It was first developed on Linux and for Linux. And now they want to use it on other platform, too. Isn't it the sight of Linux's domination? Most of the GPU makers have more profit from big servers than from gamers. And guest what? All of the big servers use Linux!
 
Hello,
Is it possible to use the FreeBSD base with the Linux kernel? If so, has anybody done it before?

Thank you for your time.
It seems that before the Gentoo and Slackware systems used FreeBSD as a base system, I cannot say now.

vigole said:
Not because of "FreeBSD didn't goose-stepped Linux". PR and marketing are alien to FreeBSD Foundation. That's the reason.

However, adding linux software to FreeBSD does support some linux software. Marketing only seems to be a closed policy of a few who benefit from the little space they use in the world with their servers and others products. And some of them have opposed standardization for over 25 years for a extended with default desktop graphic environment for everyone's use.
 
I dont understand; is X that insecure and inefficient that it necessitates a whole new protocol design? Would it be feasible if we managed our own ‘semi-fork’ like OpenBSD? I think having a display server ABI/API compatibility would be nice alone. I’d wager 90% of open source apps are still based on X anyway; so creating a new Wayland Compositor for FreeBSD would be pain.
Things like wayland come about more because of the NIH syndrome that afflicts systemdOS than any deficiencies of the old system it seeks to replace.. eventually.
 
Status
Not open for further replies.
Back
Top