Let me do a little advertising for a local company here in Champaign, IL, USA called Champaign Computer. They build machines to spec, and they ship to anywhere in the US.
They will sell you a system bare, or they can
preload (for an extra charge) Linux, Solaris,
or Windows (several flavors).
"writing a new interpreter for the platform" is actually as simple as pickup up the JVM source code (yes, Sun releases source to their JVM) and recompiling it on the target platform.
These are clearly the words of someone who has
never tried to port the JVM to a new platform.
In fact, there is quite a bit of extremely
tricky platform-specific code (for example,
the stuff that interfaces to threads and
synchronization).
Beyond this, remember the fact that you can't
distribute your port without negotiating a
license with Sun. The source code to the JVM
is released under a restrictive license, but
the test suite that must be passed before
distribution is allowed is locked up tightly.
It is not even available to all potential
customers on nondiscrimatory terms: if your port
does not fit with Sun's current business
objectives, then you just can't buy the test
suite.
It's interesting that you highly recommend VMIC.
My experience with them has been partly positive
but mostly negative:
There is at least one advertised feature,
100BASE-T Ethernet, that has never been made to
work at all on our boards (the 233 MHz
Pentium MMX based VMIVME7589).
Half the time, the boards don't work;
we expect to send ours back home to Alabama every few months. They seem to develop internal loose connections easily.
When the boards don't work, the customer
service people are admitedly very good about
taking them back and fixing them promptly.
The vxWorks development tools are pretty
poor, but that's Wind River's fault. We switched
over to Linux for our last experiment, and it
was like a dream come true.
Has anyone managed to do a shared installation
of OpenOffice 6.0 on Linux successfully? The general idea is that you run the setup script as
root with the "/NET" flag to install it in a
central place, and then each user can run it again without the "/NET" to install their personal configuration files. This worked well
at least through StarOffice 5.1.
However, all I get with this version is a"Application ErrorAbort" message. I'm running it on Debian potato. Has anyone had better luck?
The great thing is that the source code is now
out there to help track this kind of problem down. Thanks, Sun!
What you are saying is true for low optimization
levels (-O0 and -O1). Those of us who use Linux
for scientific calculations need optimizations to
work reliably (or it takes, say, six weeks instead of two weeks for us to get an answer!).
In gcc "2.96" optimization levels beyond -O1
(at least for the C++ front end) can be counted
on to produce internal compiler errors or
incorrect object code.
Is it worth pointing out that there are two
different institutions involved here? UW is the
University of Washington (in Seattle) and WU
is Washington University (in St. Louis).
It should be pointed out that mod_ssl also requires a patch to Apache; it can't be run with the plain vanilla Apache binary that may have come with your Linux distribution.
gcc "2.96" isn't suitable for compiling anything as far as I can tell. In particular, compiling
scientfic C++ code with optimization beyond -O1
tends to produce not just crashes but even wrong
answers. There is a reason why it wasn't released
yet by the gcc maintainers: it is simply not ready
for everyday use.
No, in the U.S. these "condition of sale"
clauses are not enforcable. There is a
"doctrine of first sale" that basically says
that the buyer of a book can do whatever he/she
wants with it once it's been sold once by the
publisher.
In fact, when we get international paperbacks
over here, this
clause always seems to begin with "Except in the United
States of America, this book is sold...".
Re:What it is and why Linux won't run on it.
on
Quad G4 Boards
·
· Score: 1
I'll also point you to this page on the manufacturer's web site which specifically says that they support Linux on their boards. The page has a pretty cool "industrial penguin" logo...
Admittedly, they do not claim that SMP or real-time features will be ready until Q3 2000, but that's only a few months away.
Re:What it is and why Linux won't run on it.
on
Quad G4 Boards
·
· Score: 1
I beg to differ on the point "LINUX DOES NOT SUPPORT VME." I'm currently in the process of putting together a data acquisition system for a particle physics experiment. For our test run this summer, we will be running Linux on a 200 MHz Pentium-based VME single-board computer. I can tell you from close firsthand experience that (with an appropriate driver for the VME chipset) LINUX SUPPORTS VME. The VMEbus address space appears as a device file on which you can use all of the usual I/O system calls, including read(), write(), and mmap(). There are two driver implementations out there; my experience is with this one.
Why use Linux instead of the more conventional vxWorks? As usual, the reason is reliability. vxWorks provides no memory protection between processes. Programming errors quickly lead to a need to reboot, requiring several minutes of experimental downtime. When your accelerator costs tens of thousands of dollars per hour to operate, any downtime becomes inexcusable. In addition, the ready availability of excellent development and debugging tool makes it possible to put together a project like this with limited manpower.
It is possible to pay a wide variety of prices for a VME crate. A 6U crate with a small power supply should only cost you a few thousand dollars.
You're certainly right: we all appreciate the fact that Sun may begin treating Linux as a first-class, supported platform for Java.
However, the process by which this was accomplished was nothing short of abysmal. Sun did not coordinate with the Blackdown team in any way to arrange for a smooth handover of responsibility. They also did not give credit to Blackdown for their years of dedicated work. This has led to a bad situation in at least two ways. First of all, the Sun/Inprise JDK is seen to be tainted by Sun's lack of basic courtesy and integrity. More importantly, Sun may have lost its chance to take full advantage of Blackdown's accumulated experience. Blackdown has made many substantial improvements since the point where the Sun/Inprise code forked away from it, especially in the area of the native threads virtual machine. Because they did not coordinate their actions with Blackdown, Sun produced a lower-quality release of the JDK.
I hope that Sun is able to reconcile its differences with Blackdown. They need to keep this in mind: they may have alienated a group of people who could be very useful to them in the future. The Blackdown team is a collection of the world's foremost experts on the subject of porting Java to Linux. Sun could benefit from working with them rather than against them.
I hope that another press release is forthcoming from Sun that will make clear the extent of the contributions from Blackdown and apologize for their previous oversight.
Actually, the biggest threat to the environment in that area is quite clear: it's the Long Island Expressway. The worst-case failure scenario at the High Flux Beam Reactor (the nuclear reactor at BNL that worries many residents so much) would increase the risk of cancer far less than the increment provided by the traffic on that one road.
RHIC will operate at energies of up to about 100 GeV per nucleon (that is, proton or neutron).
There is lots of scientific information about RHIC here. Follow the links to "Documentation" and "RHIC Design Manual" for detailed information about its motivation and specifications.
See www.c-computer.com.
Also, see the (free software) SquidGuard add-on to the Squid proxy server at http://www.squidguard.org.
These are clearly the words of someone who has never tried to port the JVM to a new platform. In fact, there is quite a bit of extremely tricky platform-specific code (for example, the stuff that interfaces to threads and synchronization).
Beyond this, remember the fact that you can't distribute your port without negotiating a license with Sun. The source code to the JVM is released under a restrictive license, but the test suite that must be passed before distribution is allowed is locked up tightly. It is not even available to all potential customers on nondiscrimatory terms: if your port does not fit with Sun's current business objectives, then you just can't buy the test suite.
I just did an "apt-get install nedit"--it looks like a great editor. Thanks!
However, all I get with this version is a"Application ErrorAbort" message. I'm running it on Debian potato. Has anyone had better luck?
The great thing is that the source code is now out there to help track this kind of problem down. Thanks, Sun!
What you are saying is true for low optimization levels (-O0 and -O1). Those of us who use Linux for scientific calculations need optimizations to work reliably (or it takes, say, six weeks instead of two weeks for us to get an answer!). In gcc "2.96" optimization levels beyond -O1 (at least for the C++ front end) can be counted on to produce internal compiler errors or incorrect object code.
Is it worth pointing out that there are two different institutions involved here? UW is the University of Washington (in Seattle) and WU is Washington University (in St. Louis).
It should be pointed out that mod_ssl also requires a patch to Apache; it can't be run with the plain vanilla Apache binary that may have come with your Linux distribution.
Hmm, it is true that Cygnus was the first commercial support company for free software.
gcc "2.96" isn't suitable for compiling anything
as far as I can tell. In particular, compiling
scientfic C++ code with optimization beyond -O1
tends to produce not just crashes but even wrong
answers. There is a reason why it wasn't released
yet by the gcc maintainers: it is simply not ready
for everyday use.
In fact, when we get international paperbacks over here, this clause always seems to begin with "Except in the United States of America, this book is sold...".
Admittedly, they do not claim that SMP or real-time features will be ready until Q3 2000, but that's only a few months away.
Why use Linux instead of the more conventional vxWorks? As usual, the reason is reliability. vxWorks provides no memory protection between processes. Programming errors quickly lead to a need to reboot, requiring several minutes of experimental downtime. When your accelerator costs tens of thousands of dollars per hour to operate, any downtime becomes inexcusable. In addition, the ready availability of excellent development and debugging tool makes it possible to put together a project like this with limited manpower.
It is possible to pay a wide variety of prices for a VME crate. A 6U crate with a small power supply should only cost you a few thousand dollars.
You're certainly right: we all appreciate the fact that Sun may begin treating Linux as a first-class, supported platform for Java.
However, the process by which this was accomplished was nothing short of abysmal. Sun did not coordinate with the Blackdown team in any way to arrange for a smooth handover of responsibility. They also did not give credit to Blackdown for their years of dedicated work.
This has led to a bad situation in at least two ways. First of all, the Sun/Inprise JDK is seen to be tainted by Sun's lack of basic courtesy and integrity. More importantly, Sun may have lost its chance to take full advantage of Blackdown's accumulated experience. Blackdown has made many substantial improvements since the point where the Sun/Inprise code forked away from it, especially in the area of the native threads virtual machine. Because they did not coordinate their actions with Blackdown, Sun produced a lower-quality release of the JDK.
I hope that Sun is able to reconcile its differences with Blackdown. They need to keep this in mind: they may have alienated a group of people who could be very useful to them in the future. The Blackdown team is a collection of the world's foremost experts on the subject of porting Java to Linux. Sun could benefit from working with them rather than against them.
I hope that another press release is forthcoming from Sun that will make clear the extent of the contributions from Blackdown and apologize for their previous oversight.
Actually, the biggest threat to the environment in that area is quite clear: it's the Long Island Expressway. The worst-case failure scenario at the High Flux Beam Reactor (the nuclear reactor at BNL that worries many residents so much) would increase the risk of cancer far less than the increment provided by the traffic on that one road.
RHIC will operate at energies of up to about 100 GeV per nucleon (that is, proton or neutron).
There is lots of scientific information about RHIC here. Follow the links to "Documentation" and "RHIC Design Manual" for detailed information about its motivation and specifications.