Date: Thu, 17 Aug 2000 20:30:41 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: rob@controlq.com (Robert S. Sciuk) Cc: freebsd-sparc@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: your mail Message-ID: <200008172030.NAA19336@usr06.primenet.com> In-Reply-To: <Pine.BSF.4.21.0008171016050.45559-100000@schizo.controlq.com> from "Robert S. Sciuk" at Aug 17, 2000 10:35:33 AM
next in thread | previous in thread | raw e-mail | index | archive | help
> > On Wed, Aug 16, 2000 at 12:57:24PM -0700, David DeTinne wrote: > > > Is the sparc port really dead? > > > > > > I have tried the other BSD's and from an average users > > > standpoint FreeBSD is the best (my opinion) > > To play devil's advocate, briefly ... > > Perhaps we should examine just why FreeBSD is `best'. As I understand it, > the limited architectures supported has maximized talent and effort into > making the intel platform work REALLY well, added stability, content, > performance and functionality. > > If FreeBSD migrates to additional architectures, how much of its > `goodness' will translate directly to other platforms?? Moreover, how > much future effort and talent will be diverted into porting efforts rather > than single platform perfection?? One must always trade off optimal > platform performance for the sake of portability! Doing a port to another architecture is pretty trivial. I had a Motorolla PowerStack system running a PPC port of FreeBSD up to single user mode back in 1997. It took less than two months, and the biggest obstacle was waiting for Motorolla to ship the PPCBug SDK and documentation to me (I had to pay for it twice, since they screwed up the first shipment). The biggest obstacle, historically, has been isolating the architecture dependent bits in the FreeBSD source tree. This has become much less of a problem, since the Alpha port has become mainstreamed, though there are still some pieces that depend on "alpha" vs. "!alpha", instad of on "ARCH", and there are not C versions of everything that could be C instead of assembly code. Going from another BSD to FreeBSD self-hosted on SPARC has got to be a damn sight easier than going from AIX to FreeBSD self-hosted on a PPC platform with PReP but not CHiRP support and a non-standard ias opposed to OpenBoot boot monitor. > I'd love FreeBSD on Sparc, and PA-RISC for that matter -- just not at the > expense of the single best Intel based OS I've yet to encounter!!! I am > happy with OpenBSD and NetBSD (thought neither one is on PA-RISC yet). PA-RISC is terribly dead, but since the MACH port and the OSKit work at the University of Utah, if you happened to have one of these things lying around, you could do the work, probably in a pretty short time frame, if you started with OSKit or another UNIX-like system as the base. The biggest barrier to PA-RISC is hardware documentation. > I look at the scalability efforts going on in the FreeBSD kernel as a case > in point, removing the GBL and threading and wonder just how much of that > will translate directly to other architectures?? A lot of it. > Would this effort have started at all if the talented individuals > working on it were busy porting to platform X?? Probably not; but you are incorrectly assuming that if work was expended on one, that it would not be expended on the other, since you appear to be assuming that it's the same people who would be doing the work. I rather seriously doubt that the set of SPARC-knowledgable people and the set of Intel MPSpec and APIC knowledgable people has a very large intersection. I could probably count the people who were _ever_ involved with FreeBSD that had this combination on both hands, with fingers left over. > No doubt at the end of this project, FreeBSD on Intel should beat > the living pants off of NT and Linux on the scability side of the > equation. Beating Linux performance is rather trivial. I have rather grave concerns about some of the technical approaches being pursued in this attempt, particularly as concerns use of kernel threads to dumb-down state machines to the point that linear thinkers can understand them. The SMP scaling strategy currently looks to be limited in value over 4 processors, which is supposedly an Intel limitation, but which others (e.g. Sequent) have demonstrated is really a limitation of the approach used to solve the problem. I actually rather doubt that it will beat NT performance, since free software projects appear to have a Roche limit over a certain level of complexity that prevents them from doing some things. It has been a tendancy of many commercial companies, fearing open source, to drive increasing complexity into IETF standards (IMO, without technical necessity) in order to protect their shrinking domain without having to actually confront the other commercial companies eating into their market. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200008172030.NAA19336>