OpenBSD (Still) Seeks UltraSparc III Docs From Sun
An anonymous reader writes "There is a very interesting article on kerneltrap regarding OpenBSD's lingering battle with Sun over UltraSparc III documentation (that's right ... it still hasn't been resolved). Jeremy Andrews relates his efforts to get a position from Sun on the matter. In summary, he was completely stonewalled ... and that is exactly what makes the article so noteworthy."
Okay that's fair and I partially retract my :)
statement , but I still feel a bit unhappy that I
never got to see StarOffice 6 except for some pics
on the web
If the OpenBSD team isn't willing to agree to
Sun's terms , well then , it is Suns hardware and
they have the final say , but the article did make
it sound like Sun wasn't willing to talk to the
developers and barely the reporter either.
My (updated) 2c
No, the reason Sun started charging for StarOffice was because corporate buyers were unwilling use "free" software. They believe in the saying "you get what you pay for," and thus in an ironic way didn't feel comfortable using StarOffice unless they were paying for it. So what should Sun do? Distribute the suite for free? Or tag on a price and get a higher likelihood of penetration in the corporate market?
Besides, I recall StarOffice being free to students and those in academics. And, of course, there is always OpenOffice.
-- Kircle
besides it goes against the whole point of the BSD license to sign such agreements.
Great story! However, you can get all kinds of user manuals, hardware manuals, software manuals, etc from http://docs.sun.com You can read them on-line, download Adobe Acrobat versions, and purchase the documents as well. It's a lot easier than it used to be... HMM, no Sparc 1 manual, but the Sparc Classic and similar is at http://docs.sun.com/db/doc/801-2176-13:
I think...I think it's in my basement. Let me go upstairs and check. -M.C. Escher (1898-1972)
My experience was quite different. I was trying to get some Sun Xterminals (rather old; they were basically Sparcstation 2's without hard drives) booting and serving up displays from a Red Hat machine, instead of the aging Sparcserver we were about to retire.
We had support contracts with Sun for several machines, but not the Xterminals or the Sparcserver they booted from. I put in a request with Sun (via a web form) anyway. Within a few hours, someone at the local Sun office was on the phone to me. The next morning, I had a single copy of the manuals on my desk, via courier.
PS - there's a heap of stuff on docs.sun.com
(My email address is on my homepage)
A fab is possibly the most expensive artifact on the planet,
Sun doesn't actually fab anything. They only do the chip design, and have them fab out-of-house.
And, in all that, how much use is the SPARC9 specification for writing kernel code? Not much, I imagine... since indeed memory addressing and cache stuff is what the real issue in coding is.
Conversion Rate Optimisation French / English consultant
"Sun doesn't actually fab anything. They only do the chip design, and have them fab out-of-house."
Absolutely. Given the small volume of UltraSparc cpus produced every year (very small compared to the x86 world), it would be extremely expensive for them to have an own fab. During my work at Sun I saw USIIi cpu boards made by companies like IBM (those had the well known ecache bug) and Sony.
SPARC64GP starts at the PrimePower 200 line, which is a tower server that can do 1-2 CPU's. Fujitsu does not have a 1U implementation (I'm working with their engineers daily right now, so I have a little up-to-date knowledge about this). And as for the top end, yes, the upcoming PP2500 is a mainframe-class server that does upto 128 CPU's running at 1.035 GHz, and outperforms the SunFire 15K by leaps and bounds.
Perhaps, but then why bother going after the UltraSPARC III line? At a minimum, you'll be running on either a Blade 2000 or a SunFire 280R. So if platform choice is an issue, why even bother with the UltraSPARC III at all, unless Theo de Raadt has future plans to take OpenBSD into the realm of larger, midrange class servers? Logic will tell you that either it's a ruse to get Sun to cooperate, or he has bigger plans in mind.
Rule #1 -- Politics always trumps technology.
Low volume isn't the only reason they don't fab themselves... outsourcing that process allows Sun to seek best-of-breed fab technology without having to invest huge $$ in fab infrastructure and then have to "get their $$ worth" out of it. Which makes the stockholders happy (happy as can be, anyway...)
And TI (their main fab partner) gets the symbiotic benefit of having a reason to accelerate and chase the latest and greatest fab stuff to then use on their _own_ products (mainly DSP chips).
Interestingly enough, at the time other companies had no problems to give out the full specs of any chipset that was shipping.
Without a detailed spec on the processor, it is difficult to write a good compiler, and night on impossible to write an operating system. If Sun are scared to give out the specs of a shipped product in public, maybe they are worried about something.
With an Open Source driver it is difficult to sign an NDA (it has been done). With an open source operating system it is impossible because too many people need real info about the behaviour of the hardware. Info will be reflected in comments and variable names. It is very difficult to agree not to disclose the information.
But it's OpenBSD, so they don't care. Linux people are telling Theo to "suck it up" and sign an NDA.
Acutally, the Linux/SPARC developers did suck it up and sign the NDA to get the docs.
They need more detailed MMU and cache info that what is in your comment.