kFreeBSD is "fantastic"
It seems the largest problem to including kfreebsd into the archive or
as an official Debian port is communications. There may be technical or
social reasons too, but they're sometimes difficult to identify without
enough communication.
On Tue, 6 Mar 2007 13:58:42 +1000, Anthony Towns wrote:
> On Mon, Mar 05, 2007 at 06:18:56PM -0800, Russ Allbery wrote:
> > Anthony Towns <aj@azure.humbug.org.au> writes:
> > > I'd love to be proved wrong on kfreebsd's value to users and the
> > > project.
[...]
> If kfreebsd gets added to Debian, I'm going to get asked "So, kfreebsd,
> huh?" and I'd love to be able to respond in a really positive way:
> "yes, it solves ____ a problem" or "it demonstrates this really awesome
> new technique, _____, that's miles beyond anything else, even linux"
> or /something/.
[...]
Porting Debian to a non-Linux kernel. kFreeBSD opens the doors for knetbsd,
kopenbsd, kdragonflybsd. They all have quite a few similarities.
http://wiki.debian.org/ArchiveQualification/kfreebsd-i386 and
http://wiki.debian.org/Debian_GNU/kFreeBSDGNU/kFreeBSD_why list other
reasons. If the reasons are still not sufficient (they weren't as you
noted), please note in more detail.
Some highlights from there include devfs, OSS, OpenBSD Packet Filter
(pf), jails, Xbox port, better in several benchmarks...
Making Debian work on another kernel makes it easier to do other porting
work. The kfreebsd port has helped the HURD and even 68k ports (e.g. see
some of the glibc TLS related work). Making more ports helps make
packages more portable to new unofficial, or even new official ports.
[...]
> One thing I'd like to see for candidate x86/x86_64 architectures is a
> preinstalled vmware-format image (which aiui will work under both qemu
> and vmplayer) that can be used to easily demonstrate what's so fantastic
> about a new OS.
[...]
Is GING not enough? This is the first I've heard of this particular
request. I think it could be accommodated.
[...]
> Given something fantastic that makes it all worthwhile, all the
> practical
> things can be solved. Without any particularly interesting goals that
> get people excited and involved and can be clearly described, I think
> there'll be long term problems in keeping the port active.
[...]
The motivation to work on this in the future includes many of the same
motivations as HURD on L4 and all the BSD distributions. I can't say I
totally understand especially given that "netbsd is dying" and other
related problems, but then I can't say I totally understand the
motivation for Debian.
>From a point of view of users, many ISPs run FreeBSD and people like the
GNU utilities that Debian provides (I install GNU utilities on AIX,
Solaris and Windows).
Netcraft has an interesting list at
http://uptime.netcraft.com/perf/reports/performance/Hosters?tn=february_2007
I also recently read that WindRiver beleive(d) many embedded customers
would prefer BSD over Linux. Some others might find motivation in the
differences between GPLv2 and BSD.
For me the motivation is mostly "because I can", I've got old hardware I
want knetbsd on, and because kfreebsd really helps improve portability to
other platforms that I'm interested in working on (perhaps only for
unofficial usage). I'd like to see Debian help make software more
portable.
Real Concerns?
--------------
I feel your concern is likely, why add kfreebsd/i386, kfreebsd/amd64,
knetbsd/alpha... and so many other to the archive. It creates ftp master
work, takes up Debian resources, makes release management more difficult,
makes security work more difficult... I'd argue that kfreebsd/i386 is in
far better shape than the rest. kfreebsd/amd64 isn't far behind, but the
motivation for the other BSDs doesn't seem to yet be high enough.
Another port, win32 is likely far away. Personally I've been bothered by
the hostility towards such a port by glibc, gcc etc. Not specifically
the port, but the high amount of work seemingly demanded to work with
upstream. FreeBSD helps with some of that through their ports collection
(although a few kfreebsd developers have done quite a bit for glibc on
their ports). ReactOS at FOSDEM seemed to understate their current
status. ReactOS can be used to host compiling ReactOS, and can run many
applications and drivers. Stability still may need some work, and the
politics there are a bit different.
ksolaris may happen some day if the politics get sorted out, but with
the current group dismissing GPLv3 in the manor they did, it seems they
would be quite hostile towards debian-legal. Perhaps that's a good DPL
opportunity for negotiation.
68k seems to have elected to skip official etch, but also seems to have
met the requirements. Some of the non-dd porters still want an official
etch release.
A port to uclibc seems to be content to have some packages in the
archive. I think this makes sense as porters will likely have to
recompile most things for their platform. Some buildd time might be nice
to help maintain compatibility. Most other distributions don't have as
much as Debian for this it seems.
Some analogies are why add another package, another library, kde vs
gnome... Perhaps these analogies are too weak, but are worth considering.
I feel the real concerns for kfreebsd porters are in getting patches
accepted, and having some additional resources. For now this may be
accomplished outside the Debian resources, but official recognition might
make things more easy, both in Debian, and upstream. It may even
encourage more developers.
I've gathered knowledge from official logged IRC meetings (which I
attended), quite a few mailing list messages, and a few web pages (some
linked here). I hope I got the concerns correct.
Future agreements/plans?
------------------------
aj, I like how you got a clear concise agreement from the 68k porters a
few months ago on debian-release (although I think the situation has
changed). Perhaps you could help get a clear plan for kfreebsd's port
status (scc, archive, patches...).
Also, I think we need to collect information from the Security Team, the
Release Team, the ftp masters, debian-admin, debian-boot and any other
group that may have additional work (although perhaps minor) or who
will need additional resources.
Thanks,
Drew Daniels
Resume: http://www.boxheap.net/ddaniels/resume.html
Reply to: