[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Merging Net/Free/Open-BSD together against Linux
ADRIAN Filipi-Martin wrote:
] Compatability at the ports level could surely be improved, but
] don't you think improving compatability at the /usr level would ease
] improving the compatability of the ports area? Without addressing /usr,
] you are faced with manging several sets of patches for many ports.
] Unifying /usr would restrict the multiple patch problem to kernel/system
] API specific packages.
NOTE: I dont even necessarily support this off the cuff scheme:
One approach that would realisticly improve chances could be as follows:
1. Agree on a new API
Adjust toolchains/kernel/libs to support this API
This API would exist as a binary emulation where appropriatee.
The same API would then exist across all platforms and
binaries written on one would work on all.
(Note: we havent modified any programs yet.)
2. Get vendors to support this API
Migrate the best of the best programs to this API.
We get unified vendor support. Vendors only have to support
the *BSD format.
Note: programs that understand the low lying bits would need
an abstraction layer (which should have been there anyway).
Users now have a choice between different versions of a
program. i.e.: NetBSD ftp vs FreeBSD ftp.
3. Migrate the ports (packages under NetBSD) to the new API
Migrate the old and put all the new under this API.
This will reduce the overall work necessary to get programs
for the *BSD community.
We should start seeing critical mass here.
Note: vendor support was pushed early due to their ramp up
times. The selling point to them is one API for 3 OSs.
4. As we get more programs under the new API it will then be selected
as the default by the toolchain (OSs not fully ported would just
add top level flags to specify the old behavior until everything
is ported. Yes, this will require a lot of makefile changes.)
Can this fail? Yes, most definitely.
Can this work? Maybe.
The difference is engineering factors vs developer factors. A
technically feasible solution will not always be implementable.
NIH continually gets in the was as well as different design goals.
However, even if it only makes it as far as #2 its a win. We get
unified vendor support, which is what we want. Even if there are
subtle differences to the userland if i can go out and buy
WordPerfect and only have to tell them i need it for *BSD/i386
without them worrying about will my subcamp of BSD have enough mass
to make it worth their while to support it specifically, then
its a win.
Hack the Media. Life is an illusion.