A person labeled only as ‘wicked’ sent me a link to this conversation about BSD unification. I’ve seen the topic brought up before, and I’d argue that it’s already happening, slowly. DragonFly has code brought in from FreeBSD, pkgsrc from NetBSD, pf and dhclient from OpenBSD, etc. ‘bmake’ is used in NetBSD, FreeBSD, and DragonFly now. Clang works across the board, I think (dunno the status on OpenBSD). There’s more of that cross-pollination going on if you think about it.
5 Replies to “Ecumenical BSD”
Comments are closed.
Cross-pollination is a different matter. Unification should mean one BSD can run binaries from another BSD, the way a Linux binary generally works across distros (packaging may be a bit different, but worst-case a tarball installed in /usr/local generally works).
It’s absurd that the BSDs can run Linux binaries but not one another’s.
> It’s absurd that the BSDs can run Linux binaries but not one another’s.
This statement seems to have bad logical underpinnings – there is really only ‘1’ linux operating system –
with a massive number of repackaging / rebranding efforts in the form of the various linux distributions.
BSD operating systems are *DIFFERENT OPERATING SYSTEMS* – Noone thinks it is ‘absurd’ that you can’t
run linux binaries on windows without virtualization or heavy-duty kernel drivers like colinux, or that you
cant’ run e.g. minix 3 binaries on linux, etc.
There *are* BSD binary compatibility layers – however these have gradually been not maintained due
since source-level availability of most application programs – so binary compatibility is not very important.
Also – these things take a huge amount of time, which doesn’t fall from the sky like aliens in some
magic UFO space cult – time that has been better spent elsewhere, like exploring different threading methodologies
or implementing HAMMER in DragonFly, or making totally awesome network tools like PF, OpenSSH, etc. in OpenBSD,
and so on.
The Linux compatibility layers in the BSD operating system*S* (plural) are primarily maintained NOT for generic
application compatibility with linux as some sort of ‘there should be 1 awesome OS that runs all the kool binariez’ goal –
but because it is an unfortunate requirement to run proprietary applications which are released only in binary form
(such as flash, matlab, java before java opensource, etc) or applications written in such a non-portable way
that they only compile on linux (such as openoffice in the past)
As soon as vendors start releasing binary-only software for various BSD flavors, you’d probably see more (unfortunate) effort in this area – but if you have source available, and portable code, there is no need for binary compatibility.
Again – statements like these are typically based on some sort of ‘well – linux distros are all repackaging of linux
so BSD operating systems should be something like that – but when I look deeper they are not and now I am confused
and frustrated’ kind of internal reasoning. Maybe not here. I could be wrong.
Similarly – this is why the phrase ‘*BSD’ or ‘xBSD’ irks me to no end, much as calling FreeBSD a ‘BSD Distro’ is abhorrent –
Usually these phrases are used by those who do not understand the difference in methodology, and a lack of comprehension of the huge amount of disparate but significant work that goes into the different BSD-derived projects,
reducing that effort to the equivalence of someone who basically rebuilds debian with a different wallpaper and their favorite list of applications and calls it ‘SuperWallpaperMyFaveApplicationsLinux’. I say this not to discount the work that does occur in ‘real’ linux distributions – but.. I hope the point is clear.
Dig a little deeper grasshopper. You might learn something.
Chris – I have dug into BSD for years, and have run both FreeBSD and DragonFly on my laptops in the past. Everything you have has been freebsd-advocacy material for years (one reason I like Dragonfly is that its lists are free of this sort of thing).
The reason Linux binaries work on all Linux systems is that the Linux kernel developers, from Linus down, are very strict about maintaining userspace ABI compatibility. It’s not just about closed source software. Most people do not enjoy compiling every bit of software that they need to run.
The BSDs (DFly excepted) have a serious attitude problem. It’s better these days because there is no longer any serious competition with Linux.
I have these “compat” packages installed to run older freebsd binaries
compat5x-amd64-5.4.0.8.1_1 A convenience package to install the compat5x libraries
compat6x-amd64-6.4.604000.200810_3 A convenience package to install the compat6x libraries
compat7x-amd64-7.3.703000.201008_1 A convenience package to install the compat7x libraries
I also have linux-base and kldload linux.ko ….
Someone could – with probably not too much difficulty – pkg up libraries from other BSDs and chroot them and have compat-openbsd compat-dfly compat-netbsd convenience packages so we could run some of the binaries built on other systems … or we could just grab the source and build them. The changes needed to port something from linux to free/net/openBSD or DFly are oftne much more significant than those to move from one BSD to another (unless it’s something that relies on more OS itself like openbsd’s ypdlapd ldap_login etc) so people just recompile instead.
Rahul, even in Linux land ABI compatibility is not free. Programs break all the time because one distro removes the legacy support in glibc or because the glibc version doesn’t provide the fallback for that new kernel etc. Maintaining system call compatibility between the BSDs is expensive and in the case of the threading fundations serious duplication of code.