Yeah, they're going to push the envelope with XML. If they didn't, we wouldn't have XSL...
We certainly would have XSL. It was created by an American academic working at a Scottish university. When XML first appeared on the horizon back in 1997, I attended an SGML Users Group talk on XML, XSL and the proposed mathematical markup language. If I remember correctly, the academic guy's research was part funded by MS, but the ideas were his.
The funny thing about that user group meeting was that it descended into a slanging match between the XML proponents and the SGML `elitists'. The latter argued that XML and XSL were pointless when we already have SGML and DSSSL. The fact that DSSSL is poorly documented and poorly supported seems to have escaped them... They also had the same gripe about Cascading Style Sheets, which further proved that they clearly opposed anything that threatened their consultancy fees. If markup languages were made easy for the unwashed masses, it spelled doom for them.
IT staff really should know how to read a license agreement.
<sarcasm>
I'm just trying to remember where it says in my contract that I must know how to read license agreements. It must be in there, after all it's such an important skill for a programmer.
Would you and/or other members of the OpenBSD coders consider writing a book on secure, bug-free coding and auditing? Most programming books feature sample code that is written for pedagogical purposes. Quite often this runs contrary to how secure code should be written, leaving a gap in many a programmers knowledge. A book on audinting and how to avoid security pitfalls when coding would also make your life easier - less code to audit for OpenBSD, and more time top concentrate on nifty new features!!!
So, if you consider: out of the box vs out of the box... what's more friendlier? with NT I have to install a free telnetd, well.. that takes ages to do.. not. Then I have out of the box my scripting host and off I am. that is the same setup the unix sysadmin has.
Bullshit. Windows has no decent scripting langauge `out of the box'. You can install Perl, and enjoy the fact that many of the modules on CPAN are Unix specific. You could install Cygwin but I've always found it's installed as a last act of desperaration by ex-Unix admins looking for some decent tools. By the time you've gotten used to the limitations of usng things like bash on Windows your brain's turned to mush.
And all this installing of third party packages still doesn't get round the fact that Windows NT was not designed with remote administration in mind. The features simply aren't there. It was designed to be a stable workstation OS with the Windows look and feel. It's too late to go back to the drawing board now, so Microsoft are stuck with a fundamentally crippled server OS. So stop trying to come up with shallow arguments for NT as a server OS.
NEVER buy single copies unless you have less than 20 computers. ALWAYS buy a blanket copy from MS.
Or never buy an operating system that needs two licenses - one for the software itself, and one for each computer connecting to it. The company I described in my original post got suckered because:
Management chose the software
Management bought the software
IT (in other words, me and my colleagues) wouldn't have believed how stupid NT server's licensing is even if someone had told us
And remember, this was the time when all big-brand PC suppliers shipped with Windows as default. Even if we wanted SCO or Novell, we would have had to pay extra on top of the Windows tax.
how do you "easily" admin 6000 unix boxes then? ssh is not an answer...
ssh is the answer for me. I can write simple scripts and programs that lookup host dependent information from the system or my own config files. These can then be installed on remote systems using another shell script which relies on rsync and ssh. Then remote tasks (including tasks on machines in the UK, US and Australia) can be launched from my workstation. The use of NFS, ssh, cron and an installed-by-default MTA makes remote administration of a dozen Linux servers easy.
As for 6000 systems, the principles I use would scale up to that many servers without any headaches. If you mean clients, then our servers are used by many thousands more clients than that every hour. The only downside is the wholesale upgrading of the operating system (we are currently on RedHat 6.1 thanks to this), which requires the attentions of the co-location staff. However this is no easier with NT.
I've tried remote administering NT servers, and it was a nightmare. I resorted to Perl and a hacked together bunch of modules from ActiveState's earlier incarnation. The documentation was out of date, and many of the NT features it relied on didn't work or were not documented anywhere. Thankfully the software that had mandated the use of NT turned out to be highly unreliable. This meant there was enough dissatisfaction from customers to prompt a bespoke Unix solution to be developed in house.
With all due respect, but I still think a M$ network is easier to maintain than a *Nix one.
With all due respect, NT network administration is a nightmare. Try and remotely adminster a large NT setup out of the box. Sure, you can buy expensive and buggy add on software that makes remote admin possible, but it's not as easy as administering Unix. The problem is that clueless bosses and newbies see NT's GUI and think ``this must be easier than Unix''. The truth is that the investment in a little Unix knowledge pays off much better than investing in an NT `solution'.
This reminds me of the FAST visit one of my former employers suffered. FAST (the Fedaration Against Software Theft if memory serves me well), sent a polite note to the head of IT offering an `instructive talk' about software licensing. This really constituted a fact finding mission from a FAST operative, as he carefully milked our IT people (including me) for our knowledge on licensing issues.
A few weeks later FAST `offered' to audit our license situation. This was a thinly veiled accusation that are licenses were not upto snuff.
It turned out that unscrupulous or unknowing resellers (including Compaq) had failed to sell us the required licenses. They knowingly sold us systems with NT installed on them that we couldn't legally connect together on a LAN (no client licenses). In Compaq's case, they had sold us the licenses, but conveniently forgotten to ship them with the computers.
Another problem was that too many staff had access to the software lockers, and many of our Windows 95 licenses had gone walkabout along with the CDs...
The upshot of all this was that we had to buy several hundred licenses, many of which we had legally bought already. My boss also started to read those shrinkwrapped licenses *very* carefully. The client license problem was happily resolved by installing Linux on the NT file and print servers.
Last time I used OpenBSD it was gcc 2.7.2.3. Ditto for NetBSD. I know why OpenBSD's developers would pick an older compiler over the latest release, it's more tried and tested. What I was trying to point out to the original poster was the inconsistencies in his arguments.
My RH6.2 install still consistently segfaults if I run 'gtop'
No, you mean gtop - a poorly written program - segfaults. This is like saying that Windows crashed when in fact it was notepad.
As for Windows 2000 running faster than Linux - there must be something seriously wrong with your configuration of Linux. I was recently surprised to find out how appreciably slower Windows was on an identical box to mine. Opening and closing applications, saving and loading files all seem frustratingly slow on the Windows box.
We shipped pgcc only for one release and we didn't do the same errors again since then...
I tried the Mandrake distribution once, when it's main selling point was the Pentium optimised compiler, but reverted back to RedHat when I changed jobs. If Mandrake are considering a regularily updated SPARC distribution as well as their Intel one then I'd be keen to try it again.
He's talking about the embedded market, where eCos has a much more significant role than you realise. BSD based code does make an impact in this area, (for example, OpenBSD's Theo de Raadt has been contracted to port code to such systems), but eCos is designed specifically for the embedded market.
You're obviously clueless, but I'll bite. After all I am on my lunchbreak...
Compare this with Windows, which has test periods of a year or more for new Windows releases.
Would you really trust your company to a distro that ships a broken compiler?
Read bugtraq, and learn just how stable and secure those tested versions of Windows are. Not very. As for a `broken' compiler, try Visual C++ 5.0 which was notoriously broken. RedHat's GCC snapshot was only `broken' in the respect that it was binary incompatble with preceding versions and the upcoming version 3.0. They had very good reasons to ship a snapshot, not the least of which was the fact that it produced better object code than 2.95.2. The alternative was to stick with egcs-1.1.2, which is getting exceptionally long in the tooth. If you really want to criticise a Linux distributor for shipping dodgy compilers, then turn your attention to Mandrake. They shipped the Pentium optimised `pgcc', which is known to produce incorrect assembler output.
> > [Why the broken compiler?]
This doesn't make an eachway-incompatible compiler a good idea. What it does say, however, (his words not mine) is that
(a) the current compiler is a POS
(b) we're using an incompatible, and immediately obsolete compiler.
Doesn't really encourage you to use Linux, rather than say, Windows, *bsd or Solaris, does it - the current compiler sucks
It wont encourage you unless you know how poor Microsoft or Sun's compilers are. As for BSD you clearly are clueless, as they use aging versions of gcc. Microsoft have yet to produce an ANSI C compliant compiler, let alone an ANSI C++ compliant one. As for Sun's compiler suite, they no longer ship it by default with Solaris, and many of the companies I have worked for use gcc instead out of preference. In other words, they have a Sunpro licence, but don't bother installing it.
These patches are indicative of the unstable state of Linux development... (see Mandrake for a desktop product, not that it's a patch on Windows or Mac)
Let's see - my desktop machine has not crashed once since I installed RedHat 6.2 on it four months ago. It has all the tools that my colleague's Windows PC has, and more (ever tried grep'ing or find'ing on a PC?). In the same time the programmer to my immediate left has reinstalled Windows twice, and the Mac programmer is lucky if he get four hours of uptime.
As for your inference that Windows software is easier to use, try Visual C++ some time. Their is no source control as standard, and the API's are dreadful (dodgy socket libraries for example).
Chris
If I have a Sparc driven machine why should I use this toy for Intel(and now also for Sparc) called Linux?
Your `toy' comment clearly indicates you're a troll, as does your bizarre claim to prefer using Solaris on an Intel box, however I'll credit you with a response.
Try running recent versions of Solaris on older Sun hardware - it's no longer supported and on some configurations simply wont work. In contrast, Linux (along with OpenBSD and NetBSD) runs faster than Solaris, and works with a wide range of old Sparc hardware. Couple this with the increasing number of applications available for Linux, and you have a very sound reason to use Linux on a Sparc.
I for one would love to run OpenBSD on my Sparc - but none of the BSD's support 24 bit framebuffers. If I could afford to donate a Leo framebuffer to the OpenBSD team I would, but at about £500 for a second hand one I can't really stretch to it.
I have considered doing the port of NEdit to Gtk+, but as I don't know Motif, it would be quite difficult.
The topic of porting to GTK+ comes up regularily on the NEdit mailing list - a bit like the C++ threads on the Linux Kernel mailing list. NEdit uses the Xt convenience functions a hell of a lot, so porting it to GTK+ wouldn't be much fun. Porting to Qt using TrollTechs QXt extension would probably be easier.
Same here - not impressed. Sun has people hooked and they don't know better.
When you're talking about *real* installations doing *real* computing work then Sun has people hooked because their hardware scales well. You could of course take the Yahoo! route of having massive amounts of simple Intel boxes, but for seriously intensive tasks a couple of big Sun machines are a lot less hassle. Rather than having to piss around with RPC or CORBA to synch up many computers working on the same problem, you can simply code your application(s) without regard for parallel computing issues.
In my new job, we use Sun computers. My observation is that they are amazingly slow GUI tools (which I don't use; I am in a 20 year time warp, back to vi and dbx)
The Sun software leaves a lot to be desired (run OpenBSD or SparcLinux rather than Slowaris), but the hardware is fantastic. You can even run SparcLinux on an E10000 - and apparently it compiles the Linux kernel in ~20 seconds. I doubt if your Win98 box can match that...
"Doesn't suffer the incompatability problems of cheap PC parts"
For the most part this is true...but check out the SCSI connectors on the Ultra 1 and Ultra 1 Creator. Yay for gratuitous incompatibility
Ahem. I remember trying to get a printer lead for my Sparc and HP Deskjet. The normally reliable Black Box peripheral people assured me they could get the right lead for... 60 pounds sterling!!! The lead turned out to be the wrong one, and I wasn't even entitled to a refund, just a poxy credit slip. Eventually I got one from a very small Sun reseller for a tenner.
Yup, and I wasn't saying otherwise, although I suppose it could easily be inferred from my comment. I have even come across a few clones like the Opus ones, but not Fujitsu's.
For info on all things Sun, chekc out www.sunhelp.org, which includes great info on older Sun models if you're ever thinking of buying one.
My first encounter with Sun products was when a SparcStation 1+ was offloaded onto my desk. My employer at the time wanted an FTP server, and the budget wouldn't run to a new machine. Consequently, the sys admin put together the SS1+ from a box of Sparcs abandoned by the company typesetters.
That machine ran for years, with the only downtime occuring when I switched from SunOS to Linux (RedHat 4.2 - the first distro I remember that actually outshone the commercial Unices).
Since then, I have worked on a mix of Sun and Intel hardware, but have always favoured the former for its reliability. While PC's are cheap, thanks mainly to the proliferation of clones and myriad peripheral manufacturers, many reliability and performance problems stem from the subtle incompatabilities of PC parts.
Most Sun computers contain nothing but Sun manufactured parts - although many parts are simply rebranded third party bits. For instance, my CD drive is a Toshiba with a Sun fascia, but it has been tested thoroughly for compatability and reliablity. This means higher prices, but when I plugged the CD drive into my Sparc 5 back in '96, I had a greater expectation that it'd work than friends plugging CD drives into their PC's.
This 'monopoly' on hardware often garners criticism from Apple's detractors, especially after they pulled the plug on Mac clones. However, Apple hardware shares the increased reliability of Sun equipment in part thanks to this 'monopoly'.
The problem with Sun hardware is that it's simply too expensive for what it does.
Let's see. Sun hardware does the following:
Runs reliably for years.
Doesn't suffer the incompatability problems of cheap PC parts
Keeps the room warm
Costs a lot
Prevents your kid brother playing games on it
And (most importantly) looks good
You're right when you say that PC's can perform most tasks a Sun workstation can do, but I've yet to see a PC come close to a Sun server for performance, scalability or reliability.
Slashdot Mirror
Yeah, they're going to push the envelope with XML. If they didn't, we wouldn't have XSL ...
We certainly would have XSL. It was created by an American academic working at a Scottish university. When XML first appeared on the horizon back in 1997, I attended an SGML Users Group talk on XML, XSL and the proposed mathematical markup language. If I remember correctly, the academic guy's research was part funded by MS, but the ideas were his.
The funny thing about that user group meeting was that it descended into a slanging match between the XML proponents and the SGML `elitists'. The latter argued that XML and XSL were pointless when we already have SGML and DSSSL. The fact that DSSSL is poorly documented and poorly supported seems to have escaped them... They also had the same gripe about Cascading Style Sheets, which further proved that they clearly opposed anything that threatened their consultancy fees. If markup languages were made easy for the unwashed masses, it spelled doom for them.
Chris
IT staff really should know how to read a license agreement.
<sarcasm>
I'm just trying to remember where it says in my contract that I must know how to read license agreements. It must be in there, after all it's such an important skill for a programmer.
</sarcasm>
Chris
Would you and/or other members of the OpenBSD coders consider writing a book on secure, bug-free coding and auditing? Most programming books feature sample code that is written for pedagogical purposes. Quite often this runs contrary to how secure code should be written, leaving a gap in many a programmers knowledge. A book on audinting and how to avoid security pitfalls when coding would also make your life easier - less code to audit for OpenBSD, and more time top concentrate on nifty new features!!!
Chris
So, if you consider: out of the box vs out of the box... what's more friendlier? with NT I have to install a free telnetd, well.. that takes ages to do.. not. Then I have out of the box my scripting host and off I am. that is the same setup the unix sysadmin has.
Bullshit. Windows has no decent scripting langauge `out of the box'. You can install Perl, and enjoy the fact that many of the modules on CPAN are Unix specific. You could install Cygwin but I've always found it's installed as a last act of desperaration by ex-Unix admins looking for some decent tools. By the time you've gotten used to the limitations of usng things like bash on Windows your brain's turned to mush.
And all this installing of third party packages still doesn't get round the fact that Windows NT was not designed with remote administration in mind. The features simply aren't there. It was designed to be a stable workstation OS with the Windows look and feel. It's too late to go back to the drawing board now, so Microsoft are stuck with a fundamentally crippled server OS. So stop trying to come up with shallow arguments for NT as a server OS.
Chris
NEVER buy single copies unless you have less than 20 computers. ALWAYS buy a blanket copy from MS.
Or never buy an operating system that needs two licenses - one for the software itself, and one for each computer connecting to it. The company I described in my original post got suckered because:
And remember, this was the time when all big-brand PC suppliers shipped with Windows as default. Even if we wanted SCO or Novell, we would have had to pay extra on top of the Windows tax.
Chris
how do you "easily" admin 6000 unix boxes then? ssh is not an answer...
ssh is the answer for me. I can write simple scripts and programs that lookup host dependent information from the system or my own config files. These can then be installed on remote systems using another shell script which relies on rsync and ssh. Then remote tasks (including tasks on machines in the UK, US and Australia) can be launched from my workstation. The use of NFS, ssh, cron and an installed-by-default MTA makes remote administration of a dozen Linux servers easy.
As for 6000 systems, the principles I use would scale up to that many servers without any headaches. If you mean clients, then our servers are used by many thousands more clients than that every hour. The only downside is the wholesale upgrading of the operating system (we are currently on RedHat 6.1 thanks to this), which requires the attentions of the co-location staff. However this is no easier with NT.
I've tried remote administering NT servers, and it was a nightmare. I resorted to Perl and a hacked together bunch of modules from ActiveState's earlier incarnation. The documentation was out of date, and many of the NT features it relied on didn't work or were not documented anywhere. Thankfully the software that had mandated the use of NT turned out to be highly unreliable. This meant there was enough dissatisfaction from customers to prompt a bespoke Unix solution to be developed in house.
Chris
With all due respect, but I still think a M$ network is easier to maintain than a *Nix one.
With all due respect, NT network administration is a nightmare. Try and remotely adminster a large NT setup out of the box. Sure, you can buy expensive and buggy add on software that makes remote admin possible, but it's not as easy as administering Unix. The problem is that clueless bosses and newbies see NT's GUI and think ``this must be easier than Unix''. The truth is that the investment in a little Unix knowledge pays off much better than investing in an NT `solution'.
If you want some more info on this check out http://www.unix-vs-nt.org/kirch/.
Chris
This reminds me of the FAST visit one of my former employers suffered. FAST (the Fedaration Against Software Theft if memory serves me well), sent a polite note to the head of IT offering an `instructive talk' about software licensing. This really constituted a fact finding mission from a FAST operative, as he carefully milked our IT people (including me) for our knowledge on licensing issues.
...
A few weeks later FAST `offered' to audit our license situation. This was a thinly veiled accusation that are licenses were not upto snuff.
It turned out that unscrupulous or unknowing resellers (including Compaq) had failed to sell us the required licenses. They knowingly sold us systems with NT installed on them that we couldn't legally connect together on a LAN (no client licenses). In Compaq's case, they had sold us the licenses, but conveniently forgotten to ship them with the computers.
Another problem was that too many staff had access to the software lockers, and many of our Windows 95 licenses had gone walkabout along with the CDs
The upshot of all this was that we had to buy several hundred licenses, many of which we had legally bought already. My boss also started to read those shrinkwrapped licenses *very* carefully. The client license problem was happily resolved by installing Linux on the NT file and print servers.
Chris
[root@brick /root]# uname -a /root]# gcc --version
OpenBSD brick 2.8 GENERIC#3 i386
[root@brick
2.95.3
That doesn't seem very aging to me ...
Last time I used OpenBSD it was gcc 2.7.2.3. Ditto for NetBSD. I know why OpenBSD's developers would pick an older compiler over the latest release, it's more tried and tested. What I was trying to point out to the original poster was the inconsistencies in his arguments.
My RH6.2 install still consistently segfaults if I run 'gtop'
No, you mean gtop - a poorly written program - segfaults. This is like saying that Windows crashed when in fact it was notepad.
As for Windows 2000 running faster than Linux - there must be something seriously wrong with your configuration of Linux. I was recently surprised to find out how appreciably slower Windows was on an identical box to mine. Opening and closing applications, saving and loading files all seem frustratingly slow on the Windows box.
Chris
We shipped pgcc only for one release and we didn't do the same errors again since then ...
I tried the Mandrake distribution once, when it's main selling point was the Pentium optimised compiler, but reverted back to RedHat when I changed jobs. If Mandrake are considering a regularily updated SPARC distribution as well as their Intel one then I'd be keen to try it again.
Chris
Huh ? The critical mass of 'eCos' vs 'BSD's ?
He's talking about the embedded market, where eCos has a much more significant role than you realise. BSD based code does make an impact in this area, (for example, OpenBSD's Theo de Raadt has been contracted to port code to such systems), but eCos is designed specifically for the embedded market.
Chris
You're obviously clueless, but I'll bite. After all I am on my lunchbreak ...
Compare this with Windows, which has test periods of a year or more for new Windows releases.
Would you really trust your company to a distro that ships a broken compiler?
Read bugtraq, and learn just how stable and secure those tested versions of Windows are. Not very. As for a `broken' compiler, try Visual C++ 5.0 which was notoriously broken. RedHat's GCC snapshot was only `broken' in the respect that it was binary incompatble with preceding versions and the upcoming version 3.0. They had very good reasons to ship a snapshot, not the least of which was the fact that it produced better object code than 2.95.2. The alternative was to stick with egcs-1.1.2, which is getting exceptionally long in the tooth. If you really want to criticise a Linux distributor for shipping dodgy compilers, then turn your attention to Mandrake. They shipped the Pentium optimised `pgcc', which is known to produce incorrect assembler output.
> > [Why the broken compiler?]
This doesn't make an eachway-incompatible compiler a good idea. What it does say, however, (his words not mine) is that
(a) the current compiler is a POS
(b) we're using an incompatible, and immediately obsolete compiler.
Doesn't really encourage you to use Linux, rather than say, Windows, *bsd or Solaris, does it - the current compiler sucks
It wont encourage you unless you know how poor Microsoft or Sun's compilers are. As for BSD you clearly are clueless, as they use aging versions of gcc. Microsoft have yet to produce an ANSI C compliant compiler, let alone an ANSI C++ compliant one. As for Sun's compiler suite, they no longer ship it by default with Solaris, and many of the companies I have worked for use gcc instead out of preference. In other words, they have a Sunpro licence, but don't bother installing it.
These patches are indicative of the unstable state of Linux development ... (see Mandrake for a desktop product, not that it's a patch on Windows or Mac)
Let's see - my desktop machine has not crashed once since I installed RedHat 6.2 on it four months ago. It has all the tools that my colleague's Windows PC has, and more (ever tried grep'ing or find'ing on a PC?). In the same time the programmer to my immediate left has reinstalled Windows twice, and the Mac programmer is lucky if he get four hours of uptime.
As for your inference that Windows software is easier to use, try Visual C++ some time. Their is no source control as standard, and the API's are dreadful (dodgy socket libraries for example).
Chris
If I have a Sparc driven machine why should I use this toy for Intel(and now also for Sparc) called Linux?
Your `toy' comment clearly indicates you're a troll, as does your bizarre claim to prefer using Solaris on an Intel box, however I'll credit you with a response.
Try running recent versions of Solaris on older Sun hardware - it's no longer supported and on some configurations simply wont work. In contrast, Linux (along with OpenBSD and NetBSD) runs faster than Solaris, and works with a wide range of old Sparc hardware. Couple this with the increasing number of applications available for Linux, and you have a very sound reason to use Linux on a Sparc.
Chris
Why not run OpenBSD
I for one would love to run OpenBSD on my Sparc - but none of the BSD's support 24 bit framebuffers. If I could afford to donate a Leo framebuffer to the OpenBSD team I would, but at about £500 for a second hand one I can't really stretch to it.
Chris
I have considered doing the port of NEdit to Gtk+, but as I don't know Motif, it would be quite difficult.
The topic of porting to GTK+ comes up regularily on the NEdit mailing list - a bit like the C++ threads on the Linux Kernel mailing list. NEdit uses the Xt convenience functions a hell of a lot, so porting it to GTK+ wouldn't be much fun. Porting to Qt using TrollTechs QXt extension would probably be easier.
Chris
Put NetBSD and OpenBSD users in the same small room with locked door and there will be peace, understanding and camaradarie.
Just don't try putting the NetBSD and OpenBSD *developers* in the same small room. The resulting bloodshed would be terrifying.
Chris
and I've been using Linux since 1990
...
IIRC the first public release of the Linux kernel was 1991. So not only are you are troll, you're also a liar
Chris
On the windows front, Mozilla is going to have more of a struggle against MSIE
It'll be interesting to see what AOL does with Netscape 6. If they decide to replace IE with it then we could see a massive dent in IE's market share.
Chris
... they lick each other's asses ...
Actually, we sniff each other's arses. We only lick our own arses. And remember, on the Internet, no one knows you're a dog.
Chris
Same here - not impressed. Sun has people hooked and they don't know better.
When you're talking about *real* installations doing *real* computing work then Sun has people hooked because their hardware scales well. You could of course take the Yahoo! route of having massive amounts of simple Intel boxes, but for seriously intensive tasks a couple of big Sun machines are a lot less hassle. Rather than having to piss around with RPC or CORBA to synch up many computers working on the same problem, you can simply code your application(s) without regard for parallel computing issues.
Chris
In my new job, we use Sun computers. My observation is that they are amazingly slow GUI tools (which I don't use; I am in a 20 year time warp, back to vi and dbx)
...
The Sun software leaves a lot to be desired (run OpenBSD or SparcLinux rather than Slowaris), but the hardware is fantastic. You can even run SparcLinux on an E10000 - and apparently it compiles the Linux kernel in ~20 seconds. I doubt if your Win98 box can match that
Chris
"Doesn't suffer the incompatability problems of cheap PC parts"
... 60 pounds sterling!!! The lead turned out to be the wrong one, and I wasn't even entitled to a refund, just a poxy credit slip. Eventually I got one from a very small Sun reseller for a tenner.
For the most part this is true...but check out the SCSI connectors on the Ultra 1 and Ultra 1 Creator. Yay for gratuitous incompatibility
Ahem. I remember trying to get a printer lead for my Sparc and HP Deskjet. The normally reliable Black Box peripheral people assured me they could get the right lead for
Chris
there ARE Sun clones available
Yup, and I wasn't saying otherwise, although I suppose it could easily be inferred from my comment. I have even come across a few clones like the Opus ones, but not Fujitsu's.
For info on all things Sun, chekc out www.sunhelp.org, which includes great info on older Sun models if you're ever thinking of buying one.
Chris
My first encounter with Sun products was when a SparcStation 1+ was offloaded onto my desk. My employer at the time wanted an FTP server, and the budget wouldn't run to a new machine. Consequently, the sys admin put together the SS1+ from a box of Sparcs abandoned by the company typesetters.
That machine ran for years, with the only downtime occuring when I switched from SunOS to Linux (RedHat 4.2 - the first distro I remember that actually outshone the commercial Unices).
Since then, I have worked on a mix of Sun and Intel hardware, but have always favoured the former for its reliability. While PC's are cheap, thanks mainly to the proliferation of clones and myriad peripheral manufacturers, many reliability and performance problems stem from the subtle incompatabilities of PC parts.
Most Sun computers contain nothing but Sun manufactured parts - although many parts are simply rebranded third party bits. For instance, my CD drive is a Toshiba with a Sun fascia, but it has been tested thoroughly for compatability and reliablity. This means higher prices, but when I plugged the CD drive into my Sparc 5 back in '96, I had a greater expectation that it'd work than friends plugging CD drives into their PC's.
This 'monopoly' on hardware often garners criticism from Apple's detractors, especially after they pulled the plug on Mac clones. However, Apple hardware shares the increased reliability of Sun equipment in part thanks to this 'monopoly'.
Chris
The problem with Sun hardware is that it's simply too expensive for what it does.
Let's see. Sun hardware does the following:
Runs reliably for years.
Doesn't suffer the incompatability problems of cheap PC parts
Keeps the room warm
Costs a lot
Prevents your kid brother playing games on it
And (most importantly) looks good
You're right when you say that PC's can perform most tasks a Sun workstation can do, but I've yet to see a PC come close to a Sun server for performance, scalability or reliability.
Chris