Slashdot Mirror

"Pong on my Palm would be great because it's simple, easy and people love to play with these games: Atari is a sort of a fast food in the game genre," says Hurlbut.

This guy is living in a bubble. He should out Tucows for all the PDA pong he can handle. Slapping an official Atari logo on it and charging a few bucks for it (or paying ludicrous airtime charges) doesn't sound like much fun to me. Especially for Pong, which may have been a cutting edge tennis simulation in the 70s but offers a very limited nostalgic appeal these days.

The big issue is the interface, if you've ever played Nokia's Snake games you'll have quickly realised how badly suited current mobile phones are to arcade gaming, this is compounded further by the current WAP standard's lack of support for realtime interactive keypad input - it'd be like playing pong by selecting from an HTML drop-down menu for "move up" "move down" and then clicking a submit button.

For decent arcade gaming on mobile phones, you'd be better advised to look at Sun's J2ME platform, a partnership between Sun, Sega and Motorola has resulted in the iDen phone (release here) which addresses gaming from a lower-level approach than can be acheived with the likes of WML/HDML.

--

So, what is a CFPP? It is a processor with a pipeline where data and instructions flow in opposite directions, with the instructions usually thought of as moving "up" and data as moving "down". The functional units (FU) are attached as sidings to the main pipeline. Each FU launches from a single pipeline stage and writes its results to a different stage, further "up" the pipeline. The main goals of this architecture were to make the processor simple and regular enough to create a correctness proof and to achieve purely local control.

If Sun ever produces a processor that is asynchronous, it will likely look similar to this.
--
"You can put a man through school,
But you cannot make him think."

Here's the URL for the asynchronous design group's homepage There's more info there.

http://www.ipv6.org/

http://playground.sun.com/pub/ipng/html/ipng-main. html

http://www.ipv6forum.com/

http://www.bieringer.de/linux/IPv6/IPv6-HOWTO/IPv6 -HOWTO.html

Unfortunately, ipv6.org is currently down.

r. ghaffari
(25/M/Baltimore, MD)

Lets clear the smoke.

If "two" (forget more for a second) "alien-things" happened to agree to use a messaging protocol, such as SOAP, well, right there we would have a minor (but cosmic , considering that "alien-things" are involved) miracle , since apparently they communicated their agreement without a common communication means. (No. Telepathy doesn't count.)

Smoke: XML messaging (SOAP) works miracles!

Fact: "[A]lien-things" first need a common mechanism for reaching consensus regarding communication of information..

So lets say they belong to the Inter-Galactic Alliance of Geeky "Alien-Things" [I-GAGA-T(TM)], governed by the I-GAGA-T's strict policies regarding communication means deployment. [Kinda like the saying "lets all use HTTP"]. Then, our two brave "alien-things", charter members of I-GAGA-T (affectionately known to each other as GAGAs), decide to communicate using SOAP, at which point they have fulfilled "the ONLY requirement when doing client/server" according to their recently hired communication consultant, an Earthling named garoush . [Believe me folks, I am not making this up. A true story from the GAGA archives.]

But have they?

No. One of the GAGAs decides to send a message using SOAP to its newly acquired friend! So the trusty (and somewhat rusty) SOAP client is fired up and the message is sent. And guess what? Promptly comes the standard error reply: "Message received, NOT understood. Ca va?"

Put simply, using SOAP, two or more 'alien-things' can communicate to each other as long as they agree on the SOAP protocol - which is the ONLY requirement when doing client/server using SOAP.

So, put simply, the above is a false statement.

[And this point in the story, we find an agitated and nervous garoush, furiously sending SOAPy messages to Earth: "<help>Me!!</help>" -- Lets hope that back on Earth, garoush's friends have first agreed on the Rescue-Message-Format! (But maybe they didn't, hey garoush? "Just use SOAP" he used to say back on Earth. Well ... Just use SOAP then :) )]

SOAP, and XML-RPC, both provide a means for one GAGA to send messages to another GAGA, even if the two GAGA have discovered each other for the very first time. And this messaging protocol , based on the well-understood [there!] request-reply paradigm, and utilizing a standard XML-based message container , delivers SOAP-compliant XML messages from the sender to the receiver.

So as garoush learned/will-learn [funny thing, this space-time continuum] from his consulting gig to the GAGAs, <help>Me!</help> is not defined. For the content of the message, which delivers information from garoush back to Earth, to be understood by the recipient's), he and his hoped-for-rescuers would have first needed to agree on the format of encoding information in your SOAPy messages.

Sure CORBA, DCOM, COM+, Java, etc. allow you to enable two different components to talk to each other, but those technologies do it in such a way that you must have a 'piece' of the server (called the client) to be delivered and used by the client developer. Thus, to talk with a 'server' you must meet the needs of the 'server' when using CORBA, DCOM, COM+, Java, etc. With SOAP, this is all eliminated. As long as the server publishes its API via the SOAP protocol, I can write my client to talk with the server using what ever I want. This frees me from having to 'embed' in my client a piece of the server -- thus there is no longer any 'hard-coupling' between two 'things'.

[We'll skip the fact that SOAP, CORBA, [D]COM[+], and "Java" are a rather orthogonal set of technologies ...]

What is apparently not understood by garoush is that CORBA, DCOM, COM+, Java RMI, do much much more than just simply pass messages from one GAGA to another. [I recommend this great book written specifically for GAGAs for more information on what real (i.e. working) Inter-GAGA Communication Protocols require to function. (Check out the GAGAs on the cover!)] .

Lets just take Java's RMI as an example. What's this with RMI you say? Why didn't they call it Java RPC? I'm glad you asked. See the 'M' in RMI? That's a method, which is a procedure bound to an object. The P in RPC refers to a procedure, which is not necessarily bound to anything. To invoke a method of an object, you first need to get a handle on the object, a remote reference. Any object you say? No. Objects which have been registered with a Registry/Directory Service ( UDDI anyone?) Then you pass the method invocation message to the remote object and a bit of infrastructure on the receiving end maps your method invocation message to an actual method call on the specific object you are invoking. This sub-process of mapping your messages to actual method calls on a specific object uses a messaging protocol which is analogous to what SOAP specifies.

So:

Smoke: SOAP (& XML-RPC) are distributed object technologies! [This goes beyond Smoke and verges on GAGA humor..]

Fact: SOAP is a Simple Xml-based Messaging Protocol (SXMP)

Fact: By the time you have implemented a true Simple Object Access Protocol using a SXMP, you will have something that will look awfully close to RMI. (With the exception that RMI doesn't shuffle needlessly verbose ASCII bits through its system-level plumbing, but your SOAP does.)

In short, by the time you have provided the functionality of an RMI mechanism, such as Java RMI, using SOAP (or any RPC mechanism), you will have accomplished, by the prerequisite functionality of the task at hand, a fairly complex bit of software engineering. Congratulations! (CORBA? Oh boy ...)

In short, using SOAP, we now enable a true 'smart' data-exchange-protocol between two systems such that development is now at the level of "data-exchange" rather than API, SDK, language, etc.

No. More likely, you will realize that having standardized on the data-exchange, you have in effect delegated the complexity of building a distributed object system to the client as opposed to the infrastructure.

Now that is smart. [Good going there Bill!]

[Meanwhile, back on Earth, garoush's friends and would-be rescuers [will] happen upon a long forgotten SOAP Server log file. There, buried among other debug and error messages is the messaging logging the error message the SOAP server sent back to garoush back on planet X. "Ouch" says one of garoush's friends. "I hope he is OK". Now, isn't it just great that XML messages are human readable? (Its too back Servers aren't human -- damn shameful waste of all that human readable information!)]

Smoke: SOAP/XML is a great leap forward!

Fact: Bubble Economies produce Bubble Technologies .

Lets clear the smoke.

If "two" (forget more for a second) "alien-things" happened to agree to use a messaging protocol, such as SOAP, well, right there we would have a minor (but cosmic , considering that "alien-things" are involved) miracle , since apparently they communicated their agreement without a common communication means. (No. Telepathy doesn't count.)

Smoke: XML messaging (SOAP) works miracles!

Fact: "[A]lien-things" first need a common mechanism for reaching consensus regarding communication of information..

So lets say they belong to the Inter-Galactic Alliance of Geeky "Alien-Things" [I-GAGA-T(TM)], governed by the I-GAGA-T's strict policies regarding communication means deployment. [Kinda like the saying "lets all use HTTP"]. Then, our two brave "alien-things", charter members of I-GAGA-T (affectionately known to each other as GAGAs), decide to communicate using SOAP, at which point they have fulfilled "the ONLY requirement when doing client/server" according to their recently hired communication consultant, an Earthling named garoush . [Believe me folks, I am not making this up. A true story from the GAGA archives.]

But have they?

No. One of the GAGAs decides to send a message using SOAP to its newly acquired friend! So the trusty (and somewhat rusty) SOAP client is fired up and the message is sent. And guess what? Promptly comes the standard error reply: "Message received, NOT understood. Ca va?"

Put simply, using SOAP, two or more 'alien-things' can communicate to each other as long as they agree on the SOAP protocol - which is the ONLY requirement when doing client/server using SOAP.

So, put simply, the above is a false statement.

[And this point in the story, we find an agitated and nervous garoush, furiously sending SOAPy messages to Earth: "<help>Me!!</help>" -- Lets hope that back on Earth, garoush's friends have first agreed on the Rescue-Message-Format! (But maybe they didn't, hey garoush? "Just use SOAP" he used to say back on Earth. Well ... Just use SOAP then :) )]

SOAP, and XML-RPC, both provide a means for one GAGA to send messages to another GAGA, even if the two GAGA have discovered each other for the very first time. And this messaging protocol , based on the well-understood [there!] request-reply paradigm, and utilizing a standard XML-based message container , delivers SOAP-compliant XML messages from the sender to the receiver.

So as garoush learned/will-learn [funny thing, this space-time continuum] from his consulting gig to the GAGAs, <help>Me!</help> is not defined. For the content of the message, which delivers information from garoush back to Earth, to be understood by the recipient's), he and his hoped-for-rescuers would have first needed to agree on the format of encoding information in your SOAPy messages.

Sure CORBA, DCOM, COM+, Java, etc. allow you to enable two different components to talk to each other, but those technologies do it in such a way that you must have a 'piece' of the server (called the client) to be delivered and used by the client developer. Thus, to talk with a 'server' you must meet the needs of the 'server' when using CORBA, DCOM, COM+, Java, etc. With SOAP, this is all eliminated. As long as the server publishes its API via the SOAP protocol, I can write my client to talk with the server using what ever I want. This frees me from having to 'embed' in my client a piece of the server -- thus there is no longer any 'hard-coupling' between two 'things'.

[We'll skip the fact that SOAP, CORBA, [D]COM[+], and "Java" are a rather orthogonal set of technologies ...]

What is apparently not understood by garoush is that CORBA, DCOM, COM+, Java RMI, do much much more than just simply pass messages from one GAGA to another. [I recommend this great book written specifically for GAGAs for more information on what real (i.e. working) Inter-GAGA Communication Protocols require to function. (Check out the GAGAs on the cover!)] .

Lets just take Java's RMI as an example. What's this with RMI you say? Why didn't they call it Java RPC? I'm glad you asked. See the 'M' in RMI? That's a method, which is a procedure bound to an object. The P in RPC refers to a procedure, which is not necessarily bound to anything. To invoke a method of an object, you first need to get a handle on the object, a remote reference. Any object you say? No. Objects which have been registered with a Registry/Directory Service ( UDDI anyone?) Then you pass the method invocation message to the remote object and a bit of infrastructure on the receiving end maps your method invocation message to an actual method call on the specific object you are invoking. This sub-process of mapping your messages to actual method calls on a specific object uses a messaging protocol which is analogous to what SOAP specifies.

So:

Smoke: SOAP (& XML-RPC) are distributed object technologies! [This goes beyond Smoke and verges on GAGA humor..]

Fact: SOAP is a Simple Xml-based Messaging Protocol (SXMP)

Fact: By the time you have implemented a true Simple Object Access Protocol using a SXMP, you will have something that will look awfully close to RMI. (With the exception that RMI doesn't shuffle needlessly verbose ASCII bits through its system-level plumbing, but your SOAP does.)

In short, by the time you have provided the functionality of an RMI mechanism, such as Java RMI, using SOAP (or any RPC mechanism), you will have accomplished, by the prerequisite functionality of the task at hand, a fairly complex bit of software engineering. Congratulations! (CORBA? Oh boy ...)

In short, using SOAP, we now enable a true 'smart' data-exchange-protocol between two systems such that development is now at the level of "data-exchange" rather than API, SDK, language, etc.

No. More likely, you will realize that having standardized on the data-exchange, you have in effect delegated the complexity of building a distributed object system to the client as opposed to the infrastructure.

Now that is smart. [Good going there Bill!]

[Meanwhile, back on Earth, garoush's friends and would-be rescuers [will] happen upon a long forgotten SOAP Server log file. There, buried among other debug and error messages is the messaging logging the error message the SOAP server sent back to garoush back on planet X. "Ouch" says one of garoush's friends. "I hope he is OK". Now, isn't it just great that XML messages are human readable? (Its too back Servers aren't human -- damn shameful waste of all that human readable information!)]

Smoke: SOAP/XML is a great leap forward!

Fact: Bubble Economies produce Bubble Technologies .

Lets clear the smoke.

If "two" (forget more for a second) "alien-things" happened to agree to use a messaging protocol, such as SOAP, well, right there we would have a minor (but cosmic , considering that "alien-things" are involved) miracle , since apparently they communicated their agreement without a common communication means. (No. Telepathy doesn't count.)

Smoke: XML messaging (SOAP) works miracles!

Fact: "[A]lien-things" first need a common mechanism for reaching consensus regarding communication of information..

So lets say they belong to the Inter-Galactic Alliance of Geeky "Alien-Things" [I-GAGA-T(TM)], governed by the I-GAGA-T's strict policies regarding communication means deployment. [Kinda like the saying "lets all use HTTP"]. Then, our two brave "alien-things", charter members of I-GAGA-T (affectionately known to each other as GAGAs), decide to communicate using SOAP, at which point they have fulfilled "the ONLY requirement when doing client/server" according to their recently hired communication consultant, an Earthling named garoush . [Believe me folks, I am not making this up. A true story from the GAGA archives.]

But have they?

No. One of the GAGAs decides to send a message using SOAP to its newly acquired friend! So the trusty (and somewhat rusty) SOAP client is fired up and the message is sent. And guess what? Promptly comes the standard error reply: "Message received, NOT understood. Ca va?"

Put simply, using SOAP, two or more 'alien-things' can communicate to each other as long as they agree on the SOAP protocol - which is the ONLY requirement when doing client/server using SOAP.

So, put simply, the above is a false statement.

[And this point in the story, we find an agitated and nervous garoush, furiously sending SOAPy messages to Earth: "<help>Me!!</help>" -- Lets hope that back on Earth, garoush's friends have first agreed on the Rescue-Message-Format! (But maybe they didn't, hey garoush? "Just use SOAP" he used to say back on Earth. Well ... Just use SOAP then :) )]

