Slashdot Mirror


User: svet

svet's activity in the archive.

Stories
0
Comments
5
First seen
Last seen
Profile
(view on slashdot.org)

Comments · 5

  1. Is this really a bad idea? on Sun Considers Switching Cobalt to Solaris · · Score: 3

    Solaris on the Cobalt RaQ and Qubes might not be a bad idea in many ways, from both Sun's and Cobalts point of view. Also, it could benefit the end user as well. Consider the following, just for a moment.

    1) Sun needs a foothold the low-end market. A conspiracy theorist could see that Sun is just trying to expand their empire, and with some just cause. Though Sun's competition has been makers of other higher-end systems (DEC, IBM, etc), all these companies have been feeling a loss to x86-based servers running Windows or Linux. In some ways, this has put a very strong line between who rules the high-end and who rules the low-end. However, when it comes to the bottom line, Sun could be making mroe because it is easier to sell more cheaper boxes with a cheaper OS. So, Sun does a couple of things: Make Solaris 8 free (sans media cost) for under eight processors and increased support for the x86 platform as well as addming many popular GNU tools found in Linux, FreeBSD, etc (an ironic fact if you looks at the history of Solaris or SunOS). Now, you say Solaris has x86 support. Yes, but it leaves something to be desired. However, something Sun knows how to do well is write to a very specific set of hardware. Sun writes Solaris for UltraSPARC based servers. There is only very variance in hardware, unlike the x86 world, where it is a hardware goulash. So, Sun takes Cobalt, which is very inexpensive (if you have ever looked inside a RaQ, you'll hate yourself for not coming up with so simple five years ago) *and* only uses a certain hardware. It would be easier for Sun to optimize for the RaQ than to try to make every x86 user happy. They end up with a more stable x86 offering and don't have to change a thing to the already cheap hardware. They are again competitive with the real leaders in the Server market. Face it, Sun can only sell so many mammoth Sun boxes nowdays. Talk to any Sun sales rep. They feel the pinch badly. So in the end, Sun gets with the times in a buisness sense. Produce a inexpensive, stable server with the Sun name, and not have to re-invent the wheel. Though it is too early to see, Sun could be making a step in the right direction an it could also solve a problem the Cobalt is having, stability. As for OS supremacy, Sun makes no real profit in that Microsoft since on their OS. Sun makes hardware. That is their bread and butter, not this stagnantly evolving mish-mash of BSD and System V. Sun changes Solaris to work better on their hardware. They are not big "feature" mongers.

    2) Cobalt needs Sun. Now, before you begin to flame me for possibly hinting that Linux uis unstable, that is not what I will be talking about here. Cobalt made a mistake early on, and it wasn't choosing Linux, it was not making a strong push into a hardware platform. Cobalt started on MIPS and went through great pains to make their special version of RedHat 5.2 and assorted packages run on the MIPS processor as well as their highly-flaunted web-based administration software. By RaQ2, they got it somewhat stable and really started selling. However, their were issues with their administration interface and theiur lack of 3rd party support. One was do to a software development platform, the other, hardware.
    Yes, the Cobalt "special sauce" is very perl based, however, their is a nice helpinf of servlets about. Though IBM has made great strides with Java on Linux, they weren't around at the time. The Perl/CGI and Java combo on Linux, from by point of view as a developer, is a match made in hell. I wouldn't do it on any other OS. Also, the JVM support wasn't that great on MIPS either. Overall, scalibility suffered on these boxes. Also, if you ever dared to go beyond their static administration environment, you broke that special sauce. It is not a picnic to fix. Combine this with the fact that many applications (RealServer, Oracle 8i, iPlanet/Netscape servers, Sybase, etc) that run fine on x86 Linux, could not run at all on the RaQs due to MIPS. Cobalt made the change to x86. The migration was an absolut nightmare. They drop all MIPS support on the RaQ3 so they can get better Java support and support more 3rd party apps. Well, they never coudl get a migration package to work between the older RaQs and the newer ones. Cobalt didn't write Linux, of course, they knew how to make cheaop hardware and a very *large* and convoluted web app. Cobalt planned an easier migration to x86, however, never considered all they needed to do to revert the "altered RedHat" back to x86 and make the according changeds to their app. This seems like it would be easy, however, it seems that Cobalt made things harder. I don't believe that they stuck with 5.2 as their base for trhe RaQ3, and it the structure changes broke all their platform-indepedant code they chose not to rewrite very well. Cobalt sales go down since they don't support this mess very well, as they made very little changes to fix this. Cobalt made bad desicions in changing to much of their original formula. Their product suffered. Along come Sun, with an OS that rarely changes general format. Cobalt can do what they do best: make cheap hardware and write a very user-friendly interface to a OS that supports all those lovely 3rd party apps the customers want. Cobalt's formula doesn't take well to massive hardware or software changes. They made that boat. Sun could possible save it from sinking. Was it the best boat? Maybe not, however, Cobalt really wanted the whole thing to be cheap and have the customer touch little of the OS as possible. Cobalt *could* have made their product work just fine on x86 and Linux and made it very stable. They chose not to make that effort. Now, the Java support will be top of the line. Sheesh.

    3) Lastly, the customers. These are they people that actually matter in this whole thing. The people who by this to do what they want without having to be geeks. People who want their little mom and pop internet shops or web hosters. They pay for these Cobalt boxes and don't want to worry about their nice user interface not working with the OS or worrying that more hardware changes means they can't upgrade as needed due to bad implementation. They change could benefit the customers. The majority of Cobalt customers don't mess with the OS, since it breaks their pretty interface. This important, since these people don't want to be geeks, they just want get a server online cheaply with the smallest learning curve and have it work right. This could solve that. This is not meant to be a geek's server. This is your mom or dad's server. When Cobalt can't make these servers upgrade smootly, mom and dad cease buying more servers. This *could* be remedied now.

    Closing: Sun keeps the RaQ on the x86 path with a static OS. Sun gets their foot in the low-end door. The customers hopefully get what was advertised in the beginning: a low-maintainence, cheap, stable web server that is easy to run and that doesn't require hundreds of hours of pouring over FAQs and arcane tomes to administrate. The catch: Sun. Sun will be new to this market. They could take Cobalt's implementation and make it worse by doing the same thing that Cobalt did: change without forethought. This would include price increase. That would be the worse thing Sun could do, as it would show that they just don't get it. Sun has the ability to make Cobalt's implementation work, as long as the customers get what they pay for in the end. Unfortunatly for Linux fans, it will be without Tux. Could of this been avoided? Yes, easily. Sun may of never came into the picture if that were the case.

  2. Translation from a native :-) on MS Office on Linux (Continued) · · Score: 1

    Good, a decent translation...I was about to do it myself..I had a hearty laugh after I took a look at the babelfish version after reading the original article on the c't site.

  3. I'm a junkie on LinuxWorld Show Favorites · · Score: 1

    S.u.S.E = Systems und Software Entwicklung, If I remember it correctly. Translated from German to English - System and Software Development.

  4. S.u.S.E. != "sweet" on LinuxWorld Show Favorites · · Score: 1

    I wouldn't say you exactly full of it, but a bit off...The German word for 'sweet' is suess...which would be pronounced different than 'SuSE' would be in German or even 'suesse'(I'll spare the German lesson here on why that is) ..Hmm a good American equivalent...hmm, try 'zoo-zuh' ..very light on the z, less fricative than usual and the second syllable is short and unstressed..(isn't the phoenetic alphabet supposed to resolve these questions..*snicker*) However, I like your version better than 'suzy'..that drives me up a wall for some reason...

  5. Walk Down Memory Lane on Enormous 80s Textfile Archive · · Score: 1

    It's about time. Sometimes you forget that any of
    this happened anymore, especially when you "grow-up" and have some way of getting on the Internet. Back then, it was some great entertainment. I still feel that BBSs were more personal, on a level that the web has yet or may never achieve. I've only taken a quick glance of
    the sight and have already found tons of files
    I read so many years ago, many I have on the disks
    of some old crappy C64 or IBM PC. I love the layut of the sight, since I viewed the whole BBS world
    from my lovely green-on-black monochrome monitor and ran my own BBS from the same view, collecting all that stuff...Then again, now looking at my Xterm now up right now on my laptop...I notice the same green/black
    scheme. Maybe something never do change. Hmm, Where was that stack of floppies again? I'm sure I've got a 5 1/4 drive here somewhere...and a C64 emulator.