|
Readers Speak Out: Letters to the EditorThis month: Luddites or visionaries? More readers debate Sun's Java fixation; year 2000 compliance issues with Barry Bowen; Q & A with Adrian Cockcroft; and a few "break-and-enter" tips from Security expert Peter Galvin |
Mail this article to a friend |
Send letters to sweditors@sunworld.com
I just read your article in SunWorld:
In a nutshell, shame on Mr. Shoemaker. Making sure that all systems are year 2000 compliant should be at the top of his list of problems to be solved. I realize that Solaris per se won't be harmed by the calendar rollover, but that doesn't mean that clients relying on Sun machines as servers or applications written under Solaris won't have problems.
Karl Vogel
Barry responds:
Karl:
What you say is absolutely true. However, the focus of this story was
what corporate computing will look like in the year 2000. I
leapfrogged year 2000 compliance issues because mainstream corporate
environments had better have that problem solved prior to system and
application failures. Mr. Shoemaker may have simply followed my lead.
Year 2000 compliance is a serious topic on which I've written for
Sybase Magazine and Sun Journal. The latter may soon be
posted on Sun's Year 2000 Web site (http://www.sun.com/y2000).
Year 2000 is a tough thing to write about because by now firms either
know the issues and have projects up and running, or they're asleep at
the wheel, in which case it's already too late. However, the
Sun Journal story did attempt to offer some pointers for folks
getting started late in the game.
Thanks for the feedback.
I think Sun is too Java centric, but they're doing a fairly good job with it. However, I do think they're going a little bit overboard. Java has had to mature too quickly at a high price. Java has no competition in its category, so Sun doesn't have to go so fast. Too much excitement can create a catastrophic end.
What I loved about Java was that it was simple, now it's become a monster, compatible with everything, patched to everything...
Sun has to give Java its own identity, keep it simple and elegant but powerful. Don't let the voice of the market change your vision; bring to the market a new voice and a new vision.
David Rodriguez
No! I am glad someone is making sure something is happening. We have been using low-level languages too long (C, C++). It's time for change. Although Java is not perfect, it's easy enough for beginning programmers to learn and powerful enough for advanced programmers to write advanced software (which is more than you can say for C++ and Visual Basic).
Java is a modern language with the necessary elements for today's demanding world of multithreaded, multitier, multiplatform application development.
Lars Jonsson
Yes, for the reason that the focus and hype is not proportionate to Java reality. When and if the speed-optimized apps are released the answer will probably be "No," because the attention will be well deserved.
Please, Sun, let's get out some high-performance Java products as soon as possible. We're getting impatient.
Ken Wu
I am surprised by your question, much less the responses.
I certainly don't think Sun's too Java-centric. And most of your readers who use Java on a day to day basis don't think so either. They're the "silent majority" -- those of us simply too busy developing really superb apps to bother responding to silly questions.
Michael McConnell
Java is just another language. Most of what's written about it is hype. This year Java, next year -- ?
Doug Johnston
I've been working in the OO-programming field for a ten years. My first love (in programming!) was Smalltalk. Now I feel the spirit of Smalltalk in Java! What do I like in Java?
First, Java is conceptually a clean language. This is very different from the C++, in that there's a typical adaptation of a procedural language toward the OO-world. It is a very strong solution -- it broke the line of procedural languages and jumped to pure object-oriented programming.
Secondly, Java is a language which gives us freedom. Now we can program for numerous computer platforms. We can forget about monopolists like the Microsoft empire. When I can see what's inside the OS or JVM, I can program much more effectively.
I don't think the performance of Java is too slow. I've been working on a large Java project for two years, and I've had the chance to try Java solutions from alpha and beta versions. The speed of these solutions is very impressive and of them all I think Java-in-the-chip is the best. Embedding Java in the most popular processors is the way to pure Java.
In answer to your question, I think that people critical of the ways of Sun/Java are Luddites.
Andrei R. Yershov
Siberian Energy Institute,
Irkutsk, Russia
I don't usually write in response to these items, but recent events have prompted me to do so in this case. I worked for Sun 10 years ago. I beta tested Java when it was just an idea that a bunch of engineers were playing with. Sun management wasn't supportive of the effort, and Sun marketing dismissed the www as being too slow to ever take off.
Now of course, you can't get near Sun without Java being shoved down your throat. Literally. The local Sun office here in Australia has just made the Sun Web site Java only. In other words, you can only access the information there if you have Java. This is the last straw. Java is still dreadfully insecure and for Sun to be making Java a mandatory part of their www sites is, in my opinion, verging on criminally negligent. We used to refer our customers to the Sun pages all the time, but no longer. It would be irresponsible of us to do so, given the security problems surrounding Java.
Java is a great concept, but the current implementation is far too slow, far too buggy, and far too insecure to be taken as seriously as the marketing people are hyping it.
Simon Woodhead
I feel that Sun should devote more resources to improving the cost and performance of what I consider to be Sun core products -- Solaris, CDE, Sun Net Manager, management tools, hardware, storage technology, etc.
Java is flashy, cute, and may even serve a useful business function for some, but I see little benefit to our company.
Hopefully Java is generating more revenue for Sun than it's spending on all this hype.
Joe Salerno
I work for a company that protects authors and editors rights in Italy, and I'm afraid that Java is too vulnerable to reverse engineering to become the choice for a software house. There should be some way to stop other people from getting into the code.
If this problem is solved Java could become a revolution, but it must be carefully managed to make it.
Luca Regoli
To Adrian Cockcroft:
I'm currently writing my thesis on how to calculate resources that have been used by software running in a Sun Unix-based client/server environment. I know that SunOS provides an accounting system, but I need a scientific understanding of resource accounting.
I want to know what resource information is of interest, how to collect it, and how to process it. I've looked in the Answerbook and read all the man pages, but the information just isn't sufficient.
Can you help me?
David Barton
Adrian responds:
The accounting data structure is OK but very basic.
The way that sophisticated tools do this is to sample the active
processes on the system via /proc, I describe ways to do this in my
August
1996 column "What's the best way to probe processes?" (http://www.sun.com
/sunworldonline/swol-08-1996/swol-08-perf.html)
Check out products by BGS, http://www.bgs.com. The company provides very sophisticated
resource usage collection and modeling in its Best/1 product.
A standard text book on this subject is The Art of Computer Systems
Performance Analysis by Raj Jain, published by Wiley.
Intimate shared memory
To Adrian Cockcroft:
I need to share memory (16 MB) between 2 processes. You wrote about a method used by Oracle (and others) in which they where able to share large amounts of LOCKED down memory -- you called it "intimate shared memory." Where can I find more information on this subject?
Thanks,
John B. Petritis
Adrian responds:
John,
% man shmat
When (shmflg&SHM_SHARE_MMU) is true, virtual memory resources in
addition to shared memory itself are shared among processes that use the
same shared memory.
Intel Pentium and UltraSPARC, what's the difference?
To Adrian Cockcroft:
I read your November 1995 SunWorld column, "When is it faster to have 64 bits?" (http://www.sun.com/sunworldonline/swol-11-1995/swol-11-perf.html) It was very interesting, and it helped me to understand some features and characteristics of the SPARC processor.
I'm the Regional Sales Manager of ComWare Ecuador, we're the Sun Microsystems resellers and distributors for Ecuador. Sometimes (more often than I would like) people say the Pentium chip is also 64 bits, same as UltraSPARC.
How can I explain the differences between Intel Pentium and UltraSPARC?
L. Benites
Adrian responds:
The first real 64-bit Pentium system will be
the P7 or Merced in 1999 or so. The current Pentium Pro has a 64-bit bus
interface running at 66 MHz. The Ultra 1 and 2 have a 128-bit bus
interface running at 83 or 100 MHz, hence the peak CPU bandwidth for the
Pentium Pro is 528 MB/s and the Ultra is 1328 or 1600 MB/s.
The Ultra I and Ultra II will be able to run a full 64-bit OS like the
DEC Alpha and SGI IRIX6 with just a software upgrade to Solaris 2.7. The
Intel systems will need a full CPU upgrade to the P7 to run a 64-bit OS.
The Pentium Pro is faster at integer than an Ultra at the same clock
rate and cache size. However the biggest cache on Pentium is 512 KB (I
think) and when an Ultra has a 2 MB or 4 MB cache and runs at 250 or 300
MHz it is faster than Intel at integer. For floating point the Ultra is
always faster as SPARC has lots of floating point registers and Intel
has very few, which is the biggest reason for RISC chips always being
faster at floating point.
I hope that helps.
Editor's note: For more reader Q&A with Adrian check out http://sw.wpi.com /common/cockcroft.letters.html
To Peter Galvin:
For the last two years I've been involved in system administration of Sun Ultra1/Solaris 2.5. Yesterday I changed the root password on one of the machines, now I can't remember it.
I don't want to reload the OS, etc. Do you know a simpler way to change the root password?
MMV Prasad
Peter responds:
Hi Prasad,
This situation is fairly common. When I need to "break-in" to a machine
to which I have physical access, I try to boot from CD-ROM, mount the
root hard disk, and edit the shadow file.
Remove all the characters from the password field so the password is empty.
After editing, save the file, and reboot.
There are other ways in if you don't have a CD-ROM drive, but that's the
easiest.
To Bill Rosenblatt:
Thank you for deflating some of Yourdon's more pompous crap once and for all. [See Bill's review, "Death March author Ed Yourdon admits he was wrong" in the July issue for details --editor] You give the man his due for the contribution of structured methodologies -- which is well-deserved -- but Yourdon's days as techno-icon have long since played out.
I am presently employed in the fast and furious Internet development world and have witnessed first hand the results of abandoning a sound design process to rush something out the door. I can attest to the fact that products generated in this manner can all be described with the same words: Bug-riddled crap. In the Internet age there is still no substitute for caring enough about quality to take the time to do it right the first time.
For one of Yourdon's stature to suggest in the midst of the rise of OOP that we jettison methodology is irresponsible. I don't think that anyone can write a useful library of classes without sound design. Contrary to Yourdon's "wisdom," in the object world sound design methodology rules. Those who choose to design "on the fly" are doomed to failure.
Thom Gourley
Bill's reply:
Thom,
Thanks for your letter. As someone who has been a software engineer for
a large company (Motorola) and who has studied the subject at the
graduate level, my personal feelings are somewhat extreme and succinct:
a) Data abstraction is the only truly interesting innovation to come out
of the field of software engineering since Algol 60. The rest is, at
best, just enforced documentation standards. The latter statement
applies equally to pragmatists like Yourdon and theoreticians in
academia.
b) Object-oriented languages (when used properly) impose data
abstraction principles on design; therefore, they are valuable.
c) Good tools can save you time; otherwise, nothing else is particularly
important.
Send letters to sweditors@sunworld.com
|
If you have technical problems with this magazine, contact webmaster@sunworld.com
URL: http://www.sunworld.com/swol-08-1997/swol-08-letters.html
Last modified:
|
If you have technical problems with this magazine, contact webmaster@sunworld.com
URL: http://www.sunworld.com/swol-08-1997/swol-08-letters.html
Last modified: