P4 Xeon compatibility with 5.0.5
Jeff Davis
to be able to do this in a couple of stages as I can't afford to upgrade
the server and the OS at the same time. We are currently running SCO
5.0.5 and I was looking at the HP ML350 which has a P4 Xeon running at
2.2 Ghz. Will 5.0.5 run on this computer or should I look at getting
something a bit older like a Pentium III 700? What kind of troubles
would I run into trying to install an older OS on such a new model
computer? I am almost thinking to get the upgraded OS first and then
upgrade the server later, but I need to make a move soon as my current
hardware is aging. Any and all suggestions would be appreciated.
Thanks,
Jeff
Joe Dunning
Well, you said "all suggestions", so here is one:
1. Get a lawyer to look at your license agreement to see if the
following is allowed.
2. Transfer the license for your 5.0.5 to your new hardware.
3. Configure it for dual-booting and install some flavor of Linux.
4. Use the libraries from 5.0.5 and Linux-ABI to run the non-Linux
applications you need on Linux. You will need to ensure that the
libraries remain on the licensed system. This may simply be a matter of
putting the old disk into the new system as a secondary disk.
5. Congratulate youself on saving $$$s!
If you can get the legal advice for free or you feel confident to read
and understand your license agrement for yourself, then all you have to
do is to buy new hardware. I am not a lawyer, and I have not seen your
license agreement so I can't tell you if the above is allowed by your
license agreement.
Scott Burns
<SNIP>
>3. Configure it for dual-booting and install some flavor of Linux.
>
>
<SNIP>
Hmmm, a whole 84 minutes before someone suggested dumping SCO for Linux.
We must be slowing down :P
--
Scott Burns
Mirrabooka Systems
Tel +61 7 3857 7899
Fax +61 7 3857 1368
Bill Vermillion
This has been discussed here in the past but I can not point you to
the exact place. But there are some timing issues on the P4 with
older versions. This was fixed in teh 5.0.6. I'd go for upgrade
on the OS then the HW then the the speed issues will have been
resolved at the OS level.
--
Bill Vermillion - bv @ wjv . com
ryan rothert
Jeff,
I just did the same thing for a customer of mine. I had to upgrade
an old Pentium II 5.0.5 system because the hardware was dying. I talked
to SCO pre-sales support and they said I needed to go with 5.0.7 (or
something newer than 5.0.5) for the P4 Xeon support. So we purchased the
OS upgrade and an IBM x225 series "SCO approved" server. Once we had the
right OS, the install was flawless. I highly recommend the IBM hardware.
Ryan Rothert
ryan at rothert dot com
ryan rothert
>
>
> 1. Get a lawyer to look at your license agreement to see if the
> following is allowed.
> 2. Transfer the license for your 5.0.5 to your new hardware.
> 3. Configure it for dual-booting and install some flavor of Linux.
> 4. Use the libraries from 5.0.5 and Linux-ABI to run the non-Linux
> applications you need on Linux. You will need to ensure that the
> libraries remain on the licensed system. This may simply be a matter of
> putting the old disk into the new system as a secondary disk.
> 5. Congratulate youself on saving $$$s!
>
> If you can get the legal advice for free or you feel confident to read
> and understand your license agrement for yourself, then all you have to
> do is to buy new hardware. I am not a lawyer, and I have not seen your
> license agreement so I can't tell you if the above is allowed by your
> license agreement.
Joe,
This really isnt the place for this. I think most people are fed up with
the SCO fiasco, but some people/customers still use SCO software and
not matter the outcome of the lawsuit, these people wont be able to move
way from it anytime soon. I consider myself a linux advocate/geek, but my
day job requires me to support paying customers some of which use SCO
products. Posting such rants to this newsgroup will do little to help the
linux bandwagaon and open source cause.
I dont like what the SCO executives are doing. I do have customers to
support that use SCO. This newsgroup is a good resource for anyone who
has to support SCO prodcuts. Please post this kind of thing in the linux
advocacy groups, Its not welcome here.
Ryan
Joe Dunning
>> Well, you said "all suggestions", so here is one:
>>
>>
>> 1. Get a lawyer to look at your license agreement to see if the
>> following is allowed.
>> 2. Transfer the license for your 5.0.5 to your new hardware.
>> 3. Configure it for dual-booting and install some flavor of Linux.
>> 4. Use the libraries from 5.0.5 and Linux-ABI to run the non-Linux
>> applications you need on Linux. You will need to ensure that the
>> libraries remain on the licensed system. This may simply be a matter of
>> putting the old disk into the new system as a secondary disk.
>> 5. Congratulate youself on saving $$$s!
>>
>> If you can get the legal advice for free or you feel confident to read
>> and understand your license agrement for yourself, then all you have to
>> do is to buy new hardware. I am not a lawyer, and I have not seen your
>> license agreement so I can't tell you if the above is allowed by your
>> license agreement.
>
>Joe,
>
>This really isnt the place for this. I think most people are fed up with
>the SCO fiasco, but some people/customers still use SCO software and
>not matter the outcome of the lawsuit, these people wont be able to move
>way from it anytime soon. I consider myself a linux advocate/geek, but my
>day job requires me to support paying customers some of which use SCO
>products. Posting such rants to this newsgroup will do little to help the
>linux bandwagaon and open source cause.
What makes you think this is a rant? It's a practical suggestion. If you
have issues with the technical merits of what I posted, fire away.
Stuart J. Browne
"ryan rothert" <ry...@rothert.com> wrote in message
news:pan.2004.02.24....@rothert.com...
I remember a thread a while back with people using 507 on P4 series, and
were having issues with clock throttling. THis was fixed with MP1.
505 & 506 has no abilities whats-so-ever with regards to this, or other
functions of the P4 series chips.
From a post Bela did, I beleive 505 will work, but not to the best of the
CPU's capabilities, and not able to use the built-in protections the CPU
has.
If you insist on staying on OSR505, then I'd suggest a pre-P4 series of
processor.
bkx
Brian K. White
You need at least 5.0.6 WITH rs506a in order to be able to run on any
p4 without risking torching your cpu.
It'll run, it just may or may not keep running. Also remember to
disable hyperthreading in the bios even for current 5.0.7
You can safely use whatever is the fastest p3 you can find with your
current 5.0.5. including xeon as long as it's a p3-xeon and including over
1ghz.
Maybe you can find an old P3 desktop and transfer the special hardware
(multi-port serial, scsi/raid, tapes etc... which will tide you over,
Assuming you know what specific hardware is going bad and can avoid
bringing that over.
The hardware is the immediate concern and you don't want to upgrade
the os on failing hardware, hope it makes it through that, then sit
there and hope it continues to live while they recover from buying the
OS before they can buy new hardware. You need to get on better
hardware 1st, but you can't get on current hardware without upgrading
the OS. So you better find a good old box, or a cheap new box and move
on to that temporarily, and try to offset the overhead by not paying
much for the temp box. (IE: grab an old desktop and use as much of the
old server as possible in the form of nic,serial,scsi etc...) Probably
what's mostly going bad on the old box are the hard drives and the
power supply and possibly the motherboard due to drying out
capacitors. probably the nic/serial/scsi cards are all fine. I've done
this a few times and it's worked out well. moving those pci cards also
made it easy to get the kernel to run on the new temp box since the
drivers are all already in and generally all you need to do is re-run
netconfig to tell the nic driver what irq/bus/function to find the nic
at.
if the hd's are failing and new hd's would run on the old scsi card
(even if grossly underspeed) Then that is a safe investment. Get new drives
that you will use in the (final) new server, use them in the temp box
and don't worry that it's a ultra320 drive running at 20mhz. If the
new server will have raid and the old one doesn't, no problem, just
get one of whatever will be in the raid array. You will wipe it during
install anyways. (unless the new machine will have 80-pin sca2 hot-swap
connectors and the old one doesn't and you don't have a drive bay to use in
the temp box...)
--
Brian K. White -- br...@aljex.com -- http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx Linux SCO Prosper/FACTS AutoCAD #callahans Satriani
Bill Vermillion
Stuart J. Browne <stu...@promed.com.au> wrote:
>"ryan rothert" <ry...@rothert.com> wrote in message
>news:pan.2004.02.24....@rothert.com...
>> On Mon, 23 Feb 2004 23:29:30 +0000, Jeff Davis wrote:
>>
>> > I am looking to upgrade our current Pentium II 300 Mhz. server. I need
>> > to be able to do this in a couple of stages as I can't afford to
>upgrade
>> > the server and the OS at the same time. We are currently running SCO
>> > 5.0.5 and I was looking at the HP ML350 which has a P4 Xeon running at
>> > 2.2 Ghz. Will 5.0.5 run on this computer or should I look at getting
>> > something a bit older like a Pentium III 700? What kind of troubles
>> > would I run into trying to install an older OS on such a new model
>> > computer? I am almost thinking to get the upgraded OS first and then
>> > upgrade the server later, but I need to make a move soon as my current
>> > hardware is aging. Any and all suggestions would be appreciated.
>> I just did the same thing for a customer of mine. I had to upgrade
>> an old Pentium II 5.0.5 system because the hardware was dying. I talked
>> to SCO pre-sales support and they said I needed to go with 5.0.7 (or
>> something newer than 5.0.5) for the P4 Xeon support. So we purchased the
>> OS upgrade and an IBM x225 series "SCO approved" server. Once we had
>the
>> right OS, the install was flawless. I highly recommend the IBM hardware.
>
>I remember a thread a while back with people using 507 on P4 series, and
>were having issues with clock throttling. THis was fixed with MP1.
>505 & 506 has no abilities whats-so-ever with regards to this, or other
>functions of the P4 series chips.
>From a post Bela did, I beleive 505 will work, but not to the
>best of the CPU's capabilities, and not able to use the built-in
>protections the CPU has.
Actually as I recall there are some loops in the 505 which will
cause the P4 to heat up. The built in P4 protection mechanism will
throttle the chip down to lower and lower clock speeds until it
finds a speed it will run at with no problems.
Jeffl once commented on that on a system with each reboot the the
system showed a slower and slower clock speed.
The other day my XP was getting funky, and I rebooted, and since I
have an HTT chip and XP supports HTT it showed I had two
1200MHz processors. I booted and restarted and it came us as
two 2400MHz - as it should.
As I started this I just realized this, and yesterday I noticed
that one of the two case fans had been blocked so all that fits
togther.
But the P4 protection is in the chip - it's just that [as I recall]
the way 5.0.5 works it will cause the chip to heat on install and
cause it to throttle down.
And if I'm wrong on these I do need a correction so I can
reconfigure my wetware :-)
Bill
Bela Lubkin
> I remember a thread a while back with people using 507 on P4 series, and
> were having issues with clock throttling. THis was fixed with MP1.
>
> 505 & 506 has no abilities whats-so-ever with regards to this, or other
> functions of the P4 series chips.
Your timeline is a little off: P4 thermal support was added in rs506a.
OSR506 without rs506a, and earlier releases, are in danger of
overheating a CPU, causing it to slow down drastically or in extreme
cases, damage the CPU.
> From a post Bela did, I beleive 505 will work, but not to the best of the
> CPU's capabilities, and not able to use the built-in protections the CPU
> has.
That was my belief back then. I've recently heard of cases where actual
damage may have occurred. Apparently the P4's self-protective circuitry
doesn't react very quickly, so if something is spinning very hard and
the machine's thermal design is poor, the CPU or motherboard can
actually be damaged.
> If you insist on staying on OSR505, then I'd suggest a pre-P4 series of
> processor.
I agree.
If you absolutely must use OSR505 on a P4, you might want to run the CPU
at a lower clock speed than it's rated for. This gives it a much wider
margin for reacting to sudden heat surges.
>Bela<
Bela Lubkin
> You need at least 5.0.6 WITH rs506a in order to be able to run on any
> p4 without risking torching your cpu.
>
> It'll run, it just may or may not keep running. Also remember to
> disable hyperthreading in the bios even for current 5.0.7
OSR507 with Update Pack 1 supports hyperthreading. Have you had trouble
with it?
>Bela<
ryan rothert
<foot in mouth> After some sleep, your post isnt a rant, my apologies Joe.
I skimmed through it quickly and thought was another SCO
sucks(die.die.die)/Linux rocks post.
Ryan
Brian K. White
I don't have UP1 and as far as I know, can't install it.
MP1 I have. Does that apply?
Jean-Pierre Radley
| Bela Lubkin wrote:
| > Brian K. White wrote:
| >
| >> You need at least 5.0.6 WITH rs506a in order to be able to run on any
| >> p4 without risking torching your cpu.
| >>
| >> It'll run, it just may or may not keep running. Also remember to
| >> disable hyperthreading in the bios even for current 5.0.7
| >
| > OSR507 with Update Pack 1 supports hyperthreading. Have you had
| > trouble with it?
| >
| >> Bela<
|
| I don't have UP1 and as far as I know, can't install it.
| MP1 I have. Does that apply?
The Maintenance packs are free; the Update packs require an Update
License.
--
JP
Bela Lubkin
> Bela Lubkin wrote:
> > Brian K. White wrote:
> >
> >> You need at least 5.0.6 WITH rs506a in order to be able to run on any
> >> p4 without risking torching your cpu.
> >>
> >> It'll run, it just may or may not keep running. Also remember to
> >> disable hyperthreading in the bios even for current 5.0.7
> >
> > OSR507 with Update Pack 1 supports hyperthreading. Have you had
> > trouble with it?
> >
> >> Bela<
>
> I don't have UP1 and as far as I know, can't install it.
> MP1 I have. Does that apply?
No. HT support is considered an added value and is found only in the
chargable Update Pack series.
>Bela<
Stuart J. Browne
"Bela Lubkin" <be...@sco.com> wrote in message
news:20040224170...@sco.com...
*blink* wow.. didn't realise that.. I thought it was part of the MP..
that kinda sux..
bkx
Brian K. White
That was my understanding too. I do not expect to be able to sell any
customers on any such license. They upgrade hardware & software every
4 or 5 years, add user seats as necessary, and pay us hours for
routine maintenance. Nothing I can think of to explain why they want
or need the UP's will wash with most of them, unless someone is having
a specific problem that an UP is known to fix and is known to be the
only way to fix. I don't beleive the UP's have any such items so far,
and so I think they are stupid. As you might guess, I never bought the
swim idea either and didn't that turn out to be mostly just a big
waste of suckers money for most subscribers?
Just put the new features in the next version of the OS and put
necessary bug fixes in free patches and leave the marketing
fast-talking and slight-of-hand to RedHat and Windows.
Closest thing to a legitimate need I could see in this case might be
machines such as my laptop which has a HT cpu, and no way to disable
HT in the bios.
So if I really needed to run OSR5 on this laptop, and 5.0.8 was not
out yet, that would be a reasonable case for buying the UP. Of course
nothing like that can apply to any already installed system. The
system hardware was already chosen specifically to be compatible with
the OS as it already existed. Anything that develops as a problem
starting from that starting point that is neither faulty hardware or
misconfiguration is most likely an honest bug that needs fixing, not a
new feature that is optional and should be paid for if you want it.
Bela Lubkin
> Closest thing to a legitimate need I could see in this case might be
> machines such as my laptop which has a HT cpu, and no way to disable
> HT in the bios.
> So if I really needed to run OSR5 on this laptop, and 5.0.8 was not
> out yet, that would be a reasonable case for buying the UP. Of course
> nothing like that can apply to any already installed system. The
> system hardware was already chosen specifically to be compatible with
> the OS as it already existed. Anything that develops as a problem
> starting from that starting point that is neither faulty hardware or
> misconfiguration is most likely an honest bug that needs fixing, not a
> new feature that is optional and should be paid for if you want it.
As far as I know, having HT enabled doesn't cause any problems with a
single-processor installation of OpenServer. It simply won't see (won't
even look for) the second (virtual) CPU.
>Bela<
Jean-Pierre Radley
The Update Packs incrementally bring your release from 5.0.7 to the next
one, Legend (which may or may not be designated 5.0.8). I suspect that
the price you pay now for the Upgrade License is probably less than the
trade-in to the next level will be. Just for the record, here's what's
been issued so far:
Update Pack 1:
+ support for IDE hard disks larger than 137GB
+ extended shells
+ Info-ZIP
+ Hyper-Threading Technology
+ updated online documentation and manual pages
Update Pack 2:
+ USB printer support
+ CUPS printer subsystem
+ GIMP-print support
+ ESP Ghostscript release 7.07.1
+ H2N Bind8 DNS parser
+ serial ATA support
+ PostgreSQL
+ updated IPC parameters
--
JP
Joe Dunning
>Brian K. White typed (on Tue, Feb 24, 2004 at 08:32:16PM -0800):
>|
>| That was my understanding too. I do not expect to be able to sell any
>| customers on any such license.
I can see why -- see my comments below.
>
> Update Pack 2:
>
> + USB printer support
Does not work properly.
> + CUPS printer subsystem
GPL-licensed, Free Software, why pay?
> + GIMP-print support
GPL-licensed, Free Software, why pay?
> + ESP Ghostscript release 7.07.1
GPL-licensed, Free Software, why pay?
> + H2N Bind8 DNS parser
Freely available. It's only a perl script.
> + serial ATA support
> + PostgreSQL
BSD-licensed, open source, why pay?
> + updated IPC parameters
So, of the updates, more than half are free/open source software and of
the rest one out of 3 does not work properly. Not too impressive.
Jean-Pierre Radley
You can install all the free software you want on any SCO OS. If it
does not function to your heart's content, you know where to get help
(not SCO, for sure).
If, OTOH, SCO has shipped something as part of one of its OSes, then you
have recourse to SCO when something's awry.
--
JP
Brian K. White
It's extremely impressive
If they properly and fully integrated all that stuff it's worth a lot.
The choice is:
1) spend lots a lots (and lots and lots.....) of time getting all that stuff
integrated (not just compiled or working, but really integrated so it works
without grief with everything else
2) live without
3) buy the finished working system and just use it
No particular one of those options is always the right one.
In most cases, "2" is actually fine, if they already aren't using something,
then generally, they don't need it.
In some cases, if you just need a relatively uncomplicated single discrete
component like bzip2 or something, then it's not impractical to roll your
own. Especially if you know you will need it lots of times and only have to
build it once.
So I didn't mean to imply that "3" is the only choice that is even remotely
sane, just that it is a valid choice that certainly compares well with the
others.
Brian K. White
Recall my post to the list a couple months ago. A single cpu box.
base install worked fine repeatedly, installing mp1 failed in exactly the
same place and the same way, repeatedly.
started grasping at straws and looking for unlikey possible problems,
discovered HT enabled in the bios, disabled it. install went perfect
immediately after.
Someone else who had the same problem some months before me diagnosed it a
bit further than me and determined that part of the mp1 install uncompresses
a file, this particular file would always uncompress corrupted even though
many other files uncompressed fine.
Bela Lubkin
> Bela Lubkin wrote:
> > Brian K. White wrote:
> >
> >> Closest thing to a legitimate need I could see in this case might be
> >> machines such as my laptop which has a HT cpu, and no way to disable
> >> HT in the bios.
> >> So if I really needed to run OSR5 on this laptop, and 5.0.8 was not
> >> out yet, that would be a reasonable case for buying the UP. Of course
> >> nothing like that can apply to any already installed system. The
> >> system hardware was already chosen specifically to be compatible with
> >> the OS as it already existed. Anything that develops as a problem
> >> starting from that starting point that is neither faulty hardware or
> >> misconfiguration is most likely an honest bug that needs fixing, not
> >> a new feature that is optional and should be paid for if you want it.
> >
> > As far as I know, having HT enabled doesn't cause any problems with a
> > single-processor installation of OpenServer. It simply won't see
> > (won't even look for) the second (virtual) CPU.
>
> Recall my post to the list a couple months ago. A single cpu box.
> base install worked fine repeatedly, installing mp1 failed in exactly the
> same place and the same way, repeatedly.
> started grasping at straws and looking for unlikey possible problems,
> discovered HT enabled in the bios, disabled it. install went perfect
> immediately after.
>
> Someone else who had the same problem some months before me diagnosed it a
> bit further than me and determined that part of the mp1 install uncompresses
> a file, this particular file would always uncompress corrupted even though
> many other files uncompressed fine.
Ok, I remember that now. Turning off HT fixed the problem in that case.
That doesn't prove that the problem was caused by HT itself, or by the
non-HT-aware OS's reaction to it. Other possibilities include (at
least): other settings changed by the BIOS "behind the scenes" under
control of the HT enable/disable switch; a latent hardware bug which
was exposed by slight timing differences; a latent operating system bug
exposed by timing differences.
Anyway, I see that my response was based on a misreading of what you
wrote. You wrote "Closest thing to a legitimate need I could see in
this case might be machines such as my laptop which has a HT cpu, and no
way to disable HT in the bios." I read that as a blanket recommendation
that OSR5 _needs_ HT to be disabled unless you've got the update that
adds support for it. I should have imagined the implied final clause
", and HT is causing problems on the particular machine"...
>Bela<
Tom Melvin
> On 25 Feb 2004 11:55:30 -0500, Jean-Pierre Radley <j...@jpr.com> wrote:
>
> >Brian K. White typed (on Tue, Feb 24, 2004 at 08:32:16PM -0800):
> >|
> >| That was my understanding too. I do not expect to be able to sell any
> >| customers on any such license.
>
> I can see why -- see my comments below.
>
> >
> > Update Pack 2:
> >
> > + USB printer support
>
> Does not work properly.
Just so people don't get the wrong impression - been using USB printing
here for a couple of months now and it is working without a single
problem.
Tom
--
========================================================================
Tom Melvin t...@tkrh.demon.co.uk http://www.tkrh.demon.co.uk
Veterinary Solutions Ltd
========================================================================
Brian K. White
Well, the laptop is not the machine that I had the HT problem with a few
months ago.
I have tried to install osr5 on the laptop also, and had problems, but
didn't get far enough to determine if there was going to be a problem with
HT. I know that lots of machines run with HT enabled and don't have a
problem. I was saying that if you don't want to rely on luck you should
disable it in the bios or don't use a cpu that has it (you can buy P4's that
don't even have HT). And since I never think it's sensible to rely on luck,
this translates into a simple "you must to do this" type of statement. The
implied final clause would be "if you don't have time to be a beta tester"
I agree that the problem is probably the hardware not doing a perfect job of
backwards compatibility (not behaving perfectly like a plain non-ht cpu
system) rather than the os tripping on something it doesn't know about. (not
that I'm in a position to comment knowledgeably about either the hardware or
the os down at that level)
Simply buying good name, not cheap, hardware is not an effective way to
avoid this either, since the server I had the problem with was a good intel
shg2-family.
FyRE
wrote:
[Hyperthreading]
>problem. I was saying that if you don't want to rely on luck you should
>disable it in the bios or don't use a cpu that has it (you can buy P4's that
>don't even have HT). And since I never think it's sensible to rely on luck,
>this translates into a simple "you must to do this" type of statement. The
>implied final clause would be "if you don't have time to be a beta tester"
Of course, you could just run an operating system that can cope with
modern processors, and is still being actively developed. I can't
believe anyone would be idiotic enough to run an ancient UNIX from
SCOG on a modern laptop. It's like stripping the engine out of a
Ferrari, to replace it with one from a lawnmower...
Linux runs great with Hyperthreading enabled, BTW, and 64 bit CPUs ;-)
You can't fight evolution forever, Brain...
--
FyRE < "War: The way Americans learn geography" >
Brian K. White
> On Thu, 26 Feb 2004 11:48:57 -0500, "Brian K. White" <br...@aljex.com>
> wrote:
>
> [Hyperthreading]
>
>> problem. I was saying that if you don't want to rely on luck you
>> should disable it in the bios or don't use a cpu that has it (you
>> can buy P4's that don't even have HT). And since I never think it's
>> sensible to rely on luck, this translates into a simple "you must to
>> do this" type of statement. The implied final clause would be "if
>> you don't have time to be a beta tester"
>
> Of course, you could just run an operating system that can cope with
> modern processors, and is still being actively developed. I can't
> believe anyone would be idiotic enough to run an ancient UNIX from
> SCOG on a modern laptop. It's like stripping the engine out of a
> Ferrari, to replace it with one from a lawnmower...
Actually, it's like deciding to use an engine designed, developed, and
perfected for 20 years by Lockheed Martin instead of using something that a
rotating hodge-podge of college students have tinkered with in their garage
for the last 10 years.
On top of which, linux started from scratch 10 years ago, while 20 years ago
sco bought an already good solid product and have just been perfecting it
even more since then.
> Linux runs great with Hyperthreading enabled, BTW, and 64 bit CPUs ;-)
> You can't fight evolution forever, Brain...
Who wants to? The point is not all change is good.
change != positive evolution
positive evolution = positive evolution
I say, when drivers and services and features and applications and utilities
change their behaviour from day to day, and when drivers and services and
features and applications and utilities fall into disrepair and fall
completely out of sync with the rest of the system such that they no longer
work and are no longer supported, just because none of the "thousands of
developers" happens to feel like working on that driver that doesn't work
anymore because the kernel changed out from under it... I don't call that
positive evolution. I call that rapid mutation. The object that is "linux"
is indeed pretty powerful at any given moment, and is getting more and more
powerfull all the time. But it's of very little use to me because it's
changing too much and too fast. It's sleek, fast & pretty, but not actually
useful except in a narrow range of applications that just happens to be in
the middle of the sweet spot of most developers interest. ie: core web
server services & related services (web,ftp,sql,php,...) and
desktop/multimedia stuff. And even then, the sweet spot of other developers
interest can shift out from under you at any time. Got a few hundred
thousand man-hours invested into a python app? Oh well, better hope ruby
doesn't catch on as completely as some would wish... Got a bunch of sites
already installed with some weird special item of hardware that needs the
ide-scsi driver? Oh well, better just remain happy with old bug-ridden and
security holed kernels, too bad for you.
Linux is a rat-race that businesses that just need a black box that sits in
the corner and works without needing special care by a live-in whiz kid who
stays on top of the scene by the hour do not need any more than they need 3
windows servers.
When SCO makes a change, it is either squashing a bug, which generally hurts
no one, or adding a new feature or expanding somethings abilities in a way
that does not cause any backwards incompatibility. When they add any new
funtionality, it gets tested exhaustively with all parts of the system and
under god only knows how many different contexts before it ships. Very few
actual bugs make it out and those that do are usually found and patch
relatively quickly and it's usually very few rounds of patching and updating
after a new version ships. osr 5.0.7 came out, and then a little while later
the 507a udate came out and that one update pretty much cleaned up all the
loose ends. There have been a couple specific further patches and then
nothing. That is very close to shipping a perfect system in the first place.
Linux is just riddled with constant breakage and fixage and fixage the
causes other breakage. And because SCO avoids wholesale gratuitous changes,
almost every bug that ever got fixed stayed fixed and is still fixed today.
So for example, their ksh is based on a really old "real korn", it's also
extremely robust. by now it's been used and abused by so many people in so
many different ways that you are very unlikely to come up with a situation
that hasn't been encountered and fixed a long time ago. It hasn't been
stagnating, it's been getting harder and harder and now it's a diamond. Such
is the case for every other basic system utility, and such is the case for
the system as a whole.
Linux is a perpetual prototype. Impressive surely. And I think it's not only
cool, but _necessary_ that something like linux exists that pushes
development ahead. I'd hate to try and get any work done on the original
"time sharing system" today. But that prototype is not the proper tool to do
day to day business on.
Scott Burns
>When SCO makes a change, it is either squashing a bug, which generally hurts
>no one, or adding a new feature or expanding somethings abilities in a way
>that does not cause any backwards incompatibility.
>
Not 100% true. We still have one site on 5.0.2 and a few on 5.0.5 - we
can't upgrade our development server to 5.0.7 without having to also
upgrade our clients to at least 5.0.6 with patches, or 5.0.7, because of
the changes to the shared libraries. Of course, this is the only
example I know off...
>Linux is a perpetual prototype. Impressive surely. And I think it's not only
>cool, but _necessary_ that something like linux exists that pushes
>development ahead. I'd hate to try and get any work done on the original
>"time sharing system" today. But that prototype is not the proper tool to do
>day to day business on.
>
>
>
My experiences have shown people do not tend to run either gnome or kde
on their SCO machines. They don't do graphics, so no gimp. It is rare
to see a scanner, so no sane. I've seen ppp in a few places, but no
isdn directly to a SCO box. Printing is usually primitive, perhaps
lines or boxes, but no real requirement for the full foomatic/gimp-print
etc. I've seen spider, and xeyes, but no tux racer, chromium, or even
minesweeper (gasp!). I've never seen an office application except when
watching a demo of tarentella. Postgresql is recently included but no
MySQL (could be wrong here?). Perl can be hit and miss, and compilers
are not installed on most systems. Most still run telnet and/or rsh,
without ssh being installed.
When you strip off all the fluff to bring your typical Linux system into
line with the typical SCO system, I beleive the rate of change is really
not all that fast, especially when you consider how often these systems
get updates applied, as opposed to updates available.
The last straw that made us seriously start considering Linux over SCO
came a couple of years ago. A tape drive died and we had to replace.
With the amount of data, rate of backup, etc, a CD burner was the right
choice. For the price of the tape drive alone we could buy a burner and
a 10-20 year supply of blank CDs. SCO, however, only supported SCSI CD
burners, and we could not find any of them for sale. With serious time
constraints, we had to go with the tape drive. While this failing has
been harped on before, and fixed in 5.0.7, we lost faith in this slow
rate of change. While your circumstances may mean this slow rate is
fantastic, not everyone is in that boat.
--
Scott Burns
Mirrabooka Systems
Tel +61 7 3857 7899
Fax +61 7 3857 1368
FyRE
wrote:
>FyRE wrote:
>> On Thu, 26 Feb 2004 11:48:57 -0500, "Brian K. White" <br...@aljex.com>
>> wrote:
>>
>> [Hyperthreading]
>>
>>> problem. I was saying that if you don't want to rely on luck you
>>> should disable it in the bios or don't use a cpu that has it (you
>>> can buy P4's that don't even have HT). And since I never think it's
>>> sensible to rely on luck, this translates into a simple "you must to
>>> do this" type of statement. The implied final clause would be "if
>>> you don't have time to be a beta tester"
>>
>> Of course, you could just run an operating system that can cope with
>> modern processors, and is still being actively developed. I can't
>> believe anyone would be idiotic enough to run an ancient UNIX from
>> SCOG on a modern laptop. It's like stripping the engine out of a
>> Ferrari, to replace it with one from a lawnmower...
>
>Actually, it's like deciding to use an engine designed, developed, and
>perfected for 20 years by Lockheed Martin instead of using something that a
>rotating hodge-podge of college students have tinkered with in their garage
>for the last 10 years.
>On top of which, linux started from scratch 10 years ago, while 20 years ago
>sco bought an already good solid product and have just been perfecting it
>even more since then.
How come it's so far behind Linux then, both in terms of performance
AND (as demonstrated in this very thread) hardware support and SCO
keep "borrowing" software that this "hodge-podge of college students"
have developed, to prop up their aged product line then, eh? ;-)
This is so obviously wrongheaded thinking, I'm surprised you have the
gall to say it in any newsgroup. There's nothing forcing you to run
kernel 2.6.2, GCC 3.3.2 and the latest glibc on Linux. And since I
have it running a 2.4.22 kernel on a 9 year old P90 with 2 ancient
ethernet cards, a fairly new ADSL PCI card, ancient mfm hard drive and
graphic card as a firewall/router/blah blah, I'd say it's very able to
run on old hardware. I just installed that same kernel (2.4.22) on
another new rack server today, with dual Xeon's (with HT ;-), 2GB RAM
and a trio of U320 SCSI drives running RAID 5 using a PCI RAID card.
The drivers were all right there during the install (since they're all
running RedHat using a network install with kickstart config I didn't
have to do anything other than put a floppy disk in and boot them up -
well, after configuring the RAIDs of course), and as you'll
appreciate, the thing runs like a goddamned train - alongside the
other 5 identical units installed this week.
I've personally seen Linux running on anything from a Sharp Zaurus
organiser, through 486 based robots, phones, up to 16 way servers (I
believe it can go to 64 CPUs now) and clusters. That doesn't sound
like a "narrow band" of hardware or applications to me, Brain...
>Linux is a rat-race that businesses that just need a black box that sits in
>the corner and works without needing special care by a live-in whiz kid who
>stays on top of the scene by the hour do not need any more than they need 3
>windows servers.
>
>When SCO makes a change, it is either squashing a bug, which generally hurts
>no one, or adding a new feature or expanding somethings abilities in a way
>that does not cause any backwards incompatibility.
Care to name some hardware that's no longer supported by Linux (and is
actually relevent - ie, not 20 years old)? No? Thought not...
>When they add any new
>funtionality, it gets tested exhaustively with all parts of the system and
>under god only knows how many different contexts before it ships. Very few
>actual bugs make it out and those that do are usually found and patch
>relatively quickly and it's usually very few rounds of patching and updating
>after a new version ships. osr 5.0.7 came out, and then a little while later
>the 507a udate came out and that one update pretty much cleaned up all the
>loose ends. There have been a couple specific further patches and then
>nothing. That is very close to shipping a perfect system in the first place.
>Linux is just riddled with constant breakage and fixage and fixage the
>causes other breakage.
Yet again, another baseless statement. I honestly don't know how you
expect anyone to take you seriously. Did you know, BTW that Linux is
the preferred platform for Oracle now? In fact, Oracle themselves use
it in-house. I wouldn't expect that if it were riddled with problems.
Of course, again you're free to provide some evidence, Brain, but I
won't hold my breath...
>And because SCO avoids wholesale gratuitous changes,
>almost every bug that ever got fixed stayed fixed and is still fixed today.
>So for example, their ksh is based on a really old "real korn", it's also
>extremely robust. by now it's been used and abused by so many people in so
>many different ways that you are very unlikely to come up with a situation
>that hasn't been encountered and fixed a long time ago. It hasn't been
>stagnating, it's been getting harder and harder and now it's a diamond. Such
>is the case for every other basic system utility, and such is the case for
>the system as a whole.
Wow, a real selling point. SCO have "ksh"! I think some other OS' also
have it (Linux has it as an option, though not many people would
actually bother using it since we have the more powerful bash as the
default).
>Linux is a perpetual prototype. Impressive surely. And I think it's not only
>cool, but _necessary_ that something like linux exists that pushes
>development ahead. I'd hate to try and get any work done on the original
>"time sharing system" today. But that prototype is not the proper tool to do
>day to day business on.
Millions would argue the contrary. Far more servers are running it in
far more companies than any other UNIX variant today, and the gap is
widening very quickly. It's not a prototype, unless you wish to run
the latest development code. I personally administer a large number of
Linux servers, and do you know how many problems I've had that were
caused by the operating system in the past 12 months? Zero. Problems
with unsupported hardware? Zero. Performance issues? Zero. If only all
prototypes were as stable, eh? ;-)
Luckily people such as yourself, Brain, utterly blinkered and unable
to move with the times are a dwindling minority.
Brian K. White
> Brian K. White wrote:
>
>> When SCO makes a change, it is either squashing a bug, which
>> generally hurts no one, or adding a new feature or expanding
>> somethings abilities in a way that does not cause any backwards
>> incompatibility.
>>
> Not 100% true. We still have one site on 5.0.2 and a few on 5.0.5 -
> we can't upgrade our development server to 5.0.7 without having to
> also upgrade our clients to at least 5.0.6 with patches, or 5.0.7,
> because of the changes to the shared libraries. Of course, this is
> the only example I know off...
The customers oldest xenix bins still run on the latest osr5. And I'd be
pretty surprised if there in fact is an incompatibility that keeps you from
upgrading. Just because the default output of the compiler produces dynamic
binaries linked against the default current libraries that won't run out of
the box on older systems does not stop you from servicing older boxes at
least a couple different ways while still keeping your own box as up to date
as you like:
Two basic attacks,
1) get new libs onto old box so binaries can use them.
a) build static binaries. or,
b) ship your app with copies of any new libs that your app needs,
installed in your apps home dir, not in /usr/lib, and eiher build the app
with linker options so that the binaries look for the libs by their full
exact path, or run the app with a start script that sets LD_LIBRARY_PATH.
Depending on the exact libraries in question, you may be able to do this
without breaking any IP laws, since a lot of the latest libraries are freely
available for download in the form of oss646b and mp1 and rs 507a. If you
wanted to be really paranoid you could just ship a script that downloaded a
patch and extracted the libs you need instead of the libs themselves or the
patch itself. It's not as hard as you might imagine, I have a script on my
web page that extracts a few libraries from rs506a so that programs could
run on older boxes. (since then, oss646b came out, which obsoletes my
script). I only tested my script on 5.0.4 & 5.0.5 and it has case statements
so that I already know it won't work as-is on anything else, but it's an
example to go by and could be edited a little for 5.0.2 or earlier.
"1a" might fix it right there, but I can imagine situations this wouldn't
fix, so,
if there is something so different about the new library calls that they
fail to interact with the older kernel properly, then just,
2) build using old libs
a) copy the older versions of the libraries your app needs from your
previous system to your current system. (in a seperate directory if any of
the library names collide with current libs. actually it's probably saner to
just do that anyways) and adjust your makefiles a little to specifically
link against these libraries instead of the default ones and build static if
you can't get the linker command line arguments right to cause the final
binary to look in the normal path at run-time which is not the same as the
non-standard path you would need to use at build-time.
b) set up a copy of the build environment in a chroot, then the path to
the old libs within the chroot at build-time is the same as the real path to
the same libs on the customers box.
But those are just off the cuff brute-force options that should work, but I
bet there is actually a much easier & saner "right way" to do this that has
been specifically provided just for this purpose, and it merely requires you
to know how to use it.
Create certain directories and put certain files in them from your old box,
set certain environment variables in your makefile... like that.
The devsys already allows for several different "environments" and build
targets and I bet building for older systems is at least allowed for even if
not actually present and set up out of the box.
> When you strip off all the fluff to bring your typical Linux system
> into line with the typical SCO system, I beleive the rate of change
> is really not all that fast, especially when you consider how often
> these systems get updates applied, as opposed to updates available.
That is true and a pretty big point, except the kernel does change a lot,
this necessitates library changes, this means any application binaries get
tied to a short time-span of systems that eventually won't even run on
current hardware etc etc
That is not to say that this problem is necessarily going to continue
though. Only a few years ago, software and sophisticated development tools
to create it simply didn't exist yet. You need something, you pay some
programmers to make it for you. The result costs a lot and you need to get a
lot of years of service out of it in order to make back the invesment. By
now though, a sort of critical mass has been reached, or if not quite
reached yet, sure feels like it must be just around the corner. In an awful
lot of cases, some form of free software exists by now to do the job.
sometimes even a large selection. Maybe not perfectly, or exactly the way
thats best for your particular business, but there is something there so
that the option to be cheap and/or to be self-sufficient exists if you need
it. And where software doesn't yet exist, a plethora of free development
tools and environments exists to create software and the average
professional or business owner is more likely to have enough computer
literacy to actually cobble together something to get his job done on his
own. I'm sure we've all seen clients that are not otherwise "computer
people" doing pretty heavy stuff in excel by virtue of it's ease of use and
maleability. Some free software is starting to get that good.
Once the core important applications are open source, or self-written in an
open source language, then the above problem of irreplaceable old binaries
goes away too.
It'll still be a lot more overhead having to keep updating things instead of
having them just keep working. And as a vendor/consultant having to deal
with almost every one of your customers systems having different quirks from
every other. And every new install, you are not actually 100% sure that
there won't be some kind of problem sooner or later so you are forced to
accept a higher level of risk. That all translates directly into higher cost
of ownership for the end user.
In many ways, this progress is just plain a downgrade in service to the end
user, even if many new end users aren't aware of how trouble-free their
systems could and should be. Life on the edge is not for everyone and not
for every type of work. Heck it's not for most types of work. Do you want
airplanes and radar towers to run software that's only been out in the field
a few weeks or months? nuclear reactors? hospitals and other facilities that
deal in biological agents? ok forget the dramatic life threatening stuff,
how about banks and the IRS (pardon the U.S.-ism) where a little bit of data
handling means a persons whole life in other ways? gee pretty much anything
thats worth doing with a computer besides video games is important enough
that being cavalier about it is down right unethical.
> The last straw that made us seriously start considering Linux over SCO
> came a couple of years ago. A tape drive died and we had to replace.
> With the amount of data, rate of backup, etc, a CD burner was the
> right choice. For the price of the tape drive alone we could buy a
> burner and a 10-20 year supply of blank CDs. SCO, however, only
> supported SCSI CD burners, and we could not find any of them for
> sale. With serious time constraints, we had to go with the tape
> drive. While this failing has been harped on before, and fixed in
> 5.0.7, we lost faith in this slow rate of change. While your
> circumstances may mean this slow rate is fantastic, not everyone is
> in that boat.
Fair enough though. Sounds like you made a considered decision based on
practical issues. Can't argue with that. Well, there is still an argument
there it's just a much lighter-hearted one.
Brian K. White
> Millions would argue the contrary. Far more servers are running it in
> far more companies than any other UNIX variant today, and the gap is
> widening very quickly. It's not a prototype, unless you wish to run
> the latest development code.
Relative. It's true a distribution could be put out that was careful about
what they put their "stable" stamp on, but with so many distibutions out
there, and with so many changing their behaviour from time to time, it's
difficult to point at any and say, If you stick to stable releases of
x-distribution, it will work as advertized. Caldera used to advertize that
as their specific goal, but well... I hear a few people (whos opinions I
respect) mentioning suse as being well engineered these days. *shrug* it
probably is. What do I have to go on that it will still be so next year?
> I personally administer a large number of
> Linux servers, and do you know how many problems I've had that were
> caused by the operating system in the past 12 months? Zero. Problems
> with unsupported hardware? Zero. Performance issues? Zero. If only all
> prototypes were as stable, eh? ;-)
Popularity is not a valid yardstick. Your successful personal experience and
that of anyone else you know whos opions you respect, those are valid.
Popularity? Millions of people eat at McDonalds and run Windows and sit on
particle board furniture from WalMart.
And millions of them didn't have a problem all last year.
FyRE
wrote:
[Brian comes up with some nasty hacks to make old SCOG systems run
with newer binaries. Pretty bad advice in my view, randomly
overwriting libraries on your commercial system with later
versions...]
>> When you strip off all the fluff to bring your typical Linux system
>> into line with the typical SCO system, I beleive the rate of change
>> is really not all that fast, especially when you consider how often
>> these systems get updates applied, as opposed to updates available.
>
>That is true and a pretty big point, except the kernel does change a lot,
>this necessitates library changes, this means any application binaries get
>tied to a short time-span of systems that eventually won't even run on
>current hardware etc etc
Again you spout gibberish, Brian. I challenged you to offer some proof
of these ridiculous allegations in a previous article, and you ran
away. You don't need to change the libraries just because you've built
a new kernel, Brian. Applications don't actually need to know which
kernel is in use. Why? Because they're "applications"; they are not
kernel modules.
>Once the core important applications are open source, or self-written in an
>open source language, then the above problem of irreplaceable old binaries
>goes away too.
That happened many years ago for SCO's product line.
>It'll still be a lot more overhead having to keep updating things instead of
>having them just keep working. And as a vendor/consultant having to deal
>with almost every one of your customers systems having different quirks from
>every other. And every new install, you are not actually 100% sure that
>there won't be some kind of problem sooner or later so you are forced to
>accept a higher level of risk. That all translates directly into higher cost
>of ownership for the end user.
Rubbish, rubbish, rubbish. Brian, you're not talking to one of your
dimwitted, technically ignorant customers here, you know. As I've
already stated, you're not chained to an upgrade cycle with Linux. I
know of servers still running 5 year old kernels without problems (in
fact the 2.0.x kernel line is STILL maintained, though it's now 3
generations behind the cutting edge).
If you buy Redhat AS, or ES (or even WS for desktop use), you also buy
support, and a guarantee that it WILL work as advertised with software
X and hardware Y. Same with SuSE/Novell. I'd certainly have more
confidence in those companies than gamlbing on a bunch of greedy
lawyers and other litigious bastards over in Utah who are shortly to
wink out of existance.
>In many ways, this progress is just plain a downgrade in service to the end
>user, even if many new end users aren't aware of how trouble-free their
>systems could and should be. Life on the edge is not for everyone and not
>for every type of work. Heck it's not for most types of work. Do you want
>airplanes and radar towers to run software that's only been out in the field
>a few weeks or months? nuclear reactors?...
More stupidity. Brian, you're proving yourself either ignorant, stupid
or a liar. Which is it? Do you HONESTLY think that the average Linux
using company installs the latest kernel as soon as it's released,
along with any other updates? I can see you're desperate to support
your beloved SCO's abandonware, but your arguments that progress is a
bad thing is laughable. You're looking more and more foolish every
time you try to defend OS/UW's failings.
FyRE
wrote:
[Note: Brian, as I predicted, has completely failed to back up his
earlier lies about Linux and Open Source software. Those were the
parts he chopped out of this thread ;-)]
>FyRE wrote:
>
>> Millions would argue the contrary. Far more servers are running it in
>> far more companies than any other UNIX variant today, and the gap is
>> widening very quickly. It's not a prototype, unless you wish to run
>> the latest development code.
>
>Relative. It's true a distribution could be put out that was careful about
>what they put their "stable" stamp on, but with so many distibutions out
>there, and with so many changing their behaviour from time to time, it's
>difficult to point at any and say, If you stick to stable releases of
>x-distribution, it will work as advertized.
Obviously you've never heard of companies called "RedHat", "SuSE",
(and now) "Sun Microsystems" who offer these exact products. Also some
other little companies including "Oracle" and "IBM" who list Linux as
their preferred platform; that's Linux, Brian, not SCO, BTW.
>Caldera used to advertize that
>as their specific goal, but well... I hear a few people (whos opinions I
>respect) mentioning suse as being well engineered these days. *shrug* it
>probably is. What do I have to go on that it will still be so next year?
As Tony might say "Nobody knows what will happen two minutes from now.
The sun might not rise tomorrow - yes, it probably will, but nobody
here is qualified to state that it definitely will!!!" I can't do the
whole Tony impression, BTW; running around with a tin foil hat on is
not my style...
>> I personally administer a large number of
>> Linux servers, and do you know how many problems I've had that were
>> caused by the operating system in the past 12 months? Zero. Problems
>> with unsupported hardware? Zero. Performance issues? Zero. If only all
>> prototypes were as stable, eh? ;-)
>
>Popularity is not a valid yardstick. Your successful personal experience and
>that of anyone else you know whos opions you respect, those are valid.
>Popularity? Millions of people eat at McDonalds and run Windows and sit on
>particle board furniture from WalMart.
>And millions of them didn't have a problem all last year.
The difference is: Linux has succeeded on technical merit, and it's
obvious price/performance advantages. The others you list have
succeeded by being monopolies, and/or bullying competitors out of
their markets with dubious and in some cases illegal actions.
Face it, SCO were dead long ago. This is why a creep like McBride now
hold the reins; there's no hope of the company ever turning a profit
by selling it's outdated, overpriced and outclassed product line. The
only option for SCOG was litigation. It's a short-term venture now
though; the stock price is already plumeting back down to where it
belongs, the court case has become a farce (some would argue it always
was) and the outright lies from SCOG management are well documented.
I'm a little curious as to why anyone would promoted the platform as a
realistic choice any more. I can only assume you're a "one trick pony"
who is loath to learn anything new, and now stuck with having to trick
his clients into continuing to pay for a dead product to fund your
pension scheme. The evidence against using SCOG products is
overwhelming:- No future, outdated, little hardware support, no
community support, vastly outperformed by the competition. If you are
making ANY sales to new customers, I'd be surprised... and disgusted.
Joe Dunning
>FyRE wrote:
>
>> Millions would argue the contrary. Far more servers are running it in
>> far more companies than any other UNIX variant today, and the gap is
>> widening very quickly. It's not a prototype, unless you wish to run
>> the latest development code.
>
>Relative. It's true a distribution could be put out that was careful about
>what they put their "stable" stamp on,
Where to
begin with this issue? There are so many things wrong with what you
write.
But let's start with stability: Isn't that *exactly* what RedHat's
"Enterprise" distributions are all about? Look at the published support
plans for those products.
>respect) mentioning suse as being well engineered these days. *shrug* it
>probably is. What do I have to go on that it will still be so next year?
Please tell me what yu have "to go on that" SCO will still be EXISTING
next year?
>
>> I personally administer a large number of
>> Linux servers, and do you know how many problems I've had that were
>> caused by the operating system in the past 12 months? Zero. Problems
>> with unsupported hardware? Zero. Performance issues? Zero. If only all
>> prototypes were as stable, eh? ;-)
>
>Popularity is not a valid yardstick. Your successful personal experience and
>that of anyone else you know whos opions you respect, those are valid.
>Popularity? Millions of people eat at McDonalds and run Windows and sit on
>particle board furniture from WalMart.
>And millions of them didn't have a problem all last year.
I would dispute that they didn't have a problem. Millions of people ate
food which is damaging to their health at McDonalds. Millions of people
paid excessive amounts for software controlled by a monopoly.
It's just that those people may not be aware of the harm that was done
to them by McD and MS.
>
J. L. Schilling
> On Sat, 28 Feb 2004 13:29:02 -0500, Brian K. White <br...@aljex.com> wrote:
> >
> >Relative. It's true a distribution could be put out that was careful about
> >what they put their "stable" stamp on,
>
> "Enterprise" distributions are all about? Look at the published support
> plans for those products.
OK, but isn't this an expensive solution based on an annual subscription
model? See http://www.redhat.com/software/rhel/purchase/. How does this
compare with the cost of equivalent commercial Intel-based Unix products?
Jonathan Schilling
Joe Dunning
unstable for his use.
However, if you don't want to pay RH, there are other choices, such as
White Box linux, SuSE has also been mentioned: the provide a 5 year
lifecycle for releases. There are companies offering support for older
RH versions. *Choice* and *freedom* are the issues. .
Brian K. White
heh, idiot.
I learned unix in approximately equal parts linux and xenix at about the
same time, but, seeing as how linux was free I could use it at home, where I
could learn by destroying, and thus learn a _lot_ more a lot faster than I
could the xenix eqivalents. The xenix box was "mission critical" and all
that, and I had to be very very timid when it came to doing anything on it
or with it.
As a result, even today, I am probably slight more capable all in all in
linux than in sco, although the problem has to get pretty obscure before any
appreciable difference can be shown.
The _last_ thing I am is frozen in static skill set unless the skill is "How
to figure out whatever you need to figure out on demand and be right."
I don't fear linux. I just know linux. If sco gets to the point where I
think we need to ditch it, it might be linux I go with, by maintaining my
own distribution or at least my own patch agains some other dist, so that I
can keep things sane, according to my idea of sane. If the apps I needed
were available on native freebsd form, I'd really much rather do that, but
linux is everyones darling, and vendors of traditional unix apps finally
started making linux versions a few years ago out of pure market pressure.
This again, does not imply that linux is the better choice, or that oracle
(the engineers, I could care less about the marketeers) thinks linux is the
better choice. It merely indicates that oracle knows they can sell a lot of
linux copies. Big whup.
IBM is a different situation. They don't just use linux, or accept it, or
sell stuff the runs on it because they know it will sell. They actually work
on linux itself and work towards making linux suitable for use. If they were
to put out a distribution, it would be very interesting to me.
> The evidence against using SCOG products is
> overwhelming:- No future, outdated, little hardware support, no
> community support, vastly outperformed by the competition. If you are
> making ANY sales to new customers, I'd be surprised... and disgusted.
Every day. But then again, I'm not dealing with high school kids who can
afford to goof-off and have nothing much to lose and nothing much important
going on. Mostly customers don't even ask for justification anyways. Comes
time to upgrade, they look a the few K they spent 4 or 5 years ago, and the
total lack of issues with their server all that time, compared to their
friends and competitors constant issues, and they don't even think about
wanting anything else. New customers do of course, but a simple description
of the typical life of a unix box, not imagined or promised, but describing
the history of existing and retired boxes, and conversing with as many of
our other customers as they like, and they make the same no-brainer choice.
By now, a lot of new customers are starting to turn up who actually have
already had linux boxes and a year after they've been on their new sco box,
they can't say enough how glad they are to be done fussing with their server
all the time.
FyRE
wrote:
[...]
>> Face it, SCO were dead long ago. This is why a creep like McBride now
>> hold the reins; there's no hope of the company ever turning a profit
>> by selling it's outdated, overpriced and outclassed product line. The
>> only option for SCOG was litigation. It's a short-term venture now
>> though; the stock price is already plumeting back down to where it
>> belongs, the court case has become a farce (some would argue it always
>> was) and the outright lies from SCOG management are well documented.
>>
>> I'm a little curious as to why anyone would promoted the platform as a
>> realistic choice any more. I can only assume you're a "one trick pony"
>> who is loath to learn anything new, and now stuck with having to trick
>> his clients into continuing to pay for a dead product to fund your
>> pension scheme.
>
>heh, idiot.
Good argument.
>I learned unix in approximately equal parts linux and xenix at about the
>same time, but, seeing as how linux was free I could use it at home, where I
>could learn by destroying, and thus learn a _lot_ more a lot faster than I
>could the xenix eqivalents. The xenix box was "mission critical" and all
>that, and I had to be very very timid when it came to doing anything on it
>or with it.
>
>As a result, even today, I am probably slight more capable all in all in
>linux than in sco, although the problem has to get pretty obscure before any
>appreciable difference can be shown.
Well that's a pretty damning statement. From the obvious ignorance
you've demonstrated here, I'd say you have very little knowledge of
Linux, Brian. You seem oblivious to the Enterprise versions that are
freely available, you don't understand the difference between a
development version and stable, and have made schoolboy errors
concerning the links between the Kernel and applications. (You've
snipped all those parts from this thread though; curious as you don't
usually bother snipping anything - witness the huge amount of
unanswered text in the previous article).
>The _last_ thing I am is frozen in static skill set unless the skill is "How
>to figure out whatever you need to figure out on demand and be right."
Well if you've somehow become convinced that this newsgroup requires a
clown, then I congratulate you!
>I don't fear linux. I just know linux.
That statement is demonstrably untrue. The evidence for this is
contained in your own ignorant comments peppering this newsgroup.
>If sco gets to the point where I
>think we need to ditch it, it might be linux I go with, by maintaining my
>own distribution or at least my own patch agains some other dist, so that I
>can keep things sane, according to my idea of sane.
HAHAHAHAHA!!! Brian, you're a classic - please tell me you're not
serious! Do you really think that you, "Brian White" can create and
maintain a more stable and useful distribution of Linux all by your
lonesome than Linux companies who, as well as employing a large number
of the kernel developers, have been doing this for years? Even if you
did manage it (not that you would of course), who'd use it?! You
obviously have virtually no idea of how Linux is created or
maintained, yet you expect yourself to be able to create patches and
rewrite code to address security flaws. You're also going to have to
support this bastardised distro with downloadable updates and so on.
I hope to god you don't ever start selling Linux, Brian. You're likely
to do the OS more harm than SCOG with your bumbling...
>If the apps I needed
>were available on native freebsd form, I'd really much rather do that,
...even though you've never mentioned ever having used FreeBSD... Big
surprise ;-)
>but
>linux is everyones darling, and vendors of traditional unix apps finally
>started making linux versions a few years ago out of pure market pressure.
>This again, does not imply that linux is the better choice, or that oracle
>(the engineers, I could care less about the marketeers) thinks linux is the
>better choice. It merely indicates that oracle knows they can sell a lot of
>linux copies. Big whup.
Erm Brian; if you'll care to look into the subject, it was the
engineers at Oracle that drove the migration toward Linux, not the
marketing department ;-) In fact this has been the case at a great
many companies. Since it's freely available, anyone can try it out,
and these people realise how good it is and the snowball builds. With
SCOG software, you pay x thousand dollars, realise with utter horror
how bad UNIX was 20 years ago, then notice the companies current
attempts at self-destruction and migrate to Linux (supported, with a
future).
>IBM is a different situation. They don't just use linux, or accept it, or
>sell stuff the runs on it because they know it will sell. They actually work
>on linux itself and work towards making linux suitable for use. If they were
>to put out a distribution, it would be very interesting to me.
You fool. You think any other large Linux vendor _doesn't_ work on
Linux?! Both Redhat and SuSE employ kernel developers, and support the
major application teams (either financially, or with programmers). IBM
themselves work with RH and SuSE (SuSE is actually their Linux distro
choice on mainframes, not that you'd know of course).
>> The evidence against using SCOG products is
>> overwhelming:- No future, outdated, little hardware support, no
>> community support, vastly outperformed by the competition. If you are
>> making ANY sales to new customers, I'd be surprised... and disgusted.
>
>Every day.
Sure, sure... ;-) You must be SCOG's top reseller on Earth now then!
>But then again, I'm not dealing with high school kids who can
>afford to goof-off and have nothing much to lose and nothing much important
>going on.
Neither am I. I suppose all the big Financial houses running Linux on
their servers are all "high school kids" too, right Brian? ;-) You're
a funny guy...
>Mostly customers don't even ask for justification anyways.
Lucky for you, if you can trick ignorant people into buying a
dead-ended, overpriced and underperforming product to make a quick
buck, and live with yourself afterwards.
>Comes
>time to upgrade, they look a the few K they spent 4 or 5 years ago, and the
>total lack of issues with their server all that time, compared to their
>friends and competitors constant issues,
If their friend's servers were set up by you, I wouldn't wonder they
had issues. Of course, yet again you'll present no evidence for this
;-)
>and they don't even think about wanting anything else.
Easy sell then. Funnily enough, in my experience, companies who don't
investigate other options, or financial implications when it comes
time to upgrade their kit tend to go out of business...
>New customers do of course, but a simple description
...by you...
>of the typical life of a unix box, not imagined or promised, but describing
>the history of existing and retired boxes, and conversing with as many of
>our other customers as they like, and they make the same no-brainer choice.
It certainly does show lack of brains. From your
liesH^H^H^H^statements here, you seem to portray a glowing picture of
SCOG's products and success stories. We all know this is untrue, in
fact on SCOG's own website (when it's running) one of their top
"success stories" is of a company that have subsequently switched over
to Linux! If SCOG were doing well, they wouldn't have launched this
desperate attempt to kill the OpenSource movement (despite the fact
SCOG themselves use it's software, for free). They've stated in court
that they cannot compete (although this may be one of their countless
lies of course). Yet, good old Brian K. White is creating hundreds of
new customers every year, huh? Colour me skeptical...
>By now, a lot of new customers are starting to turn up who actually have
>already had linux boxes and a year after they've been on their new sco box,
>they can't say enough how glad they are to be done fussing with their server
>all the time.
What a load of rubbish. Perhaps you'd like to tell us all just what
sort of things these hapless customers were "fussing with" on their
Linux boxes? No? What a surprise.
Brian, I think it's fair to say you're an outright liar.