Slashdot Mirror
Sun Announces New x86 Servers
An anonymous reader writes "Sun announced the new V60x and V65x servers (1U and 2U respectively). The 1U has 2.8GHz Xeon CPUs and the 2U has 3.06GHz Xeon CPUs. They also announced a partnership with RedHat and Oracle running on these boxes. RedHat will also start shipping Sun's Java with their distribution."
CowboyNeal is one huuuuuuuuuuuuuuge dude. Take a gander at the fat lummox himself.
FP for me, knobgobblers!
Why did the chicken cross the road?
To be eaten by the huuuuuuuuuuuuuuge CowboyNeal.
Way to rip off my schtick, there Jethro. ;-(
He needs two screens to read slashdot.org!
Well, at least the X3 producers can stop looking for someone to play Blob now.
Bah I say, Bah! I read slashdot so I KNOW this is astroturfing! Why, my i-semisharpiepod PDA does all the SAME EXACT THINGS, and costs much less money! And it's wideopensource! It's easy! All you have to do is dremel tool the case open, replace the mobo, cpus, ram, screen,power supply, throw in a few small scsi HDDs using RAIDioactive 5, then add the seekrit xyzBox "mod" chips that you can get from your friendly off shore supplier in sealand. Next, download the gentilenix OS ISO's from lotsabitsytinytorrential P2P people's servers over your 802.11z turbo wireless connection, compile for a few weeks, tweak a few minor files,throw a few scripts at it, and you're IN LIKE FLINT!
Piece a cake! Not only my grandmother, but YOUR grandmother could do it! And it's wearable! And it has an added bonus of playing reallyunrealdoomtournament in 4 dimensions, with the sounds in 3ggZ 0vr.3_Z format!! WHAT'S NOT TO LIKE!!1??11
Talk about security, no one can get to your co-lo and "social engineer" their way into your servers unless you get mugged, and that's why you have the thinquegreek coke bottle night vision eye glasses with frickin lasers on them! And if you want a "rack" mount, you just hire a local stripper to carry it around for you! Now, which would YOU rather have? Hmmm?
...it took 35 seconds to load his picture on a broadband connection.
I am TheRaven on Soylent News
OK, so I answered "C". I am going to make bold the claim that HTTP: The Definitive Guide, the long-awaited O'Reilly book on HTTP is ambitious enough in breadth and depth that if you answered "B", "C", or "D", you will find this book useful and informative. This is primarily due to clear organization of the book, as well as its friendly (even chummy) writing style.
:-)
Even if you are a technically-inclined sort from the Marketing department, and answered "A", you could get a good technical overview of the plumbing of the Web by skimming through this book; plus, having any O'Reilly book on the shelf in your cubicle would score you some street cred with the guys sitting over in Development - this could be the one you've actually read.
Breadth
Unless you answered "D", HTTP is more complicated than you think. This is especially true if, as the authors of a good technical book should do (and these authors do), one spends some time touching on matters one level down (to TCP/IP, and other areas, in this case), and one level up (to HTML, generally, in this case). Because the authors are particularly concerned with HTTP performance, details of the interactions between HTTP and adjacent levels can be important.
The book is divided into five main sections: 1) an overview of HTTP, URLs, and connection management; 2) HTTP Architecture, including Web servers, proxies, caches, gateways, tunnels, robots; 3) Identification, Authorization, and Security; 4) Entities, Encodings, and Internationalization; 5) Content Publishing and Distribution, including hosting, publishing, load balancing, logging. So, even if you classify yourself as a "D", or even if you are hacking on an extensible open-source router software platform (in that case, you are an "F"), you will find yourself pulling this book from the shelf from time to time to check on something in one of these areas. The modular organization of the book is good.
The full Table of Contents is available on line.
Depth
One (unfortunate?) thing about the Web is that its "architecture" (if you can even call it that) evolved and grew piece by piece. The design goals people had in mind back in 1993, or even in 1999, have been blown away by what has happened on the ground. Inter-company politics have also been a big factor - never helpful for promoting standardization, or sound design. (Perhaps another problem has been the lack of an O'Reilly book on HTTP to tie everything together!) Hence, not only do you have a confusing mass of obsolete and/or overlapping specifications documents, you also have major differences between how different browsers, servers, and proxies adhere to these specifications in practice. This is one place the book shines: sprinkled throughout the pages are little tidbits about compatibility or performance pitfalls, gleaned from much practical experience. (The authors were some of the architects of Inktomi's Traffic Server "enterprise class" Web cache. Think "proxy caching for all of AOL's Web traffic.") As one example: "Technically, any Connection header fields (including Connection: Keep-Alive) received from an HTTP/1.0 device should be ignored, because they may have been forwarded mistakenly by an older proxy server. In practice, some clients and servers bend this rule, although they run the risk of hanging on older proxies." I can just imagine the series of bug reports leading to the inclusion of that piece of advice in the book. There are many other such warnings and bits of advice, generally aimed at HTTP application developers, often with an eye to performance tuning.
Here again, appropriate depth of discussion for a variety of readers is handled by clear organization of the book. The basic background material is laid out, and as the authors dive deeper into detail they may make a suggestion like, "If you are [not] writing high-performance HTTP software... feel free to skip ahead." Then, at the end of every chapter, there is a section labelled, "For More Information," which is a collection of rele