SOAP, and XML-RPC, both provide a means for one GAGA to send messages to another GAGA, even if the two GAGA have discovered each other for the very first time. And this messaging protocol , based on the well-understood [there!] request-reply paradigm, and utilizing a standard XML-based message container , delivers SOAP-compliant XML messages from the sender to the receiver.

So as garoush learned/will-learn [funny thing, this space-time continuum] from his consulting gig to the GAGAs, <help>Me!</help> is not defined. For the content of the message, which delivers information from garoush back to Earth, to be understood by the recipient's), he and his hoped-for-rescuers would have first needed to agree on the format of encoding information in your SOAPy messages.

Sure CORBA, DCOM, COM+, Java, etc. allow you to enable two different components to talk to each other, but those technologies do it in such a way that you must have a 'piece' of the server (called the client) to be delivered and used by the client developer. Thus, to talk with a 'server' you must meet the needs of the 'server' when using CORBA, DCOM, COM+, Java, etc. With SOAP, this is all eliminated. As long as the server publishes its API via the SOAP protocol, I can write my client to talk with the server using what ever I want. This frees me from having to 'embed' in my client a piece of the server -- thus there is no longer any 'hard-coupling' between two 'things'.

[We'll skip the fact that SOAP, CORBA, [D]COM[+], and "Java" are a rather orthogonal set of technologies ...]

What is apparently not understood by garoush is that CORBA, DCOM, COM+, Java RMI, do much much more than just simply pass messages from one GAGA to another. [I recommend this great book written specifically for GAGAs for more information on what real (i.e. working) Inter-GAGA Communication Protocols require to function. (Check out the GAGAs on the cover!)] .

Lets just take Java's RMI as an example. What's this with RMI you say? Why didn't they call it Java RPC? I'm glad you asked. See the 'M' in RMI? That's a method, which is a procedure bound to an object. The P in RPC refers to a procedure, which is not necessarily bound to anything. To invoke a method of an object, you first need to get a handle on the object, a remote reference. Any object you say? No. Objects which have been registered with a Registry/Directory Service ( UDDI anyone?) Then you pass the method invocation message to the remote object and a bit of infrastructure on the receiving end maps your method invocation message to an actual method call on the specific object you are invoking. This sub-process of mapping your messages to actual method calls on a specific object uses a messaging protocol which is analogous to what SOAP specifies.

So:

Smoke: SOAP (& XML-RPC) are distributed object technologies! [This goes beyond Smoke and verges on GAGA humor..]

Fact: SOAP is a Simple Xml-based Messaging Protocol (SXMP)

Fact: By the time you have implemented a true Simple Object Access Protocol using a SXMP, you will have something that will look awfully close to RMI. (With the exception that RMI doesn't shuffle needlessly verbose ASCII bits through its system-level plumbing, but your SOAP does.)

In short, by the time you have provided the functionality of an RMI mechanism, such as Java RMI, using SOAP (or any RPC mechanism), you will have accomplished, by the prerequisite functionality of the task at hand, a fairly complex bit of software engineering. Congratulations! (CORBA? Oh boy ...)

In short, using SOAP, we now enable a true 'smart' data-exchange-protocol between two systems such that development is now at the level of "data-exchange" rather than API, SDK, language, etc.

No. More likely, you will realize that having standardized on the data-exchange, you have in effect delegated the complexity of building a distributed object system to the client as opposed to the infrastructure.

Now that is smart. [Good going there Bill!]

[Meanwhile, back on Earth, garoush's friends and would-be rescuers [will] happen upon a long forgotten SOAP Server log file. There, buried among other debug and error messages is the messaging logging the error message the SOAP server sent back to garoush back on planet X. "Ouch" says one of garoush's friends. "I hope he is OK". Now, isn't it just great that XML messages are human readable? (Its too back Servers aren't human -- damn shameful waste of all that human readable information!)]

Smoke: SOAP/XML is a great leap forward!

Fact: Bubble Economies produce Bubble Technologies .

Lets clear the smoke.

If "two" (forget more for a second) "alien-things" happened to agree to use a messaging protocol, such as SOAP, well, right there we would have a minor (but cosmic , considering that "alien-things" are involved) miracle , since apparently they communicated their agreement without a common communication means. (No. Telepathy doesn't count.)

Smoke: XML messaging (SOAP) works miracles!

Fact: "[A]lien-things" first need a common mechanism for reaching consensus regarding communication of information..

So lets say they belong to the Inter-Galactic Alliance of Geeky "Alien-Things" [I-GAGA-T(TM)], governed by the I-GAGA-T's strict policies regarding communication means deployment. [Kinda like the saying "lets all use HTTP"]. Then, our two brave "alien-things", charter members of I-GAGA-T (affectionately known to each other as GAGAs), decide to communicate using SOAP, at which point they have fulfilled "the ONLY requirement when doing client/server" according to their recently hired communication consultant, an Earthling named garoush . [Believe me folks, I am not making this up. A true story from the GAGA archives.]

But have they?

No. One of the GAGAs decides to send a message using SOAP to its newly acquired friend! So the trusty (and somewhat rusty) SOAP client is fired up and the message is sent. And guess what? Promptly comes the standard error reply: "Message received, NOT understood. Ca va?"

Put simply, using SOAP, two or more 'alien-things' can communicate to each other as long as they agree on the SOAP protocol - which is the ONLY requirement when doing client/server using SOAP.

So, put simply, the above is a false statement.

[And this point in the story, we find an agitated and nervous garoush, furiously sending SOAPy messages to Earth: "<help>Me!!</help>" -- Lets hope that back on Earth, garoush's friends have first agreed on the Rescue-Message-Format! (But maybe they didn't, hey garoush? "Just use SOAP" he used to say back on Earth. Well ... Just use SOAP then :) )]

SOAP, and XML-RPC, both provide a means for one GAGA to send messages to another GAGA, even if the two GAGA have discovered each other for the very first time. And this messaging protocol , based on the well-understood [there!] request-reply paradigm, and utilizing a standard XML-based message container , delivers SOAP-compliant XML messages from the sender to the receiver.

So as garoush learned/will-learn [funny thing, this space-time continuum] from his consulting gig to the GAGAs, <help>Me!</help> is not defined. For the content of the message, which delivers information from garoush back to Earth, to be understood by the recipient's), he and his hoped-for-rescuers would have first needed to agree on the format of encoding information in your SOAPy messages.

Sure CORBA, DCOM, COM+, Java, etc. allow you to enable two different components to talk to each other, but those technologies do it in such a way that you must have a 'piece' of the server (called the client) to be delivered and used by the client developer. Thus, to talk with a 'server' you must meet the needs of the 'server' when using CORBA, DCOM, COM+, Java, etc. With SOAP, this is all eliminated. As long as the server publishes its API via the SOAP protocol, I can write my client to talk with the server using what ever I want. This frees me from having to 'embed' in my client a piece of the server -- thus there is no longer any 'hard-coupling' between two 'things'.

[We'll skip the fact that SOAP, CORBA, [D]COM[+], and "Java" are a rather orthogonal set of technologies ...]

What is apparently not understood by garoush is that CORBA, DCOM, COM+, Java RMI, do much much more than just simply pass messages from one GAGA to another. [I recommend this great book written specifically for GAGAs for more information on what real (i.e. working) Inter-GAGA Communication Protocols require to function. (Check out the GAGAs on the cover!)] .

Lets just take Java's RMI as an example. What's this with RMI you say? Why didn't they call it Java RPC? I'm glad you asked. See the 'M' in RMI? That's a method, which is a procedure bound to an object. The P in RPC refers to a procedure, which is not necessarily bound to anything. To invoke a method of an object, you first need to get a handle on the object, a remote reference. Any object you say? No. Objects which have been registered with a Registry/Directory Service ( UDDI anyone?) Then you pass the method invocation message to the remote object and a bit of infrastructure on the receiving end maps your method invocation message to an actual method call on the specific object you are invoking. This sub-process of mapping your messages to actual method calls on a specific object uses a messaging protocol which is analogous to what SOAP specifies.

So:

Smoke: SOAP (& XML-RPC) are distributed object technologies! [This goes beyond Smoke and verges on GAGA humor..]

Fact: SOAP is a Simple Xml-based Messaging Protocol (SXMP)

Fact: By the time you have implemented a true Simple Object Access Protocol using a SXMP, you will have something that will look awfully close to RMI. (With the exception that RMI doesn't shuffle needlessly verbose ASCII bits through its system-level plumbing, but your SOAP does.)

In short, by the time you have provided the functionality of an RMI mechanism, such as Java RMI, using SOAP (or any RPC mechanism), you will have accomplished, by the prerequisite functionality of the task at hand, a fairly complex bit of software engineering. Congratulations! (CORBA? Oh boy ...)

In short, using SOAP, we now enable a true 'smart' data-exchange-protocol between two systems such that development is now at the level of "data-exchange" rather than API, SDK, language, etc.

No. More likely, you will realize that having standardized on the data-exchange, you have in effect delegated the complexity of building a distributed object system to the client as opposed to the infrastructure.

Now that is smart. [Good going there Bill!]

[Meanwhile, back on Earth, garoush's friends and would-be rescuers [will] happen upon a long forgotten SOAP Server log file. There, buried among other debug and error messages is the messaging logging the error message the SOAP server sent back to garoush back on planet X. "Ouch" says one of garoush's friends. "I hope he is OK". Now, isn't it just great that XML messages are human readable? (Its too back Servers aren't human -- damn shameful waste of all that human readable information!)]

Smoke: SOAP/XML is a great leap forward!

Fact: Bubble Economies produce Bubble Technologies .

As I recall, memory use balloons rather quickly no matter what you do. Worse, it never really comes down again. There was also some discussion at the time (Swing has "built in" memory leaks); don't know if that is still pertinent.

Point being, it helps workflow to have everybody using the same OS and architecture. Even the work-study students and interns.

Dude, its right on the Front Page

Keep in mind the ultra 10 give you SMP support.

The datasheet says this about the pci slots:

Three 32-bit PCI slots, full size, 33mhz, 5V (3.3V power supplied)

USB is used for the keyboard/mouse interface for all new Sun machines since the SunRay - So far, that's the sunrays and the sunblades. I believe logitech makes the actual keyboards.

Solaris 8 also supports various other USB devices, which would presumably be listed in the HCL.

The upside to this, of course, is if you work on a Sun layout keyboard, you can hang a USB sun keyboard off your linux or windows desktop and not have to mentally switch to that annoying PC layout all the time. Plus, the mouse has 3 buttons :) The keyboard is P/N 320-1273 (US Unix) and the mouse is P/N 370-3632.

