Slashdot Mirror

Brian Kingsbury writes: "The New York Times has an article on a new twist in the world of the Sims --- a "virus" that can kill off a player's characters. In a particularly sadistic twist, the virus is carried by a guinea pig that players download from the Sims Web site. I wonder what's next, maybe the Black Death? " That's all Nate would have needed to complete his House of Fear - locked doors, no food, two ghosts, and the kitchen on fire. Will Wright, you're a genius.

JellyBeans writes: "There's a hands-on preview of 3dfx' Napalm chip (the Voodoo5 5500), where it's compared to a GeForce 256 from NVIDIA. It seems that two chips are NOT better than one in this case (SLI of the Voodoo5 doesn't beat the GeForce)." Okay, these cards can be used for more than games, but who do I think I'm kidding?

krshultz writes "IBM has posted a great technical article on Java performance on its DeveloperWorks site. I learned a lot about Java and Linux in general." This is a nice big well-indexed article. Go.

krshultz writes "Salon has a piece on Red Hat's aquisition of Cygnus Solutions. It mentions concerns that shareholders might see more dollar signs in proprietary software, and there's an interesting bit about the future of things like gcc." I didn't know gcc had a steering committee. It's nice to see its developers concerned about what all this will mean to the community.

This week, for your questioning pleasure, we have assembled a four-member panel of antitrust experts who are willing to speculate on what might happen to Microsoft next - if anything. But before you start posting questions, please hit some of the links we've provided to several other stories about the potential results of Judge Jackson's Nov. 5 Findings of Fact. (more below)

First, let's introduce our guests:

Don Weightman was the gentleman who did our Instant Legal Analysis immediately after the Findings of Fact announcement. We had many requests for him as an interview guest. So here he is.

Richard Hawkins engaged in the general practice of law for five years prior to obtaining his Ph.D. in Economics and Statistics. He is currently a visiting assistant professor of economics at the University of Northern Iowa, and practices only in antitrust and other economic issues in the law. His past includes both hardware and software development, including the mail-merge patch for LyX.

John Lederer is a retired lawyer in Oregon, Wisconsin. He is currently active in technology and intellectual property issues. He practiced in the antitrust and transportation areas and argued three U.S., Supreme Court cases.

David Niemi is a system engineer with a background in economics as well as software. He has been administering and developing for UNIX and Linux since 1987, and has been following Microsoft's antitrust adventures closely since 1993.

Next, a few selected stories about the Microsoft Saga that you may not have read:

• Findings of Fact, A Two-Themed Opus (from The Linux Show.)
• Jerry's Take On The Microsoft Decision: Wrong! (Jerry Pournelle in Byte.)
• Microsoft willing to settle antitrust case (from the Boston Globe.)
• Now bust Microsoft's trust (from The Economist.)
• Militant Microsofties Bunker mentality... (from SF Gate.)
• Don't You Sass Me, Mr. Micro-Smartypants! is a humor piece we couldn't resist including that talks about how things might go if Judge Judy was in charge of the Microsoft trial. It's from - believe it or not - The New York Times. (Free registration required to read.)

Necessary Legal Disclaimer: Although three out of our four panelists are attorneys, all they are providing here is speculation. While our panelists are smart and well-read, no one can predict the future accurately, so you should not base business or personal decisions on their answers to Slashdot readers' questions. For legal or investment advice, please arrange a personal consultation with a qualified professional.

Now Let's Get Down to Business

As usual, moderators will select the most interesting questions, and Tuesday afternoon Slashdot editors will do the final "cut" and forward 10 - 15 chosen questions to the panelists - who are all Slashdot readers, just so you know. Answers will appear Friday. So ask away!

Eddie writes "Don't know how to stop your video recorder flashing 12:00. Want to run Linux on your TV top. Check out the latest in Linux powered boxes. " Its about the TiVo. And I think that I'm in love. Although I don't see anything about Linux in there...

Andrew Hagen writes "Network Associates, formerly McAfee, developer of PGP, has quietly rejoined the Key Recovery Alliance. Despite withdrawing from the group last December amid pointed concerns over the continued trustworthiness of PGP, NAI apparently rejoined the Key Recovery Alliance (KRA) three months later with their February 1998 acquisition of Trusted Information Systems, a founding member of the KRA. The KRA's major stated goal is creation of "a global infrastructure that supports recovery of encrypted information." NAI has sent me e-mail stating that they might or might not remain in the KRA, that "PGP products will not be affected," and that they have "no interest in enabling key escrow for government access." Network Associates is presently listed on the KRA membership roster. "

Giving some actual theory to the whole cryptography discussion, Ian S. Nelson's review of Handbook of Applied Cryptography takes a look at this veritable tome of information. This isn't a book for those of you trying to figure out exactly what the NSA actually does; this is for the real meat and numbers behind it all. Click below for more info. Handbook of Applied Cryptography author Alfred J. Menezes, Paul C. van Oorschot, Scott A. Vanstone pages publisher CRC Press rating 9/10 reviewer Ian S. Nelson ISBN 0-8493-8523-7 summary Required reading for any cryptography freak. REVIEW: Handbook of Applied Cryptography Alfred J. Menezes, Paul C. van Oorschot, Scott A. Vanstone CRC Press (ISBN 0-8493-8523-7) Nutshell
Review: Required reading for any cryptography freak.
Rating: 9/10 The Scenario CRC Press has been building a series of books on discrete mathematics and its applications. Doug Stinson wrote the theory book on cryptography (Cryptography: Theory and Practice (ISBN: 0-8493-8521-0, if you don't like this book you'll vomit when you see the Stinson book) and this is the application book on cryptography. It's close to 800 pages chocked full of information.

I must confess that I'm a cryptography freak and I'm a little sick of the constant political discussions and lack of tech talk, this book is all tech and might even be a little much if you're not into math. It's a wonderful companion to the Schneier books (Applied Cryptography 1st or 2nd Edition A.K.A. "the crypto bible") if you're into the nitty gritty details of cryptography.

What's Bad? I really like this book and I can't find a lot that I don't like about it... but I think in places the math gets a little thick. I have a degree in math and I find myself returning to the math overview section more often than I'd like to admit. If you're not familiar with discrete math and combinatorics then this book probably isn't for you. If you enjoy that stuff, then this will be a piece of cake. If you're looking to build your crypto book library up I'd highly recommend this book before you get some of the more hard-core books.

Something else I feel is lacking is cryptanalysis on ciphers. They discuss attacks on various protocols and hashes but actual attacks on ciphers are glossed over. As a companion to Cryptography: Theory and Practice, which covers cryptanalysis in more detail, it is understandable to leave that material out of this book but I think they could discuss it a little more than they do without going into specifics.

The no-nonsense style can be a little dry at times, there aren't a lot of jokes or anecdotes to lighten things up in this book.

What's Good? Cipher isn't spelled with a 'y' anywhere in this book. It's not filled with a lot of opinion or rumor. It doesn't hardly bring up ITAR, key escrow, or the NSA's mystical superpowers. This book is about cryptographic techniques and a listing of patents is about as political or opinionated as it gets.

It is kind of like a textbook without the problems at the end of each chapter. It is written in an outline format with subitems of "Definition", "Fact", "Notes", "Example", and "Algorithm." Each subitem is followed by a few short but concise paragraphs of explanation.

Plenty of charts and figures fill the pages and everything is explained well. While it lacks source code, there is certainly enough information for you to implement any of the ciphers, hashes, or protocols covered. It even includes some test vectors for a lot of the algorithms.

So What's In It For Me? If you want to learn about cryptography, not the politics but the actual technology, then this is a great book to get before you get over your head. It's very readable and while the math can be a little heavy in places it is accessible and useful. It gives you a good flavor of how more advanced papers and books on the subject are and it avoids the nonacademic discussions surrounding cryptography.

To pick this book up, head over to Amazon and help Slashdot out.

Table of Contents

1. Overview of Cryptography
2. 1. Introduction
   2. Information Security and Cryptography
   3. Background on Functions
   4. Basic Terminology and Concepts
   5. Symmetric-key Encryption
   6. Digital Signatures
   7. Authentication and Identification
   8. Public-key Cryptography
   9. Hash Functions
   10. Protocols and mechanisms
   11. Key establishment, management, and certification
   12. Pseudorandom numbers and sequences
   13. Classes of attacks and security models
   14. Notes and further references
3. Mathematical Background
4. 1. Probability theory
   2. Information theory
   3. Complexity theory
   4. Number theory
   5. Abstract algebra
   6. Finite fields
   7. Notes and further references
5. Number-Theoretic Reference Problems
6. 1. Introduction and overview
   2. The integer factorization problem
   3. The RSA problem
   4. The quadratic residuosity problem
   5. Computing Square roots in Z _n
   6. The Discrete logarithm problem
   7. The Diffie-Hellman problem
   8. Composite moduli
   9. Computing individual bits
   10. The subset sum problem
   11. Factoring polynomials over finite fields
   12. Notes and further references
7. Public-Key Parameters
8. 1. Introduction
   2. Probabilistic primality tests
   3. (True)Primality tests
   4. Prime number generation
   5. Irreducible polynomials over Z _p
   6. Generators and elements of high order
   7. Notes and further references
9. Pseudorandom Bits and Sequences
10. 1. Introduction
    2. Random bit generation
    3. Pseudorandom bit generation
    4. Statistical tests
    5. Cryptographically secure pseudorandom bit generation
    6. Notes and further references
11. Stream Ciphers
12. 1. Introduction
    2. Feedback shift registers
    3. Stream ciphers based on LFSRs
    4. Other stream ciphers
    5. Notes and further references
13. Block Ciphers
14. 1. Introduction
    2. Background and general concepts
    3. Classical ciphers and historical development
    4. DES
    5. FEAL
    6. IDEA
    7. SAFER, RC5, and other block ciphers
    8. Notes and further references
15. Public-Key Encryption
16. 1. Introduction
    2. RSA public-key encryption
    3. Rabin public-key encryption
    4. ElGamal public-key encryption
    5. McElliece public-key encryption
    6. Knapsack public-key encryption
    7. Probabilistic public-key encryption
    8. Notes and further references
17. Hash Functions and Data Integrity
18. 1. Introduction
    2. Classification and framework
    3. Basic constructions and general results
    4. Unkeyed hash functions (MDCs)
    5. Keyed hash functions (MACs)
    6. Data integrity and message authentication
    7. Advanced attacks on hash functions
    8. Notes and further references
19. Identification and Entity Authentication
20. 1. Introduction
    2. Passwords (weak authentication)
    3. Challenge-response identification (strong authentication)
    4. Customized zero-knowledge identification protocols
    5. Attacks on identification protocols
    6. Notes and further references
21. Digital Signatures
22. 1. Introduction
    2. A framework for digital signature mechanisms
    3. RSA and related signature schemes
    4. Fiat-Shamir signature schemes
    5. The DSA and related signature schemes
    6. One-time digital signatures
    7. Other signatures schemes
    8. Signatures with additional functionality
    9. Notes and further references
23. Key Establishment Protocols
24. 1. Introduction
    2. Classification and framework
    3. Key transport based on symmetric encryption
    4. Key agreement based on symmetric techniques
    5. Key transport based on public-key encryption
    6. Key agreement based on asymmetric techniques
    7. Secret Sharing
    8. Conference Keying
    9. Analysis of key establishment protocols
    10. Notes and further references
25. Key Management Techniques
26. 1. Introduction
    2. Background and basic concepts
    3. Techniques for distributing confidential keys
    4. Techniques for distributing public keys
    5. Techniques for controlling key usage
    6. Key management involving multiple domains
    7. Key life cycle issues
    8. Advanced trusted third party services
    9. Notes and further references
27. Efficient Implementation
28. 1. Introduction
    2. Multiple-precision integer arithmetic
    3. Multiple-precision modular arithmetic
    4. Greatest common divisor algorithms
    5. Chinese remainder theorem for integers
    6. Exponentiation
    7. Exponent recoding
    8. Notes and further references
29. Patents and Standards
30. 1. Introduction
    2. Patents on cryptographic techniques
    3. Cryptographic standards
    4. Notes and further references
31. Appendix A: Bibligraphy of Papers from Selected Cryptographic Forums
32. 1. Asiacrypt/Auscrypt Proceedings
    2. Crypto Proceedings
    3. Eurocrypt Proceedings
    4. Fast Software Encryption Proceedings
    5. Journal of Cryptology papers

Jon Cochran writes "While looking around the net today, I found out that Casio is planning to release two new entry level PDAs. The catch? They're more expensive than the DaVinci Pro (which doesn't even exist yet), don't do email, and their screen resolution is smaller than the DaVinci. Do these have any compelling features to make them a good entry level PDA?"

Chops-Frozen-Water alerted us to the situation over at Salon. Apparently, after posting a story about the affair that Henry Hyde was supposed to have had, the result was a DOS attack. Andrew Leonard, the reporter, in question has written the article in an interesting fashion, only touching on the cause of the attack, but the talks about the potential for comptuer-related terrorism.

Chops-Frozen-Water writes "It was only a matter of time. At their developer forum, Intel demoed a prototype of a "home entertainment device" that has a transparent blue case. Story also mentions a Korean manufacturer that's working on a Celeron-based iMac lookalike. Whatever you think of the iMac, the design concept is going to be around for a while... "

Chops-Frozen-Water writes "Motorola's first effort at a set-top device , seems pretty loaded... More of a platform than a device, it has 3D gaming, DVD player, and Internet access in addition to your basic cable TV decoder. If they were to include a cable modem-type capability, I'd be in line already... "

Shlomi Fish has written up a piee on why Oracle and Java can't work together, but why Perl and Oracle will. It might be a language war type piece, but I don't really think it is. Both of these languages are really hot right now, and Shlomi does a great job explaining some of the reasons why. The following is a feature by Slashdot Reader Shlomi Fish Why Oracle for Java cannot Work (and why Oracle for Perl can work better)

Oracle Corp. recently announced that they are planning to release a version of their Database Server to run on Java. Despite Java's popularity and all the hype around it, is this really a good idea?

Java is converted into a machine-independent bytecode, and then interpreted or JIT-compiled by a system-dependent interpreter. Such interpreted languages have the advantage of running within their own virtual machine. Thus, they can hide such machine-code derived problems of buffer overflows or assigning values to the NULL pointer: in the worst case the interpreter will either trap the exception or exit with an error code, and will not cause any damage to the system. Furthermore, they can supply functionality to the programmer that is implemented by different APIs on different OSes enable him to release only one release for all of them.

It is no wonder that most knowledgeable users and administrators do most of their day-to-day programming in one or more of these languages. It not only reduces the time of development but lower problems in uploading the programs to the server or distributing them to the users. And of-course the various Assembly-level glitches are trapped by the interpreter, which makes it more secure in the first place. There is a performance cost naturally, but most systems are powerful enough as it is to handle it.

Java is one such technology, but is hardly the only one. Other such technologies include Perl, Python and Tcl/Tk. From what I know of Java's features as a computer language, it is my belief that it is not suitable as a basis for a full-featured object-oriented database server. If Oracle proceed with their plan, I predict that:

1. It will take a long time to develop, and consume Oracle of precious personnel and money.
2. Once released, it will be ignored by professional administrators.
3. Oracle will end up selling it to many end-users who will keep complaining, asking for constant support and demanding their money back.
4. It may even break Oracle, in a time when its financial status is in jeopardy anyhow.

It's not that I don't like Java. It's a cute language, but it's clearly a language for toys: small client-side or serve-side applets that do various simple tasks; configurable controllers for home appliances; various multimedia rich applications such as games, demos or educational programmers. Maybe even a sophisticated role-playing gaming system across the Internet based entirely on Java.

But an entire object-oriented relational database management system? For that matter is Java suitable for a powerful and configurable web-server that can rival Apache or Netscape's Enterprise Server? How about a cross-protocol messaging system like MS Exchange Server? Or a search-engine like Altavista or Excite? How about a system that can integrate various online services (e.g: web, mail, push technology, IRC, ICQ, FTP, usenet) with one consistent interactive content?

All the applications I mentioned do a lot of data and text processing. And with all due respect Java is not suitable for data and text processing. I can testify that both C++ (which is probably the language Oracle is written with at the moment) and perl version 5 are much better. Plus, perl 5 is much handier than C++, and has some advantages of being an interpreted language running on top of its own virtual machine.

In Java a two-dimensional array has to be initialized with the following statements:

int array[][] = new int [] [10];
for(int a=0;a<10;a++)
{
    array[a] = new int [10];
}

And if I later need to resize it beyond the 10*10 boundary... oh well. In Perl any array can have an unlimited number of dimensions and an item can be written at any coordinates. For example:

my (@array);
$array[100000][5000][87778787] = 3;

is a perfectly legal perl statement. It is very possible to write a short non-recursive function in perl that can duplicate a complex hierarchial data-structure, containing giga-bytes of information. To duplicate a Java object, I need to assign each one of its members separately. The Java statement "MyClass New = Old" will result in two references to the same physical object.

In Java, the most common data structures like a stack, a queue, or an associative array lie somewhere under the java.lang package and have names like java.lang.Stack or java.lang.Deque. Furthermore, they can only handle the most generic data-type: Object. This means that Oracle Programmers will have to implement their version of these containing either more basic data-types (such as the various integers) or derived classes of Object that will not require them to do the sub-classing all the time. After all, how much can one do with a reference to Object?

A standard perl array on the other hand can serve as a stack, queue or deque as well as a standard vector, and one can join them or retrieve selected items and ranges of it by using the built-in perl operators and functions. Perl5 hashes can serve as associative arrays, classes, as base for binary-trees, and many other uses. A perl scalar cannot only be a buffer whose size is limited only by the perl interpreter, but a reference to all other perl data-types. And its behaviour is transparent for the programmer.

I did not do an expert research on object-oriented databases, but from what I've heard each database can contain, besides tables, several other databases and a record can contain a table within one of its fields. Are the end-users who would like to script the server with Java are going to see a database as an object that contains an array of Objects or com.ORACLE.whatever.BasicDBClass's which have to be subclassed into com.ORACLE.whatever.Table's and com.ORACLE.whatever.Database's?

A basic Perl data structure can be "tied" into objects and a list of parameters, which can enable the programmers and end-users to think of a record as a simple hash, which is the natural way to think of it, in my opinion. And a RDB table would simply be an array of such hashes. For instance, to increment the values of the field myfield in the table mytable by 1, one would have to write the following code in Java:

Int ref;
for(int a=0;a<mytable.getRecordsNum();a++)
{
    ref = (Int)(mytable.getRecord(a).getField("myfield"));
    ref.fromInt(ref.toInt()+1);
}

And in perl:

foreach $r ($mytable->@records)
{
    $r->{"myfield"}++;
}

I wonder what will be easier to understand. Java's object-oriented programming is based on the Smalltalk school of OOP and is very restrictive: objects can only be single-inherited, operators cannot be overloaded, no pointers to methods, strict data-typing etc. Perl 5 has much more flexible OOP capabilites, and for a large-scale project such as modern RDBMS, I believe both its programmers and the users who will want to script it will appreciate it. Perl also has some advantages over C++ in that field. For instance, one can add member items and methods to objects at run time, since they are represented internally by hashes.

Java's I/O mechanism is quite awkward with names such as FileInputStream, BufferedOutputStream, or ServerSocket for some of the most basic I/O operations. Perl uses simple global functions like "open", "print", "pipe", "socket", or "print", and can do some complex I/O operations with a few statements. And an RDB server requires a lot of I/O.

If Oracle for Java comes out, I will not even want to try it. For once, I know it's going to be a super-complex hierarchy of classes and interfaces that will be a mess for Oracle's newly-recruited programmers to make sense of, much less keep up to date. Even if its first version works, I know that at a certain point, it will break under pressure and the code will fall to pieces. So, I'd rather not rely on a Java based RDBMS in the first place.

Secondly, I don't know if I will be able to script the damn thing without losing my mind. With all due respect, Java per-se is not a good scripting language, while perl is perhaps the best scripting language on the planet.

The Java technology is not in a stable state now. There are already 3 major versions of the JDK and many APIs are constantly changed, or even lack a proper specification. Almost all Java run-time environments are problematic and unstable, and most web-browsers ship only with JDK 1.0.2. Java micro-controllers may help solve this problem, but it will take some years before they are integrated into future much less existing systems. Chances are that end-users will try the Java DBMS out, see that it isn't stable or fast enough, and give up immediately.

On the other hand, if I'll hear that a serious OO RDBMS based on Perl is due to arrive I will be eagerly waiting to try it out, and I believe most people who used UNIX recently will say the same. Perl5 is an amazing language, with superb system-integration, extensibility and embeddebility, AI-like features, a good security mechanism and on top of all a nice C-like syntax.

Oracle for Perl will be able to act as its own multiplexer, de-multiplexer and middleware. One will be able to program it to read, write and transceive data to other resources on the network. It will be able to act as its own RAD. UNIX users write Perl scripts that perform complex and simple data manipulation, even with simple flat-file records, and if the perl programmer will be able to access a state-of-the-art database engine and SQL interface at the tip of his hands: the sky is the limit.

When I joined the Java Developers Connection some weeks ago, my registration was handled by a script ending with the ".pl" extension - a clear indication that it was a perl script. If the webmasters of JavaSofts' website preferred to a perl script over a Java servlet for the simple database-related task of registering a new developer entry, then how can anyone except an entire database server to be programmed and maintained with Java?

I realize that many newbies believe Java to be "the language of the future" and will say "for what?" if they hear of Oracle/Informix/OpenIngres/etc. for Perl. Still, I believe those vendors can make enough money of their databases by selling them to more experienced developers, administrators and users who are familiar with the perl technology. After the newbies will hear from them how great it is, they will want to try it too.

It is my belief that no single computer language is suitable for all purposes, especially Java with its so many inherent restrictions. And the way I see it, if Oracle is looking for a cross-platform language to run a server on, perl, not Java, should be their choice.

Shlomi Fish has written up a piee on why Oracle and Java can't work together, but why Perl and Oracle will. It might be a language war type piece, but I don't really think it is. Both of these languages are really hot right now, and Shlomi does a great job explaining some of the reasons why. The following is a feature by Slashdot Reader Shlomi Fish Why Oracle for Java cannot Work (and why Oracle for Perl can work better)

Oracle Corp. recently announced that they are planning to release a version of their Database Server to run on Java. Despite Java's popularity and all the hype around it, is this really a good idea?

Java is converted into a machine-independent bytecode, and then interpreted or JIT-compiled by a system-dependent interpreter. Such interpreted languages have the advantage of running within their own virtual machine. Thus, they can hide such machine-code derived problems of buffer overflows or assigning values to the NULL pointer: in the worst case the interpreter will either trap the exception or exit with an error code, and will not cause any damage to the system. Furthermore, they can supply functionality to the programmer that is implemented by different APIs on different OSes enable him to release only one release for all of them.

It is no wonder that most knowledgeable users and administrators do most of their day-to-day programming in one or more of these languages. It not only reduces the time of development but lower problems in uploading the programs to the server or distributing them to the users. And of-course the various Assembly-level glitches are trapped by the interpreter, which makes it more secure in the first place. There is a performance cost naturally, but most systems are powerful enough as it is to handle it.

Java is one such technology, but is hardly the only one. Other such technologies include Perl, Python and Tcl/Tk. From what I know of Java's features as a computer language, it is my belief that it is not suitable as a basis for a full-featured object-oriented database server. If Oracle proceed with their plan, I predict that:

1. It will take a long time to develop, and consume Oracle of precious personnel and money.
2. Once released, it will be ignored by professional administrators.
3. Oracle will end up selling it to many end-users who will keep complaining, asking for constant support and demanding their money back.
4. It may even break Oracle, in a time when its financial status is in jeopardy anyhow.

It's not that I don't like Java. It's a cute language, but it's clearly a language for toys: small client-side or serve-side applets that do various simple tasks; configurable controllers for home appliances; various multimedia rich applications such as games, demos or educational programmers. Maybe even a sophisticated role-playing gaming system across the Internet based entirely on Java.

But an entire object-oriented relational database management system? For that matter is Java suitable for a powerful and configurable web-server that can rival Apache or Netscape's Enterprise Server? How about a cross-protocol messaging system like MS Exchange Server? Or a search-engine like Altavista or Excite? How about a system that can integrate various online services (e.g: web, mail, push technology, IRC, ICQ, FTP, usenet) with one consistent interactive content?

All the applications I mentioned do a lot of data and text processing. And with all due respect Java is not suitable for data and text processing. I can testify that both C++ (which is probably the language Oracle is written with at the moment) and perl version 5 are much better. Plus, perl 5 is much handier than C++, and has some advantages of being an interpreted language running on top of its own virtual machine.

In Java a two-dimensional array has to be initialized with the following statements:

int array[][] = new int [] [10];
for(int a=0;a<10;a++)
{
    array[a] = new int [10];
}

And if I later need to resize it beyond the 10*10 boundary... oh well. In Perl any array can have an unlimited number of dimensions and an item can be written at any coordinates. For example:

my (@array);
$array[100000][5000][87778787] = 3;

is a perfectly legal perl statement. It is very possible to write a short non-recursive function in perl that can duplicate a complex hierarchial data-structure, containing giga-bytes of information. To duplicate a Java object, I need to assign each one of its members separately. The Java statement "MyClass New = Old" will result in two references to the same physical object.

In Java, the most common data structures like a stack, a queue, or an associative array lie somewhere under the java.lang package and have names like java.lang.Stack or java.lang.Deque. Furthermore, they can only handle the most generic data-type: Object. This means that Oracle Programmers will have to implement their version of these containing either more basic data-types (such as the various integers) or derived classes of Object that will not require them to do the sub-classing all the time. After all, how much can one do with a reference to Object?

A standard perl array on the other hand can serve as a stack, queue or deque as well as a standard vector, and one can join them or retrieve selected items and ranges of it by using the built-in perl operators and functions. Perl5 hashes can serve as associative arrays, classes, as base for binary-trees, and many other uses. A perl scalar cannot only be a buffer whose size is limited only by the perl interpreter, but a reference to all other perl data-types. And its behaviour is transparent for the programmer.

I did not do an expert research on object-oriented databases, but from what I've heard each database can contain, besides tables, several other databases and a record can contain a table within one of its fields. Are the end-users who would like to script the server with Java are going to see a database as an object that contains an array of Objects or com.ORACLE.whatever.BasicDBClass's which have to be subclassed into com.ORACLE.whatever.Table's and com.ORACLE.whatever.Database's?

A basic Perl data structure can be "tied" into objects and a list of parameters, which can enable the programmers and end-users to think of a record as a simple hash, which is the natural way to think of it, in my opinion. And a RDB table would simply be an array of such hashes. For instance, to increment the values of the field myfield in the table mytable by 1, one would have to write the following code in Java:

Int ref;
for(int a=0;a<mytable.getRecordsNum();a++)
{
    ref = (Int)(mytable.getRecord(a).getField("myfield"));
    ref.fromInt(ref.toInt()+1);
}

And in perl:

foreach $r ($mytable->@records)
{
    $r->{"myfield"}++;
}

I wonder what will be easier to understand. Java's object-oriented programming is based on the Smalltalk school of OOP and is very restrictive: objects can only be single-inherited, operators cannot be overloaded, no pointers to methods, strict data-typing etc. Perl 5 has much more flexible OOP capabilites, and for a large-scale project such as modern RDBMS, I believe both its programmers and the users who will want to script it will appreciate it. Perl also has some advantages over C++ in that field. For instance, one can add member items and methods to objects at run time, since they are represented internally by hashes.

Java's I/O mechanism is quite awkward with names such as FileInputStream, BufferedOutputStream, or ServerSocket for some of the most basic I/O operations. Perl uses simple global functions like "open", "print", "pipe", "socket", or "print", and can do some complex I/O operations with a few statements. And an RDB server requires a lot of I/O.

If Oracle for Java comes out, I will not even want to try it. For once, I know it's going to be a super-complex hierarchy of classes and interfaces that will be a mess for Oracle's newly-recruited programmers to make sense of, much less keep up to date. Even if its first version works, I know that at a certain point, it will break under pressure and the code will fall to pieces. So, I'd rather not rely on a Java based RDBMS in the first place.

Secondly, I don't know if I will be able to script the damn thing without losing my mind. With all due respect, Java per-se is not a good scripting language, while perl is perhaps the best scripting language on the planet.

The Java technology is not in a stable state now. There are already 3 major versions of the JDK and many APIs are constantly changed, or even lack a proper specification. Almost all Java run-time environments are problematic and unstable, and most web-browsers ship only with JDK 1.0.2. Java micro-controllers may help solve this problem, but it will take some years before they are integrated into future much less existing systems. Chances are that end-users will try the Java DBMS out, see that it isn't stable or fast enough, and give up immediately.

On the other hand, if I'll hear that a serious OO RDBMS based on Perl is due to arrive I will be eagerly waiting to try it out, and I believe most people who used UNIX recently will say the same. Perl5 is an amazing language, with superb system-integration, extensibility and embeddebility, AI-like features, a good security mechanism and on top of all a nice C-like syntax.

Oracle for Perl will be able to act as its own multiplexer, de-multiplexer and middleware. One will be able to program it to read, write and transceive data to other resources on the network. It will be able to act as its own RAD. UNIX users write Perl scripts that perform complex and simple data manipulation, even with simple flat-file records, and if the perl programmer will be able to access a state-of-the-art database engine and SQL interface at the tip of his hands: the sky is the limit.

When I joined the Java Developers Connection some weeks ago, my registration was handled by a script ending with the ".pl" extension - a clear indication that it was a perl script. If the webmasters of JavaSofts' website preferred to a perl script over a Java servlet for the simple database-related task of registering a new developer entry, then how can anyone except an entire database server to be programmed and maintained with Java?

I realize that many newbies believe Java to be "the language of the future" and will say "for what?" if they hear of Oracle/Informix/OpenIngres/etc. for Perl. Still, I believe those vendors can make enough money of their databases by selling them to more experienced developers, administrators and users who are familiar with the perl technology. After the newbies will hear from them how great it is, they will want to try it too.

It is my belief that no single computer language is suitable for all purposes, especially Java with its so many inherent restrictions. And the way I see it, if Oracle is looking for a cross-platform language to run a server on, perl, not Java, should be their choice.

Jeremy Arnold has written an essay on what he calls LUTE- the Linux Usability Testing and Evaluation project. It could help make programs more usable by organizing volunteers to test software and clean things up. Far to often great programmers aren't the best at creating the ideal user interface. Perhaps this project could put people who understand the human factors in touch with the guys who write the killer code. Hit the link below to read it and throw in your 2 bits. The following was written by Slashdot reader Jeremy Arnold The LUTE Project Linux Usability Testing and Evaluation Last week on Slashdot an article was posted about an essay on user interface design. As a comment to that article I brought forth an idea for a group of people who would do usability testing for Open Source Linux projects. The response to the idea was generally positive, so I have now prepared this more formal proposal. If I can find a place to host web pages and a mailing list and Slashdot readers agree there is a need for this group and some are willing to volunteer their time to be part of it, the Lute project should be running shortly.

What is the Lute project? LUTE stands for "Linux Usability Testing and Evaluation". A bit redundant, but I like acronyms that form words. :) Usability testing is the process of testing the user interface for a piece of software to make sure that it makes sense to the user. "Makes sense" refers to the interface being intuitive and consistent, and generally that the user interface helps the user rather than frustrating them. Note that there is a difference between "usability testing" and just plain "testing". Lute does not exist to find bugs in software. The purpose is to find flaws in the user interface.

Most commercial software development includes a usability testing phase, and the most usable software generally includes usability testing throughout the development cycle. Large software development companies usually have a "usability testing lab" with lots of (somewhat) fancy equipment to aid them in this testing. This, of course, translates to money, which most open source projects do not have. Usability testing can be performed (though somewhat less effectively) with no special equipment, but it is an area which many open source developers are unfamiliar with, and most do not take the time to do it.

As Linux becomes more accepted in the commercial world and starts to be used by more "common users" rather than the traditional hacker types, software usability will become more and more important.

The Lute project is an attempt to address these issues by performing usability testing for open source projects. This testing will be performed for free by Lute volunteers. On the web, Lute will also serve as an information center for good user interface design as well as techniques for usability testing and evaluation.

Lute will not force developers to use certain toolkits (such as KDE/Qt or Gnome/GTK). In fact, when testing a program, Lute volunteers won't even be looking at the source code. In addition, Lute will not enforce strict standards (like forcing you to use 5 pixels between buttons and 10 point bold Helvetica font for menu text). Upon completing testing, the Lute volunteer wil l give an evaluation back to the developer about what aspects of the interface work well, and, more importantly, what aspects don't work well. The evaluator will also try to give the developer ideas on how to improve these aspects. It is up to the developer to choose whether or not to implement these changes, and how to do it.

