Date: Fri, 9 Jan 1998 19:11:48 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: cjs@portal.ca (Curt Sampson) Cc: tlambert@primenet.com, jb@freebsd1.cimlogic.com.au, jkh@time.cdrom.com, jim.king@mail.sstar.com, freebsd-alpha@FreeBSD.ORG Subject: Re: Alpha port.. Message-ID: <199801091911.MAA27343@usr09.primenet.com> In-Reply-To: <Pine.NEB.3.96.980108160415.11220P-100000@cynic.portal.ca> from "Curt Sampson" at Jan 8, 98 04:15:46 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > Binary compatability. > > That's already there, isn't it? And even if FreeBSD has diverged > that much, it's a relatively simple matter of adding a new emulation > type. I meant with commercial software realeased for non-BSD OS's. > > A working install > > process that doesn't require a net connection and can operate off a > > CDROM instead for the non-Intel machines. > > In fact, we'd have something near that right now if, instead of an > AXPpci33, I'd had on my desk last month one of those nice 500 MHz > alphas that are currently sitting idle on certain FreeBSD hackers' > desks. This is not a major project. It is to get it the same across platforms. I think at least Julian's (or similar) slice stacking code is needed to do this. Both my NetBSD Alpha and my NetBSD HP/345 installs were basically done as disk images with the raw disk out there. NetBSD want's me to have an ethernet transciever to install my HP, and would prefer I have one on my Alpha to install it. Personally, I would prefer boot floppies. On the HP, because I don't have IEEE 488 devices (my Commodore PET/64 equipment doesn't count), I pretty much can't do a tape install. I think a set of uniform install methods across platforms is probably a pretty big deal. Of course, I'm willing to be proven wrong... 8-). > I'm not trying to say that FreeBSD wouldn't benefit from an alpha > port; but the reasons above are not really good reasons to put in > the kind of effort it takes to do a port. The reasons above are what FreeBSD would bring to the Alpha table (including the editted one that aren't really above). Yes, some of these duplicate what NetBSD already brings to the table. I really don't want to get into theories of organizational dynamics at this point. But there is an obvious difference in the installed user base of NetBSD vs. FreeBSD (vs. Linux -- let's be honest), and organizational dynamics is where the crux of the reasons behind the differences lies. It's not some silly explanation like "momentum" or anything like that; the BSD groups have achieved homeostasis in their problem mapping space. Suffice it to say, I think there would be more Alpha's with BSD installed if FreeBSD was ported. > The benefit the Alpha port would provide FreeBSD would be that it > will force you to have damn clean code, and will discover a hell > of a lot of bugs. (I spend a great deal of my alpha hacking time > fixing things someone committed on another port.) This is a secondary benefit, and one that will have to come out of porting effort. I don't think it's that tied to Alpha or anything else; until you try to port something, you don't resolve portability issues if you weren't designing for portability in the first place. The BSD's, even the CSRG code, really was not designed for this; NetBSD is only now, 4 years after the fact, approaching a good level of portability -- and then only for the kernel space, not the install tools or procedures. Probably the procedures are more important than the tools to implemnt them. Certainly, however, there are obvious benefits to doing a port, even if we don't agree 100% on what those benefits will be. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199801091911.MAA27343>