By the way, it does have a normal PCI slot, and you could put the SunPCI-II card in it, but also some other PCI card (provided there is a Solaris 8 driver for it).

base config comes with IDE everything, 4GB hard drive
Only the earliest Ultra 5 systems shipped with slow 4500 RPM disks. Later Ultra 5s have 5400 or 7200 RPM disks.
The Blade 100 has one or two 15 GB 7200 RPM IDE drives. Bootable Symbios SCSI add-in cards can be found for $40-$60. Also, both in Linux and Solaris, remember to find the magic switch to turn on DMA disk I/O

a slow processor (can't remember the exact numbers)
The Blade 100 bumps the speed up from the Ultra 5's initial 300 MHz UltraSPARC IIi (later 400 MHz) to 500 MHz. Still UltraSPARC-IIe, not -III, and with small caches though.

video was limited to 256 colors at any reasonable resolution
Video was stuck at 8-bit or switchable between 8-bit or 24-bit on the early systems. Later Ultra 5 systems can display both at the same time.
The Blade 100 comes with 24-bit graphics built it and can use the new Expert3D-Lite graphics card (which is much faster than the very decent Creator3D cards; here's a comparison) .

My Linux box (a dell pII-300) blew it out of the water on every benchmark
Many people buy the the entry level Sun machines to have a relatively cheap SPARC box. I haven't benchmarked the latest, but SPARC emulators running on Intel Linux don't tend to run very fast.

"t's computing without compromise. The new Sun Blade[tm] 100 workstation shatters the $1,000 entry price barrier for desktop workstations without sacrificing performance, versatility, or expandability."

On this page you can see some (older) benchmarks, SPECint95 20; SPECfp95 21 for the 500MHz part. The IIe is meant to be an embedded processor. An Athlon (Classic) at 600 MHz is pretty much on par with this guy. Save your money.

And I quote from the FAQ at http://www.sun.com/desktop/sunblade100/faq.html#1

2. Is this memory proprietary?
No. The memory used in the Sun Blade 100 is industry standard.

3. Why buy Sun memory?
This family of memory products are priced competitively and are tested, approved and qualified by Sun.

Still, I want one...

The SunPCi card uses a 600Mhz Celeron for the processor. Details at http://www.sun.com/desktop/products/sunpci/

For Sun, it takes a while for products to move from press release to online store. The $1000 dollar Sun server mentioned in this slashdot article is only just for sale on their online store.

But, the SunBlade 100 is for sale on the online store now.

A tremendous performance boost for demanding compute-intensive applications.

Sun ushers in the next generation of exceptional tools for technical professionals with the Sun Blade[tm] 1000 workstation. The Sun Blade 1000 system accommodates up to two superscalar, 64-bit, high-performance UltraSPARC[tm]-III CPUs. It features a high-performance, crossbar-switch system interconnect that provides high bandwidth (up to 4 GB/sec.) for today's and tomorrow's ultra-high-speed processors and graphic subsystems. It also delivers plenty of internal disk and memory and a 64-bit PCI bus for incredibly fast I/O. The Sun Blade 1000 workstation provides both USB and IEEE1394 interfaces for connectivity to the leading edge in third-party peripherls. With state-of-the-art high-end graphics, dual monitor capabilities, and support for Sun's advanced storage systems, this workstation is truly a powerful, flexible next-generation desktop.

Processor Powered by up to two 600-, 750-, or 900-MHz UltraSPARC-III CPUs. Memory Delivers up to 8 GB of main memory and up to 72 GB of 10,000-rpm FC/AL disk storage. Graphics Choice of Sun[tm] Creator3D, Sun[tm] Elite3D m6 and Sun Expert3D graphics technology for high-performance graphics functionality. I/O Interfaces IEEE 1394 ports for high-speed digital video transfers; USB ports for connecting USB devices such as Iomega Zip® or JAZ® drives. Peripheral Drives Three removable media slots for choice of DVD-ROM, 4-mm tape, or floppy; smart-card reader is standard. PCI Cards Four industry-standard PCI slots provide access to hundreds of expansion and high-performance networking options. Operating System Runs Solaris[tm] 8 Operating Environment; binary compatible with previous Solaris versions and entire workstation and server lines.

This is all from there site.. who posted this?? What did they not use the little search box on the www.sun.com web site??

I don't want a lot, I just want it all!
Flame away, I have a hose!

-earl

Can be found on the Sun Blade 100 Workstation page.

Hate to reply to my own post, but I saw the answer on another thread. Info at Sun's Site.

this spec pdf for the sun blade 100 has a little more information... http://www.sun.com/desktop/sunblade100/sb100_ds.pd f

Of course, I put this in my submission about this story, along with the link to the machine itself but it got rejected :-(

It also spoells the death of Solaris x86, since the only reason to use it was because you couldn't afford Sparc hardware.

In fact, I'd go as far to say it will make a huge dent in Linux market share -- I know I would prefer a Solaris Sparc machine to intel box any day. Many others would, especially at the server end, where the Netra really shines.

Tux, you're going to have to do something really good to keep me on board!

...the Slashdot article should read SunPCi . This is a card witha chip on it that allows the user to run existing x86 applications under the Solaris OS. The article confused me with the line:

"With a PCi card for an extra $195, the Sun Blade 100 machine would be able to run applications on both Microsoft's Windows and Sun's Solaris operating system."

Until I looked it up on Sun's site at: http://www.sun.com/desktop/products/sunpci/sunpcij tf.html

Specs and other marketing blurb are available on SUN's website. --Ives

Here's some info on Sun's site:

http://store.sun.com/catalog/doc/BrowsePage.jhtml? cid=60357

http://www.sun.com/desktop/sunblade100/

What about this? OK, it's the Sun store, but it's there.

up on Sun's site now. You can see it here -> http://store.sun.com/catalog/doc/BrowsePage.jhtml? cid=60357

"Everything that can be invented has been invented."

Sun now offers compressed ISO images for download, as mentioned in another comment. No charge, just a simple license.

From The official FAQ:

2. What can I do with the binary (runtime) version of the Solaris 8 Operating Environment?
You can use the Solaris 8 runtime environment at home or at work, for business or personal computing.

No, it's not GPL, but not everything of value in the world is released under the GPL. Get over it.

Solaris 8 is free for machines with less than 8 processors for any purpose.

Download Solaris 8 (Sparc/x86) "free" from Sun here. They'll even let you download the source for Solaris 8 for free, after letting you jump through some legal hoops. There are restrictions on what you can use either of these for though, but for home use, you should be all set.

Download Solaris 8 (Sparc/x86) "free" from Sun here. They'll even let you download the source for Solaris 8 for free, after letting you jump through some legal hoops. There are restrictions on what you can use either of these for though, but for home use, you should be all set.

1.) On an airplane - No net access so you can watch DVD's (yep you can watch DVD's in linux), Play games or type whatever you need to type.

2.) In the car when driving you can listen to mp3's