How will Lute work? These details are subject to change, but this is how I envision Lute working. The developer will submit a request for an evaluation of his/her project. (Of course, most open source projects have multiple developers. In this case, one developer would act as the liaison to Lute.) This request will include a short description of the program, a list of features to be tested (sometimes this will be the whole program, other times just a few features may need to be tested), and a developer contact (email address).

Once a request has been submitted, it will probably be appended to a web page list of pending projects and sent out on a Lute mailing list. Lute evaluators can then choose to accept the project. The evaluator will write up a list of tasks to use for the test. These tasks are the things that the user will perform in order to give the evaluator a good feel for what works well and what doesn't. After preparing this task list, the evaluator will discuss it with the developer to make sure that the developer thinks it adequately covers the expected uses of the program. The evaluator would then find about 3 "average users" to test the program with, and report back to the developer with the findings.

Note that the definition of an "average user" could be a bit different for each project. For example, the average user of a programming IDE would be a programmer, while the average user of a web browser might be the evaluator's mother. Also note that the average users will generally be somebody the evaluator knows, and they must be able to meet in person to perform the evaluation. (If you disagree with this condition, go read some articles/books on usability testing and then post an informed comment here.)

This "formal testing" process could take a bit of time, and is probably overkill at times, especially when usability testing is performed regularly throughout the development cycle. In this case, a full formal test should certainly be performed from time to time, but at other times the developer might just need an "expert opinion" about how the usability of an application could be improved. For this, the developer might put in a request for an "expert opinion" (or perhaps this should be "somewhat informed opinion"), at which time a Lute evaluator could volunteer for the project and then look at the program and make recommendations based on their prior experience with and knowledge of user interface design and testing. Note that this is a supplement to the formal testing, and not a replacement. The formal testing can be much more effective; it just takes a bit more time and effort to do.

