Re: Anyone know why the Alpha market is so so quiet?

In article <1179847916.555477.223420@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
Andrew <andrew_harrison@xxxxxxxxxxxx> wrote:
On 20 May, 15:43, Chip Coldwell <coldw...@xxxxxxxxxxxxxxxxx> wrote:
On Fri, 18 May 2007, ChrisQuayle wrote:

Why would anyone in their right mind want to run Linux for mission critical
stuff when Solaris is now free, industrial strength, has decades of
professional development effort and runs on Sparc or X86 ?

Because they are pessimistic about the long-term prospects for Sun as a
company. Linux has the property that it is owned by nobody, so there is
nobody to go broke and strand the customer. For example, you can now buy
support for the Red Hat Enterprise Linux distro from either Red Hat or
Oracle. If one of those two goes broke, switch to the other one.


Ahh but this is Linux's great strength while at the same time being
its greatest weakness as well.

From a hobbyist perspective the bazaar approach to developing an OS
platform is very attractive, it bodes well for longevity and the rapid
inclusion of new features. That is if you do not care too much about
compatibility and stability.

From an enterprise perspective the bazaar approach causes huge
problems of ownership. The code maintainers and developers who will be
responsible for fixing XYZ issue almost certainly do not work for
Oracle or RedHat instead they may work in academia etc, so while
RedHat or Oracle may be able to manage your support problem ultimately
they may be powerless to effect a change that resolves your problem.

Buying AIX/HP-UX/Solaris/Windows or VMS gives any enterprise customer
a degree of certainty that their problem will be rectified and in a
way that does not break random other bits of their OS, this certainty
simply isn't there in the Linux world.


Not true that the enterprise customer would get the support they pay
for.

In the mid 80's I worked for a Concurrent Computer in their IT dept.
We noticed cron jobs were not getting run and cron was dying on their
Xelos System V operating system.

I reported the problem to support (I was internal to the company but
used the normal support chanels.) The bug was kicked up to AT&T.
The cron was malloc'ing memory and never releasing it so it used up all
the memory available and then core dumped.

th.) The bug was kicked up to AT&T.
The cron was malloc'ing memory and never releasing it so it used up all
the memory available and then core dumped.

th.) The bug was kicked up to AT&T.
The cron was malloc'ing memory and never releasing it so it used up all
the memory available and then core dumped.

th.) The bug was kicked up to AT&T.
The cron was malloc'ing memory and never releasing it so it used up all
the memory available and then core dumped.

th.) The bug was kicked up to AT&T.
The cron was malloc'ing memory and never releasing it so it used up all
the memory available and then core dumped.

th.) The bug was kicked up to AT&T.
The cron was malloc'ing memory and never releasing it so it used up all
the memory available and then core dumped.

th.) The bug was kicked up to AT&T.
The cron was malloc'ing memory and never releasing it so it used up all
the memory available and then core dumped.

th.) The bug was kicked up to AT&T.
The cron was malloc'ing memory and never releasing it so it used up all
the memory available and then core dumped.

th.) The bug was kicked up to AT&T.
The cron was malloc'ing memory and never releasing it so it used up all
the memory available and then core dumped.

th.) The bug was kicked up to AT&T.
The cron was malloc'ing memory and never releasing it so it used up all
the memory available and then core dumped.

th.) The bug was kicked up to AT&T.
The cron was malloc'ing memory and never releasing it so it used up all
the memory available and then core dumped.

th.) The bug was kicked up to AT&T.
The cron was malloc'ing memory and never releasing it so it used up all
the memory available and then core dumped.

th.) The bug was kicked up to AT&T.
The cron was malloc'ing memory and never releasing it so it used up all
the memory available and then core dumped.

th.) The bug was kicked up to AT&T.
The cron was malloc'ing memory and never releasing it so it used up all
the memory available and then core dumped.

th.) The bug was kicked up to AT&T.
The cron was malloc'ing memory and never releasing it so it used up all
the memory available and then core dumped.

th.) The bug was kicked up to AT&T.
The cron was malloc'ing memory and never releasing it so it used up all
the memory available and then core dumped.

th.) The bug was kicked up to AT&T.
The cron was malloc'ing memory and never releasing it so it used up all
the memory available and then core dumped.

th.) The bug was kicked up to AT&T.
The cron was malloc'ing memory and never releasing it so it used up all
the memory available and then core dumped.

th.) The bug was kicked up to AT&T.
The cron was malloc'ing memory and never releasing it so it used up all
the memory available and then core dumped.

th.) The bug was kicked up to AT&T.
The cron was malloc'ing memory and never releasing it so it used up all
the memory available and then core dumped.

th.) The bug was kicked up to AT&T.
The cron was malloc'ing memory and never releasing it so it used up all
the memory available and then core dumped.

th.) The bug was kicked up to AT&T.
The cron was malloc'ing memory and never releasing it so it used up all
the memory available and then core dumped.

th.) The bug was kicked up to AT&T.
The cron was malloc'ing memory and never releasing it so it used up all
the memory available and then core dumped.

th.) The bug was kicked up to AT&T.
The cron was malloc'ing memory and never releasing it so it used up all
the memory available and then core dumped.

th.) The bug was kicked up to AT&T.
The cron was malloc'ing memory and never releasing it so it used up all
the memory available and then core dumped.

th.) The bug was kicked up to AT&T.
The cron was malloc'ing memory and never releasing it so it used up all
the memory available and then core dumped.

th.) The bug was kicked up to AT&T.
The cron was malloc'ing memory and never releasing it so it used up all
the memory available and then core dumped.

th.) The bug was kicked up to AT&T.
The cron was malloc'ing memory and never releasing it so it used up all
the memory available and then core dumped.

th.) The bug was kicked up to AT&T.
The cron was malloc'ing memory and never releasing it so it used up all
the memory available and then core dumped.

th.) The bug was kicked up to AT&T.
The cron was malloc'ing memory and never releasing it so it used up all
the memory available and then core dumped.

th.) The bug was kicked up to AT&T.
The cron was malloc'ing memory and never releasing it so it used up all
the memory available and then core dumped.

th.) The bug was kicked up to AT&T.
The cron was malloc'ing memory and never releasing it so it used up all
the memory available and then core dumped.

th.) The bug was kicked up to AT&T.
The cron was malloc'ing memory and never releasing it so it used up all
the memory available and then core dumped.

th.) The bug was kicked up to AT&T.
The cron was malloc'ing memory and never releasing it so it used up all
the memory available and then core dumped.

The answer from the OS develeoper/vendor is "Get a machine with demand
paged virtual memory, we never see the problem on those boxes."
Thank you #@$ much AT&T.

Having source code to the OS allows you to fix your own problmes.
Counting on a vendor to do what they should do is leaving your fate in
others hands. I've taken software issues to DEC, Sun, IBM etc.
Sometimes the response is excellent... sometimes the response is
dependant on the financial state and staff load at the company.

At least Open Source (and Solaris is getting there) gives you the option
to do it yourself.


Regards
Andrew Harrison



Bill
--
--
"When I think back on all the crap I learned in Vax school
It's a wonder I fixed anything at all." (to the tune of Kodachrome)
pechter-at-gmail.com
.

Relevant Pages

  • Re: chron overhead
    ... It would take a failure of cron itself to ... I'm slightly surprised it uses 100 MB of memory even when not running. ... There's a lot of crap running on that machine (apache2, tomcat, mysql ... huge array) forces Tomcat's resident size down to 5916. ...
    (comp.lang.java.programmer)
  • Re: chron overhead
    ... With a program that does the job once and exits, but which is scheduled by cron or similar, the worst a crash or hang can do is clobber one run. ... I guess you could use some external utility to monitor your looping program and restart it if it crashes. ... I'm slightly surprised it uses 100 MB of memory even when not running. ...
    (comp.lang.java.programmer)
  • Re: Spontan reboot of FreeBSD 4,x box
    ... cron is'nt running? ... Regards, ... bug you have in the kernel, or bad memory. ... a fbsd file system if you wish to try the bad memory theory ...
    (freebsd-net)
  • Re: Can 10M Buffer Ceiling be lowere?
    ... >>I would like to get as much out of my memory as possible. ... With a few unneeded services (cron, sendmail) disabled, I ... Also note that cron is responsible for such things as the routine system ... if you really insist on disabling cron, ...
    (freebsd-questions)
  • Re: Forth as an operating system
    ... Suppose that bug results in failure to yield. ... Or what happens on a memory leak? ... E.g. how to deal with idiots who ... defined interface or architectures, either, and even good programmers tend ...
    (comp.lang.forth)