3.) At home or in the office there is nothing a laptop can't do that a desktop can ... trust me.

Now if you've ever tried to install linux on a laptop you will find that with everything built into the mother board and lack of room to tinker with the insides ... that installing linux is not the easiest thing to do.

Solution ... instead of buying a laptop with windows pre-installed ... get linux pre-installed ... and QLITech offers this ...

And if you must have windows I am quite sure that QLITech would set you up with a dual-booting system.

So I am more than pleased to see that TuxTops legacy is still alive and not to mention all previously supported computers are still supported through QLITech ... they could have easily just taken over the notebook section, but they stayed with the commitment of TuXtops.

Lastly ... about the names ... have you not noticed the names of notebooks these days ... Protege, Satellite, iBook, or iPaq ... come on these names are no more absurd than any otherrs ... at least there's reasoning behind their names.

Actually, I've been lusting over one myself, but I can't begin to justify the $2200.

Hey, I just noticed the 24" crt is LESS than the 18" lcd. So why not opt for the bigger crt?

24" Sun Monitor

That's too much of a nerd view of the world. What I said in Time is, "Just because it's possible doesn't mean it's OK."

Contrast this with Sun Microsystems who use the SPARC processor under license. As far as I'm aware, they don't even manufacture SPARCs themselves, but rely on a third party foundry. Why is this relevant? Because SPARCs are also used by many vendors and you can even get the chip architectures if you wanted to implement it yourself, then have your design properly verified.

Contrast this with Sun Microsystems who use the SPARC processor under license. As far as I'm aware, they don't even manufacture SPARCs themselves, but rely on a third party foundry. Why is this relevant? Because SPARCs are also used by many vendors and you can even get the chip architectures if you wanted to implement it yourself, then have your design properly verified.

To get around the legal issue of rebroadcasting, he could always install an optical network. That is, a bunch of, mirrors which would reflect the screen to different rooms. And then use the aforementioned CGI script to control channel.

But seriously doesn't a rebroadcast involve time-shifting? Just don't store it. The network would then be the same as my mirrors.

As for Java, behold!

If you're going to go the Java route Java Web Start, would probably be better than an applet.

(not that I've actually used it, mind you, but I do like the fact that it appears to be free of the browser-related issues that can occur with applets)

Of course, then you'll need to roll out JWS itself to all your computers...
---

For prople primatily interested in Linux, and glibc2, there's a paper for the community, written by David J. Brown and Karl Runge on Library Interface Versioning in Solaris and Linux.

Where my prefered solution would be to install SunRays on all desktops
where people don't need special apps and the let the people who do
have a Linux PC for them (or me more likely :) to play with.
If some people REALLY need win32 apps that have no Linux counterpart
we'll have to play around with Wine/WMvare/Win4Lin/Citrix/etc...

But it all depends on how the Gnome/OpenOffice situation looks in 6 month

Solaris being ruled out on cost

FYI (and hopefully without starting the usual free beer/speech debates) - Solaris is free for use on systems with less than 8 CPU's. Admittedly, driver support is lacking in the x86 version, but you really don't need the latest video card on your server.

You can even download ISO CD images here, and make your own installation CD's.

Temkin

This html translation was generated (blindly) by StarOffice.
--

Hmmm... this quote was from a note attached to one of their recommendations. While I've been on a great number of sites that do frames very badly, frames done well can be a great benefit.

For instance, I've always been impressed with the way the Java API is layed out...