What roles are involved? Here is a description of the various roles which need to be fulfilled for this to work:

• Project Maintainer

  I am currently this person. I will be in charge of setting up the infrastructure for the project, including things like web pages and mailing lists. I will also be in charge of facilitating communication between Lute volunteers, and make the final decisions in policy matters. Most open source projects have some type of "benevolent dictator". Lute's "Project Maintainer" is the same type of thing.

  In case somebody cares, I am Jeremy Arnold (jeremy_a@bigfoot.com). Last spring I graduated from Utah State University with a bachelor's degree in Computer Science, and I now work as a Java Performance tester for IBM. I have little formal experience with user interface design, and my usability testing experience consists of about a week doing usability testing on a program I developed during a summer internship. I certainly don't claim to be an expert in this area, but it is something I find very interesting and in many ways it comes naturally to me. I have been a Linux user for about 4 years now, although I have never really (previously) taken a very active part in the Linux development community.

• Evaluator

  These are the people who will do most of the real work for Lute. They will then volunteer to evaluate the programs submitted by the developers, and report their findings back to the developer.

  While I don't expect the evaluators to have years of experience in usability testing, they will be required to have at least some knowledge in the area. At a minimum, this will probably mean they have to read some on-line information about it, and perhaps for their first project or two a more experienced evaluator will also evaluate the program and then give some feedback to the new evaluator about any areas they might be able to improve in. This is not meant to scare off people who would like to help; I just feel it is necessary in order to provide quality feedback to developers and not lose credibility for Lute. Anybody who has done some work with user interface design and knows the challenges involved could probably pick up the necessary knowledge to be an evaluator pretty quickly.

• Developer

  Developers are, of course, the people who are developing open source projects. More specifically, they are the ones developing open source projects with user interfaces. This does not necessarily mean graphical user interfaces, although most programs evaluated by Lute probably will have GUIs. Any program that interacts with the user has some kind of user interface, and can be evaluated by Lute.

  Lute will only evaluate programs at the request of a developer. The programs to be evaluated must be open source (as a matter of principle....I am not against closed source development for some projects, but Lute is really designed to help open source developers) and freely available (if the developers are charging users for their product, then they can afford to pay somebody for usability testing). I refuse to get into a debate about whether or not KDE is really free, but programs written using KDE/Qt fit the definition of free used in this paragraph, and are eligible for Lute evaluation.

  Lute will encourage (and perhaps require) the developer to read some general information on user interface design before we will evaluate their program. This is simply because it is a waste of time for us to evaluate a program that has no consideration for well-known design principles and then report on all the ways their program violates these principles. Any required reading will be as short as possible.

  Programs to be evaluated must have a reasonably functional interface. It is best to evaluate the user interface of a program before it is completed, so that the framework can be fixed before a lot of code is developed over it. However, even if the program is not complete, the user interface must be functional. If your program has a button labeled "Find a cure for cancer and generate world peace" (not necessarily a good name for a button), it doesn't have to actually find a cure for cancer and generate world peace, but if I press that button it should pop up a window that says that the cancer-curing peace-generating functionality is not implemented, rather than just sitting there or crashing the program or something.

• Average User

  The evaluator will test the program by observing average people use the program (performing the list of tasks given by the observer). These users are very important, as they can show the evaluator the types of difficulties that most people will have when using the program.

  Average users are not direct volunteers to Lute as the evaluators are. This is because evaluators need to be able to watch the users as they run the program, which means they must be geographically near the person. Because of this, evaluators will generally find average users among the people around them. Luckily, average computer users are pretty abundant in the world, so this shouldn't be a problem.

  Besides the need for geographical proximity, volunteers to be average users would not be desirable. If a person is an "average user" for 50 usability tests, they are no longer average. That person should consider becoming an evaluator.

