Date: Tue, 12 Jan 1999 22:32:25 -0800 (PST) From: Christopher Nielsen <enkhyl@scient.com> To: "Jordan K. Hubbard" <jkh@zippy.cdrom.com> Cc: sparc@FreeBSD.ORG Subject: Re: All this muttering about support from Sun. Message-ID: <Pine.BSF.4.05.9901122211270.296-100000@ender.sf.scient.com> In-Reply-To: <613.915693995@zippy.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I've been on vacation for the last three weeks, so maybe I've missed some of the discussions to which Jordan is referring. First, thanks for the reality check, Jordan. I think it was needed. All of the issues mentioned occurred to me during my vacation when I had a chance to seriously thinking about exercising those contacts within Sun to garner support for the project. As a result, I have serious reservations about following through; mostly for the sake of FreeBSD's reputation, the reputations of my friends within Sun and my own reputation. Until we have a booting kernel, support from core, and more serious development effort, we have no business asking SME for any kind of support; especially hardware handouts. I hope this doesn't upset too many people, but I think it's prudent to get over one hurdle at a time. That said, I will probably be buying UltraSPARC hardware on which to do development within the next month, so I will persoanlly be able to contribute more in the near future. On Wed, 6 Jan 1999, Jordan K. Hubbard wrote: > I don't subscribe to this mailing list (I get way too much already) > but I did catch some of the discussion on one of the mail2news sites > and can only say that I find some of what's been discussed so far to > be just a little alarming. I'm also not sure that my role in > "rejecting" SME's original offer was all that properly characterized, > and the two points are related, so let me see if I can't explain some > of the history here and attempt to put things in perspective: > > First off, I'd like it to be well understood by everyone that when you > approach any vendor for FreeBSD-related resources, no matter how big > or small, you're essentially now representing the project as far as > that vendor is concerned and they're just as likely to assume you're > project leadership or something given that most companies are > typically pretty confused about how the whole free software world is > led and who the key players are (I can't say I'm always all that sure > myself). The danger of misrepresenting or overselling the project is > a large reason why the original deal with SME was turned down. > > Even though I myself could probably be said to "lead" the project as > much as any individual does, I am still not at all comfortable with > the idea of representing the project as a whole when it comes to > committing to projects as large as doing and supporting an UltraSPARC > port for any reasonable length of time (a port which flares and dies > quickly being of no use to either party). Were I to have stood up a > year ago and said "OK Sun, I'll take 3 uSPARCs, $20K in direct funding > and 100 hours of one of your own developer's time in exchange for a > working FreeBSD/uSPARC port", I would have been committing the entire > project to far more work and obligation than $20K and 3 machines will > frankly buy. It's one thing to do a slap-dash port of FreeBSD to a > new architecture just for our own interest and yet another thing > entirely to produce a port which works to the satisfaction of a > company like Sun, already fussy customers indeed when you realize > you're competing to some extent against the Solaris group on their > home turf. > > It was much more likely, given my estimation of our abilities back > then time, that we would have simply failed to produce much of > anything reasonable in the time allotted (oh, did I also forget to > mention that SME wanted the port done in 90 days or less, no-foolin' > at all about the schedule?) and the result would have been Sun > concluding (quite rightly) that we were a bunch of losers who didn't > really know what we were doing. You just can't say you'll do > something, impose on some vendor's resources (be it in the form of > equipment loans, discounts, cash bribes, *whatever*), and then shrug > with a stupid grin on your face when it comes time for you to come up > with your end of the deal. > > We've also shown ourselves to be historically very bad when it comes > to doing things to reasonably timely schedules, the DEC Alpha port > taking 1.5 years from the moment that DEC gave us the machines to now, > where it's actually sort of working. Such a thing would have been > completely unacceptable to SME and we just got lucky with Digital in > that nobody there really asked us to do the port in any particular > timeline, I also getting the machines through a personal contact at > DEC which made the whole thing much more low-key and low pressure. > > > So anyway, that's the history up to now and while I'm certainly very > glad to see renewed interest in doing a SPARC port again, I hope that > everyone involved can keep a similar grip on their perspective when it > comes to the more blue-sky aspects of project planning and > committments, either direct or implied, with any 3rd party who might > be attracted to the idea of having a SPARC port of FreeBSD. It's one > thing to say "rah rah, let's do it!" but a very different thing to > contemplate FreeBSD/sparc actually being committed to -current and > built/released in the same way that FreeBSD/axp and FreeBSD/x86 are; > between where you are now and there lie many gates to walk through, > filters to satisfy, a core team to convince, you name it! > > It's also my suggestion that you all start *fist* with the resources > already available rather than hoping that Sun will give you a handout > in the form of discounts or outright loans/grants, something which > will only bring a degree of obligation (nothing comes for free!) into > your little project long before any significant amount of code has > been written or anything is checked into the tree. That's just not > the way it should be done if you're willing to be halfway honest with > yourself, and the way I've seen every successful porting effort go to > date (observing the NetBSD and Linux folks, among others) has been a > small group of 2-3 developers who have the machines and know-how > (e.g. NOT novice or beginning people) significantly advancing the port > to the point where the other folks can actually jump aboard and start > helping with the more mundane stuff. Before that can happen, somebody > has to have wrestled with the toolchain issues and a bootstrap > environment (NetBSD/Linux/Solaris/whatever), then they need to > understand what the architecture specific portions of a FreeBSD system > are and get things to the point where an actual FreeBSD kernel is > booting single user on an actual SPARC machine of some sort. > > Once you've reached that milestone, some of the people who don't have > pre-existing porting experience can start making more realistic > contributions to the port and advance it from the point where it's a > technology demonstrator to being an actual "product" in the same way > that FreeBSD/x86 is. Not even FreeBSD/alpha is to that point yet, and > it has a couple of major coding studs like John Birrell and Doug > Rabson working on it. Just something to keep in mind as you > contemplate this particular mountain, folks. :-) > > - Jordan > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-sparc" in the body of the message > -- Christopher Nielsen Scient: The eBusiness Systems Innovator <http://www.scient.com>; cnielsen@scient.com 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?Pine.BSF.4.05.9901122211270.296-100000>