On Wed, 1 May 2024 at 12:31, Greg Troxel <
gdt%lexort.com@localhost> wrote:
>
> Liam Proven <
lproven%gmail.com@localhost> writes:
>
> > Step 1: a binary interoperability standard, so apps from any BSD can
> > execute on any other BSD (on the same CPU architecture, obviously.)
>
> This is not so much about the binaries about about the ABI for libc and
> other core libs. But I suspec this works better than you think, if one
> arranges for the other libs and deals with elf tags.
You are missing my point.
I am not asking "are they close?" or "are they compatible?" I am
saying: let's work out the differences, make a detailed specific list,
and see if it would be possible to work out a specific standard API so
that *the same binaries* could run on them all.
A modern BSD equivalent of the iBCS 2:
https://en.wikipedia.org/wiki/Intel_Binary_Compatibility_Standard> All BSDs come from 386BSD and Net/2, said in a very broad brush way.
I know that. I have been working in the Unix industry and thus
watching this sector closely since half a decade before 386BSD was
released.
> It's not accurate to say that the kernels are unique. [...]
Again, you misunderstand and do not see my point.
I am saying: let us try to isolate and work out which parts of the 3
or 4 main BSD projects are specific to each OS and which are shared.
Each BSD's kernel is its own. Yes they are all related. We know that.
The clue is in the BSD name. But they are not the same any more and
merging the kernels would be both an epic job, as well as one that
nobody would want to do or to happen.
> > * Coreutils?
>
> coreutils is a term for a GNU package, and many/most of those
> utilities in BSDs aren't from that. Really, coreutils is the linux
> reimplementation of traditional utilities.
I dispute that. It's just a name. Don't fixate on the name. Thing
about the thing that the name refers to.
Here is one set of BSD coreutils, ported to Linux:
https://github.com/DiegoMagdaleno/BSDCoreUtilsHere is another:
https://github.com/dcantrell/bsdutilsHere's a modernised port of that:
https://github.com/chimera-linux/chimerautilsIt is an identifiable, discrete thing.
FWIW I have written about this subject as part of this article:
https://www.theregister.com/2023/02/13/chimera_non_gnu_linux/> Lots of things are the same because they are from the same upstream,
> eg. OpenSSH. But others are differnet. Again you can't really slice it
> that way so easily.
I submit that there is a very important difference between "you can't
slice it" and "nobody has tried to slice it".
> Mostly these are the same upstreams, perhaps packaged differently.
I know. That is my point.
> emacs runs on all of them. I'm not sure what your point is here.
My point is to try to reduce the maintenance load of the 4 separate
BSD projects by identifying where they overlap and moving those
duplicated sections into a shared codebase, which can be
collaboratively maintained by all the teams, reducing the maintenance
burden on those parts by, conservatively, 75%.
--
Liam Proven ~ Profile:
https://about.me/liamprovenEmail:
lproven%cix.co.uk@localhost ~ gMail/gTalk/FB:
lproven%gmail.com@localhostTwitter/LinkedIn: lproven ~ Skype: liamproven
IoM: (+44) 7624 277612: UK: (+44) 7939-087884
Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053