• Web page/mailing list host

  As mentioned far above, the Lute project is also in need of somebody to host the needed web pages and mailing list(s). If the project becomes popular, I could afford to get a permanent connection to the Internet and use my machine as the host, but I would rather not spend that money until the project gets moving and looks like it is going to succeed. CGI (or perhaps Java servlets?) access on the web host would be really helpful, as I hope to get much of the process of submitting requests for evaluation and stuff automated. Even if the project does become quite popular, I wouldn't expect the mailing list to be extremely high volume or the web pages to need high bandwidth (except of course if the URL was posted on Slashdot).

Comments? Questions? Suggestions? Post them here, and I will try to answer them. A lot of the details remain to be decided, most likely once there is a team of Lute evaluators. Note that all of the policy and procedure stuff in this article is not set in stone. It is just my thoughts on how things would work best. Like I said, I don't claim to be an expert, and it is quite possible (and even likely) that things could be done better.

"I want to help. What do I do?" I'm glad you would like to help. If you would like to be a Lute volunteer as an evaluator, web/mailing list host, send me email (jeremy_a@bigfoot.com) and let me know. Personal replies are unlikely for evaluators, but I will let you know once the mailing list is set up.

Jeremy Arnold has written an essay on what he calls LUTE- the Linux Usability Testing and Evaluation project. It could help make programs more usable by organizing volunteers to test software and clean things up. Far to often great programmers aren't the best at creating the ideal user interface. Perhaps this project could put people who understand the human factors in touch with the guys who write the killer code. Hit the link below to read it and throw in your 2 bits. The following was written by Slashdot reader Jeremy Arnold The LUTE Project Linux Usability Testing and Evaluation Last week on Slashdot an article was posted about an essay on user interface design. As a comment to that article I brought forth an idea for a group of people who would do usability testing for Open Source Linux projects. The response to the idea was generally positive, so I have now prepared this more formal proposal. If I can find a place to host web pages and a mailing list and Slashdot readers agree there is a need for this group and some are willing to volunteer their time to be part of it, the Lute project should be running shortly.

What is the Lute project? LUTE stands for "Linux Usability Testing and Evaluation". A bit redundant, but I like acronyms that form words. :) Usability testing is the process of testing the user interface for a piece of software to make sure that it makes sense to the user. "Makes sense" refers to the interface being intuitive and consistent, and generally that the user interface helps the user rather than frustrating them. Note that there is a difference between "usability testing" and just plain "testing". Lute does not exist to find bugs in software. The purpose is to find flaws in the user interface.

Most commercial software development includes a usability testing phase, and the most usable software generally includes usability testing throughout the development cycle. Large software development companies usually have a "usability testing lab" with lots of (somewhat) fancy equipment to aid them in this testing. This, of course, translates to money, which most open source projects do not have. Usability testing can be performed (though somewhat less effectively) with no special equipment, but it is an area which many open source developers are unfamiliar with, and most do not take the time to do it.

As Linux becomes more accepted in the commercial world and starts to be used by more "common users" rather than the traditional hacker types, software usability will become more and more important.

The Lute project is an attempt to address these issues by performing usability testing for open source projects. This testing will be performed for free by Lute volunteers. On the web, Lute will also serve as an information center for good user interface design as well as techniques for usability testing and evaluation.

Lute will not force developers to use certain toolkits (such as KDE/Qt or Gnome/GTK). In fact, when testing a program, Lute volunteers won't even be looking at the source code. In addition, Lute will not enforce strict standards (like forcing you to use 5 pixels between buttons and 10 point bold Helvetica font for menu text). Upon completing testing, the Lute volunteer wil l give an evaluation back to the developer about what aspects of the interface work well, and, more importantly, what aspects don't work well. The evaluator will also try to give the developer ideas on how to improve these aspects. It is up to the developer to choose whether or not to implement these changes, and how to do it.

How will Lute work? These details are subject to change, but this is how I envision Lute working. The developer will submit a request for an evaluation of his/her project. (Of course, most open source projects have multiple developers. In this case, one developer would act as the liaison to Lute.) This request will include a short description of the program, a list of features to be tested (sometimes this will be the whole program, other times just a few features may need to be tested), and a developer contact (email address).

Once a request has been submitted, it will probably be appended to a web page list of pending projects and sent out on a Lute mailing list. Lute evaluators can then choose to accept the project. The evaluator will write up a list of tasks to use for the test. These tasks are the things that the user will perform in order to give the evaluator a good feel for what works well and what doesn't. After preparing this task list, the evaluator will discuss it with the developer to make sure that the developer thinks it adequately covers the expected uses of the program. The evaluator would then find about 3 "average users" to test the program with, and report back to the developer with the findings.

Note that the definition of an "average user" could be a bit different for each project. For example, the average user of a programming IDE would be a programmer, while the average user of a web browser might be the evaluator's mother. Also note that the average users will generally be somebody the evaluator knows, and they must be able to meet in person to perform the evaluation. (If you disagree with this condition, go read some articles/books on usability testing and then post an informed comment here.)

This "formal testing" process could take a bit of time, and is probably overkill at times, especially when usability testing is performed regularly throughout the development cycle. In this case, a full formal test should certainly be performed from time to time, but at other times the developer might just need an "expert opinion" about how the usability of an application could be improved. For this, the developer might put in a request for an "expert opinion" (or perhaps this should be "somewhat informed opinion"), at which time a Lute evaluator could volunteer for the project and then look at the program and make recommendations based on their prior experience with and knowledge of user interface design and testing. Note that this is a supplement to the formal testing, and not a replacement. The formal testing can be much more effective; it just takes a bit more time and effort to do.

What roles are involved? Here is a description of the various roles which need to be fulfilled for this to work:

• Project Maintainer

  I am currently this person. I will be in charge of setting up the infrastructure for the project, including things like web pages and mailing lists. I will also be in charge of facilitating communication between Lute volunteers, and make the final decisions in policy matters. Most open source projects have some type of "benevolent dictator". Lute's "Project Maintainer" is the same type of thing.

  In case somebody cares, I am Jeremy Arnold (jeremy_a@bigfoot.com). Last spring I graduated from Utah State University with a bachelor's degree in Computer Science, and I now work as a Java Performance tester for IBM. I have little formal experience with user interface design, and my usability testing experience consists of about a week doing usability testing on a program I developed during a summer internship. I certainly don't claim to be an expert in this area, but it is something I find very interesting and in many ways it comes naturally to me. I have been a Linux user for about 4 years now, although I have never really (previously) taken a very active part in the Linux development community.

• Evaluator

  These are the people who will do most of the real work for Lute. They will then volunteer to evaluate the programs submitted by the developers, and report their findings back to the developer.

  While I don't expect the evaluators to have years of experience in usability testing, they will be required to have at least some knowledge in the area. At a minimum, this will probably mean they have to read some on-line information about it, and perhaps for their first project or two a more experienced evaluator will also evaluate the program and then give some feedback to the new evaluator about any areas they might be able to improve in. This is not meant to scare off people who would like to help; I just feel it is necessary in order to provide quality feedback to developers and not lose credibility for Lute. Anybody who has done some work with user interface design and knows the challenges involved could probably pick up the necessary knowledge to be an evaluator pretty quickly.

• Developer

  Developers are, of course, the people who are developing open source projects. More specifically, they are the ones developing open source projects with user interfaces. This does not necessarily mean graphical user interfaces, although most programs evaluated by Lute probably will have GUIs. Any program that interacts with the user has some kind of user interface, and can be evaluated by Lute.

  Lute will only evaluate programs at the request of a developer. The programs to be evaluated must be open source (as a matter of principle....I am not against closed source development for some projects, but Lute is really designed to help open source developers) and freely available (if the developers are charging users for their product, then they can afford to pay somebody for usability testing). I refuse to get into a debate about whether or not KDE is really free, but programs written using KDE/Qt fit the definition of free used in this paragraph, and are eligible for Lute evaluation.

  Lute will encourage (and perhaps require) the developer to read some general information on user interface design before we will evaluate their program. This is simply because it is a waste of time for us to evaluate a program that has no consideration for well-known design principles and then report on all the ways their program violates these principles. Any required reading will be as short as possible.

  Programs to be evaluated must have a reasonably functional interface. It is best to evaluate the user interface of a program before it is completed, so that the framework can be fixed before a lot of code is developed over it. However, even if the program is not complete, the user interface must be functional. If your program has a button labeled "Find a cure for cancer and generate world peace" (not necessarily a good name for a button), it doesn't have to actually find a cure for cancer and generate world peace, but if I press that button it should pop up a window that says that the cancer-curing peace-generating functionality is not implemented, rather than just sitting there or crashing the program or something.

• Average User

  The evaluator will test the program by observing average people use the program (performing the list of tasks given by the observer). These users are very important, as they can show the evaluator the types of difficulties that most people will have when using the program.

  Average users are not direct volunteers to Lute as the evaluators are. This is because evaluators need to be able to watch the users as they run the program, which means they must be geographically near the person. Because of this, evaluators will generally find average users among the people around them. Luckily, average computer users are pretty abundant in the world, so this shouldn't be a problem.

  Besides the need for geographical proximity, volunteers to be average users would not be desirable. If a person is an "average user" for 50 usability tests, they are no longer average. That person should consider becoming an evaluator.

• Web page/mailing list host

  As mentioned far above, the Lute project is also in need of somebody to host the needed web pages and mailing list(s). If the project becomes popular, I could afford to get a permanent connection to the Internet and use my machine as the host, but I would rather not spend that money until the project gets moving and looks like it is going to succeed. CGI (or perhaps Java servlets?) access on the web host would be really helpful, as I hope to get much of the process of submitting requests for evaluation and stuff automated. Even if the project does become quite popular, I wouldn't expect the mailing list to be extremely high volume or the web pages to need high bandwidth (except of course if the URL was posted on Slashdot).

Comments? Questions? Suggestions? Post them here, and I will try to answer them. A lot of the details remain to be decided, most likely once there is a team of Lute evaluators. Note that all of the policy and procedure stuff in this article is not set in stone. It is just my thoughts on how things would work best. Like I said, I don't claim to be an expert, and it is quite possible (and even likely) that things could be done better.

"I want to help. What do I do?" I'm glad you would like to help. If you would like to be a Lute volunteer as an evaluator, web/mailing list host, send me email (jeremy_a@bigfoot.com) and let me know. Personal replies are unlikely for evaluators, but I will let you know once the mailing list is set up.

Chops-Frozen-Water sent us a little story that appeared in BusinessWeek about the Back Orifice fun'n'games. And as, Chops says, it is written in layman's terms so even the pointy-haired bosses can understand it.

Mercutio writes "This story Seems to indicate that Dell is preparing to move its Linux installation program to a global, rather than purely European market. " The informal program seems to be working well enough that Dell execs are considering making Linux an official supported OS across the pond." Dell supporting Linux?" Update an anonymous Dell employee wrote in to say that the Performance Computing article is in error, as Dell does not do SCO, but instead DellWare (described as "Like CompUSA, but with Dell's name on it"). And this all sounded so good.

Michael Heldebrant writes "New OS upgrades for Palm Pilots: 3.0.1 and 2.0.5 downloadable at PilotGear and officially from Palmpilot.com. changelist is on the html pages, mostly PPP fixes. " Possibly even more interesting is a story that Yoz sent us. He says. "Cool news for people wanting to do serious DB stuff for everyone's favourite PDA... it's only 150k, there's a Java API to it, and it'll be out within the next couple of weeks."

Itamar S.-T. writes " A wearable computer that can run Linux. For rich geeks only, though: "The two-pound computer, half the weight of a laptop computer, can be voice-activated and is just twice the size of a typical mobile telephone. It will retail for less than $5,000, Newman said. The mobile device, which with a 233 megahertz Pentium chip is more powerful than most office desktop personal computers, runs standard operating systems such as Microsoft Windows or Unix. Users can make telephone calls, send faxes, and access the Internet, Newman said. The computer display will come in a variety of head-worn technology, such as visors, or it can be plugged into a standard monitor." "

Fedor Kouranov wrote in with this article where Computer Shopper columnist Paul Bonner rips Netscape apart for their source code decision. I don't disagree that IE4 is extendable- all MS projects are great at this, but he blows of Netscape and just accepts that Microsoft owns the industry. Personally I prefer thinking of a future that's open instead of held inside the walls of some mega corporation is a little better than one where Microsoft over powers each new industry as it appears, but hey, I'm an optimist.

Itamar S.-T. let us know that PalmPC.com has been registered by 3com and is up and running. Next is this articleabout the new P3's sent in by David Cloud. Last Drew Daniels sent in this hotwired article and This ZDNet article.

Another entertaining use of the internet is now available- a company is selling photographs taken from satellites of anywhere in the world. Resolution is 10sq/ft per pixel, and it costs a few hundred bucks a pixel, but it's only money, right?

The article also talks about using cel phones as a homing device. Crazy stuff. check out the story sent to us by Garrett