Why aren't there more rendering engines?
on
Galeon 1.0 Released
·
· Score: 1
HTML is not such a complicated standard, it's well documented now, and there are lots of HTML parsers available. Why aren't there more full HTML rendering engines besides Mozilla, IE, and KHTML? And why is Mozilla so big? Even if the Galeon front end is pretty light, it still uses the same rendering engine.
(BTW, I find Galeon has been getting less stable for me: downloads have started to fail, it crashes with some frequency when exiting, etc. I hope 1.0 will fix that.)
look at wxWindows and other toolkits
on
GTK-- vs. QT
·
· Score: 1
There are several other cross-platform toolkits out there, some free and some commercial. wxWindows is quite good, uses Gtk+ on Linux, and has a very Windows-like feel to it when programming. It also now comes in a very lightweight "universal" flavor and will probably come in an embedded version soon. (I kind of view wxWindows as the "real" Gtk--.) wxWindows also comes with nice cross-platform non-GUI libraries (networking, image handling, etc.), as well as platform specific classes for things like ActiveX on Windows, classes that you can use conditionally to make your application behave more like a native app.
FLTK is very lightweight and easy to use. It is used extensively on handheld Linux devices. FLTK1 lacks some functionality that you may need, but FLTK2 is shaping up to be quite complete.
Also, Qt is not the only game in town for commercial toolkits. If you want something commercial, look around. In the past, other commercial toolkits had much better tool support than Qt.
Yes, and Qt applications is all that handheld is going to run because TrollTech's proprietary toolkit takes over the entire screen and cannot share it with other, non-Qt applications.
If you want a nifty handheld with a proprietary toolkit, there are lots of WindowsCE devices out there. And developing for WindowsCE is cheaper than developing for Qt.
The whole idea behind top down design and modular programming is that you're breaking software down into small pieces that perform a single task. If you know each module performs its task and only its task and does it properly, the software won't crash!
Oh, my gosh! You got the solution! The silver bullet! Tens of thousands of computer scientists and engineers have worked on this for decades and not come up with a solution. But you found the answer. Brilliant.
Come on, get a clue. Modular and top-down programming were found wanting 20 years ago. They are important principles, but they are not a solution.
A non-trivial piece of software isn't any more complex than a bridge.
A non-trivial piece of software has tens of thousands of different kinds of "parts" (classes, functions, expressions) and often millions of "parts instances". And, unlike physical parts, which are designed, manufactured, and tested by dozens of people each, software parts need to be designed at a rate of several per day by one programmer. Software works amazingly well for the conditions under which it needs to be created.
I don't know how much physics you've taken but the math behind a bridge is complex and it's really easy to make a mistake.
The mathematics behind bridges is absolutely trivial compared to the mathematics behind the semantics of computer programs.
As an Engineer you're held liable if something you design breaks. So you'd better make damn sure you get it 100% correct.
If you pay me to accept the liability, I'll be happy to. The simple fact is: most users don't care, and most users apparently aren't willing to pay tens of thousands of dollars for a word processor that doesn't crash.
I agree that improving accountability is good. Customers should, in fact, simply be able to return software like MS Word or Windows for a full refund if it doesn't live up to their expectations.
But why does establishing a software engineering certification improve accountability? If Microsoft hired certified software engineers, why would they be any more accountable?
The suggestion that anything a licensed software engineer writes should expose him to liability strikes me as very dangerous. Code is much more complex than bridges, and assigning responsbility for problems is hard. If I become liable for any stupid thing some random person on the Internet does with my code, I simply won't publish code for free. That can't be the goal.
So, again, companies that make safety-critical equipment and sell it for such purposes should be liable. Companies that sell word processors should be required to allow product returns if it doesn't work. Then, market forces will get companies to hire the programmers they need to get the job done.
However I would think that there is a definite need for accredited software engineers for software systems that would pose a hazard to life or limb by their failure. A control system for an oil refinery, or medical equipment, for example are no place for feature rich bloatware that needs to be re-booted once a day.
Sure, there is a need for software engineers that know how to build reliable software systems. Unfortunately, nobody knows how to guarantee reliability.
Oh, lots of people are very vocal about their pet methodologies or pet languages, but that's not the same as credible validation of the approaches, or a careful cost/benefit analysis.
There is a simple, free-market approach to ensuring software security: hold vendors responsible for faults. If Microsoft had to refund licensing fees when their software doesn't work, they'd be quick to improve its reliability. In areas where companies are exposed to significant liabilities, companies already are very careful with their software engineering methodologies and hire their employees accordingly.
Software development technology keeps changing so rapidly, faster than any standard can adapt, that I think it is wrong to try and enforce any standards just yet. We would risk prescribing practices that will just look ridiculous a few years down the road, or, worse, we would discourage people from trying different approaches. Other engineering disciplines had decades and centuries to develop their standards.
Pretending that "software engineering" is "engineering" also doesn't make it so. Most of the practices described in the document are popular in only a narrow segment of the industry. Teir use is not supported by any credible, measurable quantities. Nobody really understands where and how software engineering is practiced in the real world.
Creating a voluntary "IEEE certified software engineer" program may not be a bad idea--it would be like an "MCSE" for a different market segment. But making a program like this mandatory for software development or computer science education would be a very bad idea, in my opinion. Most of the software we use today would not exist in any form if SWEBOK practices had been in place over the last few decades.
I've always found the AtheOS approach an intriguing one, and quite reminiscent of Windows.
They build and optimize for the GUI, rather than the command-line kernel with a GUI built on top (like an X11 + *NIX approach).
I don't know what you mean by "build and optimize for the GUI". UNIX has a lot of command line utilities, but so what? Windows has a lot of command line utilities as well. Both systems can be administered from the command line, from a GUI, or from a web browser. The fact that most Windows users don't know about the command line doesn't seem to reflect on the OS, but on the user community.
obviously you live in or near a city. Rail, taxies, car rentals, bicycle zones all work great in high concentrations of people, but most of the land-mass of the USA and probably half the population don't live in highly populated areas. [...] What would be the cost of putting train stops within walking distance of everyone in New York or New Jersey vs putting train stops withing walking distance of everyone in Kansas?
The whole of the US has been settled in patterns that assumes widespread and frequent use of the car and air plane. Can you have a system that works well without frequent use of cars or air planes in states with lower population densities? Of course you can, just not with the current land use patterns in the US.
I'm under no illusion that this is going to happen any time soon. But that is not because there is something wrong with alternatives to the car, it's because with the advent of the automobile and airplane, the US has fallen into a trap that is hard to get out of.
Now, safe personal (automated?) air travel? That'd be great! I could make it to work in 5 minutes instead of the 30 minutes that it currently takes me to wind down the mountain and get to work. I certainly won't be waiting for the train to take me to work in my lifetime.
Well, you could move closer to work, or your job could move closer to where you are. The only reason why we have huge, central factories, huge, central shopping malls, and huge farms is because transportation is subsidized and there are some economies of scale. If transportation costs rise, jobs, farms, and shopping will move back closer to where you live. In different words, when gasoline rises to $10/gallon or $20/gallon (in 2001 dollars), as it probably will, you may well end up considering moving or taking the train, in your lifetime.
The alternative is to make the shell understand about the notion of an "application" that consists of a bunch of files living together in a directory. That way, you could say something like "my path consists of all the application directories that are subdirectories of/usr/apps".
And you can, of course, also create directories of pointers to where stuff really lives through symbolic links, together with a process that cleans them up every now and then when they have gotten stale.
Rail is violently expensive. Profit margins tend to be low even in densely-populated areas.
Rail, when widely deployed, is intrinsically cheaper than air travel. What makes rail expensive relative to other modes of transportation in the US is poor utilization, low-volume production of the components, poor integration, lengthy and costly legal and political fights when trying to build new rail lines, and subsidies and failure to account for the true costs of automobiles and air travel.
You can't "grow your way" into rail travel and hope that it's cost effective from its smallest beginnings to a large scale deployment. If you insist on incremental adoption of a technology, you automatically favor auto and air travel, which have much lower infrastructure costs and can be deployed one vehicle at a time. Unfortunately, the ultimate cost of having 300 million people rely on cars and airplanes are horrendous.
The problems that need to be solved for mass aviation are identical to many highly-relevant military problems: cruise missiles need to be able to autonomously navigate with 10 meter precision using terrain observation and inertial guidance
That seems like another good reason not to undertake that kind of development effort: I can do well without both personal aircraft and without another generation of cruise missiles.
If you want to deploy massive improvements in 50 years,
Actually, I'd prefer to see short and medium range air travel, as well as the personal automobile, be largely replaced in 50 years by rail, high speed ferries, automatic taxies, walk-up car rentals, pedestrian and bicycle zones, and telecommuting. Those are technologically far simpler and have clear benefits.
When you count all the synchronization which is happening between all these threads,
Synchronization between Java threads is a lot faster than any of the IPC mechanisms that, say, Gnome, KDE, or Mozilla are using.
as well as the sheer amount of context switching,
If the Linux kernel and thread libraries provided better primitives, you wouldn't need as many system calls to build threaded applications on top of them.
memory usage
If you run a complete desktop inside a single Java process, you end up using a lot less memory than Gnome or KDE: Java applications can share code and data a lot easier and with a lot less overhead inside a single process than C/C++-based systems. In fact, the voracious appetite of C/C++ GUI apps is one reason for abandoning that approach.
and the number of processes which have to be scanned to find one capable of being accessed,
I don't understand what you mean by this. If there is only a single Java process, you don't have to "scan" lots of them.
If you mean that Java using native threads makes lots of kernel threads under Linux and that that has a bit of overhead, you are right. But that's a shortcoming of the Linux threads system and Sun's particular implementation of threads on Linux, not of the Java approach. In a well-designed thread implementation, a thread is no more expensive than an object.
which means that you need to make threads for *everything*. Its not uncommon to have two threads per socket to handle reading and writing blocks.
Java lacks some APIs and Sun's Java implementation has limitations, but that doesn't invalidate the approach. There are systems like Java that have better threading support. Still, a single-process approach based on JDK and Linux, with all the limitations of the JDK and of Linux, is already more efficient than the many process approach of Gnome or KDE and similar systems.
I don't quite see the point of short-hop mass air transportation. A well-designed rail system is more efficient, less noisy, safer, and more environmentally friendly. And we could, gasp, move closer to where we work.
To me, this sounds like NASA is grasping at straws trying to prove its relevance. But developing tech toys won't cut it, I suspect.
If you try to transfer your domain away from NSI by letting your domain expire and then reregistering it with another registrar, you may find that NSI is holding it hostage.
Maybe the intent isn't quite as sinister as you think. People's domains often expire because their bill got lost somewhere. NSI customers have some interest in NSI holding on to their expired domain names for a while. And NSI can't really verify that you are transferring the domain to yourself at another registrar.
Don't get me wrong: I don't like NSI's service either and they are milking this for everything it's worth. But that doesn't mean every screwup has a master plan behind it. Mostly, they probably don't fix broken procedures because it doesn't make them any money. Welcome to an unregulated market economy: it will take decades before NSI either shapes up or goes out of business.
Many OS purists think that using multiple processes is a hack around understanding multithreaded programming especially since traditionally there is a context/address switch cost from process to process versus when using different threads.
It's not about "understanding". If you program in a language like C or C++ that is so lacking in fault isolation and safety features, you have to use separate processes to keep things out of each other's hair. The alternative, which is known to be more efficient, is to use safe languages and multithreading.
This kind of disconnect is also why Java has such a bad name among Linux users. Java doesn't need separate processes--you can run your whole desktop in a single thread, safely. What Java needs is fast threads.
In any case, as far as Mozilla is concerned, it's slow because it's written that way, not because of anything wrong with Linux. And the Mozilla developers neither seem to understand nor care much about the UNIX and X11 world. The existence of browsers like Opera show that you don't need something as big and slow as Mozilla, and even Opera isn't all that efficient. Rendering HTML is not rocket science, and it is actually kind of amazing how many megabytes people manage to expend on it.
Gates is a busy guy. He single-handedly gave the world open source, the Internet, office suites, multitasking, security, transactioned file systems, and GUIs. Well, at least according the Microsoft propaganda.
In reality, Microsoft copied everything and was usually years late at doing so.
As for open source, it is as old as computers. The Free Software Foundation was producing GNU C and other GNU software before the PC was even a 32 bit computer.
I don't think it is appropriate for the government in any society to try and compromise computers via computer viruses. Maybe Mr. Ashcroft is benign (hah!), but what about our old bugaboo, the Chinese government? And government intrusions are really no different than intrusions from some other determined, skillful, powerful entity trying to do you harm. So, having said that, I think it's worth to think about how one can avoid falling prey to these kinds of intrusions.
Remote, automatic updates like Microsoft's automatic update, Norton and McAfee anti-virus updates (talk about ironic), Compaq automatic support, Debian, and (commercial) RedHat are vulnerable to this. Governmental agencies can easily carry out man-in-the-middle attacks against specific targets. Even if you guard against that with secure key distribution, governmental agencies can quietly compromise trusted sources ("Mr. Gates, you have to ship this virus-carrying update; it's your patriotic duty", or "Mr. Debian package maintainer, you must include this binary in your package and sign it").
What can people do about it? First, use intrusion detection software: is your computer making connections to funny sites by itself? Are other unusal patterns of activity occurring? Have binaries changed unexpectedly? Second, use many sources of information, not just one "secure" one. For someone to figure out how to modify package signatures consistently received from multiple different source via multiple different means in order to hide their hacking is rather difficult. Third, if security is important to you, quarantine updates and wait whether other people have detected compromises.
In fact, systems like Debian and RedHat should really make it much easier to hook up to multiple source of package signatures (via E-mail, custom scripts, etc.) and allow people to verify packages.
One guy has the brilliant idea that it is frequently useful to arrange search results and files by time and patents the equivalent of "ls -lt". Another gives use more 3D room equivalents, and yet another gives us a "lens" that compresses less relevant information off to the side.
Two paradigms that actually are a bit more interesting aren't mentioned. The first is "active notebooks", as found in MathCad or Mathematica, related to a number of earlier toolkits like CLIM and DynamicWindows (now defunct), and also in some vague sense related to HTML/JavaScript/DOM. Such approaches combine text and documents with behavior and interaction. We might call them "document-based UIs" and they can be a lot easier to author, and they provide a lot more useful information and help to end users, compared to toolkits like Motif, Win32/MFC, Gtk+, and Qt.
The other interesting development is zoomable user interfaces, as in the Jazz toolkit. Zoomable user interfaces can be viewed as a very restricted form of 3D toolkit, something that is actually fairly easy to understand for users and reasonably consistent and straightforward to program for. Zoomable interfaces can also be viewed as the "structured graphics" document type complementing the document-based UIs I mentioned in the previous paragraphs.
If Linux or the open source community wants to break ground in delivering new, more usable, easy-to-author UIs, zoomable and document-based UIs are the way to go in my opinion. Hyperbolic browsers, 3D rooms, and time-ordered display are little frills around the edges.
Actually, I view Windows-only client programming as kind of a "niche"--a big niche, but a niche. Also, Windows programmers brought up on C# will have a very easy time picking up Java and becoming bilingual.
And Sun may take competition from C# as an incentive to improve Java and also make it better for desktop applications. Sun has been dragging their feet on VM sharing, compiled code caching, genericity, and a few other features.
And when I look at the fact that there are far more McDonald's restaurants around than Four Seasons; far more government programs that take money directly from the wealthy and give it directly to the poor than vice versa ; and far more Targets and Wal-Marts than Neiman-Marcuses (or whereever us rich and powerful folk shop), it becomes even more difficult to understand just how the rich and powerful manage to control so much in our country, knowing their tastes and aspirations as I presumably do (being one of them, y'see).
Well, of course, with your firm belief in the existence of an efficient mass market in the US and seeming lack of familiarity with alternative choices, that's doubtlessly the only conclusion you can reach. Of course, I'd view that reasoning as kind of circular.
To many people who have personal experience living and working in other countries for extended periods of time, and according to numerous economic studies, the US standard of living is lower than in many other western nations, even though the US is clearly economically predominant. Americans live with inconvenient and unreliable transportation systems, a flakey banking system, poorly built homes, poor nutritional choices, poor health services, and poor choices for recreational activities. Even being a reasonably well off consumer in one of the more civilized areas of the US, in many of these areas, I simply cannot get better products and services.
To me, it's pointless to argue whether the US market represents an optimal outcome for US consumers--it clearly does not. The only question to me is: why not? Why do Americans put up with living like this? I mean, people in developing nations can't afford to live any better than they do, but the US has the money and the resources to do better.
I think from the level of people who make decisions about what programming languages to use on commercial projects (this includes me), the technical distinctions between Java and C# are of little concern: the languages are so similar that they are basically interchangeable. What matters is who supports it, what libraries are available, how mature are the implementations, whether it's a single-vendor or mult-vendor solution, how well it integrates with the platform, and how many programmers are available.
For pure Windows programmers, C# wins there and will probably be picked up by lots of VB and VisualC++ programmers. But people who live in that world are already not using Java. For everybody else, Java seems to win hands down. I think C# will neither be a complete failure nor will it do much harm to Java.
There is a very simple mechanism by which lawyers will likely put an end to that: if you are part of a software "crowd" and someone in that crowd does something, you will be held at least in part responsible; the necessary connectivity information can probably be obtained from ISP logs and electronic wiretaps even if the source of any particular request cannot.
In fact, I wouldn't be surprised if the legal system or Ashcroft wouldn't try to claim that you should be suspected of terrorist activities simply because you are using software like AT&T's crowds software. Since that kind of software doesn't ship with every PC and requires at least a bit of skill and effort to install, you will be part of a small minority if you do.
The CIA wants to provide anonymization so that people in other countries with oppressive regimes can get unhindered and anonymous access to information. But "anonymous access to information" probably has a bad name in Washington right now, with all that fear and speculation surrounding terrorism.
Slashdot Mirror
(BTW, I find Galeon has been getting less stable for me: downloads have started to fail, it crashes with some frequency when exiting, etc. I hope 1.0 will fix that.)
FLTK is very lightweight and easy to use. It is used extensively on handheld Linux devices. FLTK1 lacks some functionality that you may need, but FLTK2 is shaping up to be quite complete.
Also, Qt is not the only game in town for commercial toolkits. If you want something commercial, look around. In the past, other commercial toolkits had much better tool support than Qt.
If you want a nifty handheld with a proprietary toolkit, there are lots of WindowsCE devices out there. And developing for WindowsCE is cheaper than developing for Qt.
Oh, my gosh! You got the solution! The silver bullet! Tens of thousands of computer scientists and engineers have worked on this for decades and not come up with a solution. But you found the answer. Brilliant.
Come on, get a clue. Modular and top-down programming were found wanting 20 years ago. They are important principles, but they are not a solution.
A non-trivial piece of software isn't any more complex than a bridge.
A non-trivial piece of software has tens of thousands of different kinds of "parts" (classes, functions, expressions) and often millions of "parts instances". And, unlike physical parts, which are designed, manufactured, and tested by dozens of people each, software parts need to be designed at a rate of several per day by one programmer. Software works amazingly well for the conditions under which it needs to be created.
I don't know how much physics you've taken but the math behind a bridge is complex and it's really easy to make a mistake.
The mathematics behind bridges is absolutely trivial compared to the mathematics behind the semantics of computer programs.
As an Engineer you're held liable if something you design breaks. So you'd better make damn sure you get it 100% correct.
If you pay me to accept the liability, I'll be happy to. The simple fact is: most users don't care, and most users apparently aren't willing to pay tens of thousands of dollars for a word processor that doesn't crash.
But why does establishing a software engineering certification improve accountability? If Microsoft hired certified software engineers, why would they be any more accountable?
The suggestion that anything a licensed software engineer writes should expose him to liability strikes me as very dangerous. Code is much more complex than bridges, and assigning responsbility for problems is hard. If I become liable for any stupid thing some random person on the Internet does with my code, I simply won't publish code for free. That can't be the goal.
So, again, companies that make safety-critical equipment and sell it for such purposes should be liable. Companies that sell word processors should be required to allow product returns if it doesn't work. Then, market forces will get companies to hire the programmers they need to get the job done.
Sure, there is a need for software engineers that know how to build reliable software systems. Unfortunately, nobody knows how to guarantee reliability.
Oh, lots of people are very vocal about their pet methodologies or pet languages, but that's not the same as credible validation of the approaches, or a careful cost/benefit analysis.
There is a simple, free-market approach to ensuring software security: hold vendors responsible for faults. If Microsoft had to refund licensing fees when their software doesn't work, they'd be quick to improve its reliability. In areas where companies are exposed to significant liabilities, companies already are very careful with their software engineering methodologies and hire their employees accordingly.
Pretending that "software engineering" is "engineering" also doesn't make it so. Most of the practices described in the document are popular in only a narrow segment of the industry. Teir use is not supported by any credible, measurable quantities. Nobody really understands where and how software engineering is practiced in the real world.
Creating a voluntary "IEEE certified software engineer" program may not be a bad idea--it would be like an "MCSE" for a different market segment. But making a program like this mandatory for software development or computer science education would be a very bad idea, in my opinion. Most of the software we use today would not exist in any form if SWEBOK practices had been in place over the last few decades.
Also, NumericalPython and the Python Imaging Library are good packages and integrate with VTK. NumericalPython is better than Matlab, IMO.
I don't know what you mean by "build and optimize for the GUI". UNIX has a lot of command line utilities, but so what? Windows has a lot of command line utilities as well. Both systems can be administered from the command line, from a GUI, or from a web browser. The fact that most Windows users don't know about the command line doesn't seem to reflect on the OS, but on the user community.
The whole of the US has been settled in patterns that assumes widespread and frequent use of the car and air plane. Can you have a system that works well without frequent use of cars or air planes in states with lower population densities? Of course you can, just not with the current land use patterns in the US.
I'm under no illusion that this is going to happen any time soon. But that is not because there is something wrong with alternatives to the car, it's because with the advent of the automobile and airplane, the US has fallen into a trap that is hard to get out of.
Now, safe personal (automated?) air travel? That'd be great! I could make it to work in 5 minutes instead of the 30 minutes that it currently takes me to wind down the mountain and get to work. I certainly won't be waiting for the train to take me to work in my lifetime.
Well, you could move closer to work, or your job could move closer to where you are. The only reason why we have huge, central factories, huge, central shopping malls, and huge farms is because transportation is subsidized and there are some economies of scale. If transportation costs rise, jobs, farms, and shopping will move back closer to where you live. In different words, when gasoline rises to $10/gallon or $20/gallon (in 2001 dollars), as it probably will, you may well end up considering moving or taking the train, in your lifetime.
And you can, of course, also create directories of pointers to where stuff really lives through symbolic links, together with a process that cleans them up every now and then when they have gotten stale.
Rail, when widely deployed, is intrinsically cheaper than air travel. What makes rail expensive relative to other modes of transportation in the US is poor utilization, low-volume production of the components, poor integration, lengthy and costly legal and political fights when trying to build new rail lines, and subsidies and failure to account for the true costs of automobiles and air travel.
You can't "grow your way" into rail travel and hope that it's cost effective from its smallest beginnings to a large scale deployment. If you insist on incremental adoption of a technology, you automatically favor auto and air travel, which have much lower infrastructure costs and can be deployed one vehicle at a time. Unfortunately, the ultimate cost of having 300 million people rely on cars and airplanes are horrendous.
The problems that need to be solved for mass aviation are identical to many highly-relevant military problems: cruise missiles need to be able to autonomously navigate with 10 meter precision using terrain observation and inertial guidance
That seems like another good reason not to undertake that kind of development effort: I can do well without both personal aircraft and without another generation of cruise missiles.
If you want to deploy massive improvements in 50 years,
Actually, I'd prefer to see short and medium range air travel, as well as the personal automobile, be largely replaced in 50 years by rail, high speed ferries, automatic taxies, walk-up car rentals, pedestrian and bicycle zones, and telecommuting. Those are technologically far simpler and have clear benefits.
Synchronization between Java threads is a lot faster than any of the IPC mechanisms that, say, Gnome, KDE, or Mozilla are using.
as well as the sheer amount of context switching,
If the Linux kernel and thread libraries provided better primitives, you wouldn't need as many system calls to build threaded applications on top of them.
memory usage
If you run a complete desktop inside a single Java process, you end up using a lot less memory than Gnome or KDE: Java applications can share code and data a lot easier and with a lot less overhead inside a single process than C/C++-based systems. In fact, the voracious appetite of C/C++ GUI apps is one reason for abandoning that approach.
and the number of processes which have to be scanned to find one capable of being accessed,
I don't understand what you mean by this. If there is only a single Java process, you don't have to "scan" lots of them.
If you mean that Java using native threads makes lots of kernel threads under Linux and that that has a bit of overhead, you are right. But that's a shortcoming of the Linux threads system and Sun's particular implementation of threads on Linux, not of the Java approach. In a well-designed thread implementation, a thread is no more expensive than an object.
which means that you need to make threads for *everything*. Its not uncommon to have two threads per socket to handle reading and writing blocks.
Java lacks some APIs and Sun's Java implementation has limitations, but that doesn't invalidate the approach. There are systems like Java that have better threading support. Still, a single-process approach based on JDK and Linux, with all the limitations of the JDK and of Linux, is already more efficient than the many process approach of Gnome or KDE and similar systems.
To me, this sounds like NASA is grasping at straws trying to prove its relevance. But developing tech toys won't cut it, I suspect.
Maybe the intent isn't quite as sinister as you think. People's domains often expire because their bill got lost somewhere. NSI customers have some interest in NSI holding on to their expired domain names for a while. And NSI can't really verify that you are transferring the domain to yourself at another registrar.
Don't get me wrong: I don't like NSI's service either and they are milking this for everything it's worth. But that doesn't mean every screwup has a master plan behind it. Mostly, they probably don't fix broken procedures because it doesn't make them any money. Welcome to an unregulated market economy: it will take decades before NSI either shapes up or goes out of business.
It's not about "understanding". If you program in a language like C or C++ that is so lacking in fault isolation and safety features, you have to use separate processes to keep things out of each other's hair. The alternative, which is known to be more efficient, is to use safe languages and multithreading.
This kind of disconnect is also why Java has such a bad name among Linux users. Java doesn't need separate processes--you can run your whole desktop in a single thread, safely. What Java needs is fast threads.
In any case, as far as Mozilla is concerned, it's slow because it's written that way, not because of anything wrong with Linux. And the Mozilla developers neither seem to understand nor care much about the UNIX and X11 world. The existence of browsers like Opera show that you don't need something as big and slow as Mozilla, and even Opera isn't all that efficient. Rendering HTML is not rocket science, and it is actually kind of amazing how many megabytes people manage to expend on it.
In reality, Microsoft copied everything and was usually years late at doing so.
As for open source, it is as old as computers. The Free Software Foundation was producing GNU C and other GNU software before the PC was even a 32 bit computer.
Remote, automatic updates like Microsoft's automatic update, Norton and McAfee anti-virus updates (talk about ironic), Compaq automatic support, Debian, and (commercial) RedHat are vulnerable to this. Governmental agencies can easily carry out man-in-the-middle attacks against specific targets. Even if you guard against that with secure key distribution, governmental agencies can quietly compromise trusted sources ("Mr. Gates, you have to ship this virus-carrying update; it's your patriotic duty", or "Mr. Debian package maintainer, you must include this binary in your package and sign it").
What can people do about it? First, use intrusion detection software: is your computer making connections to funny sites by itself? Are other unusal patterns of activity occurring? Have binaries changed unexpectedly? Second, use many sources of information, not just one "secure" one. For someone to figure out how to modify package signatures consistently received from multiple different source via multiple different means in order to hide their hacking is rather difficult. Third, if security is important to you, quarantine updates and wait whether other people have detected compromises.
In fact, systems like Debian and RedHat should really make it much easier to hook up to multiple source of package signatures (via E-mail, custom scripts, etc.) and allow people to verify packages.
For the UI technology afficionado, I didn't mean "lens", I meant "hyperbolic browser".
Two paradigms that actually are a bit more interesting aren't mentioned. The first is "active notebooks", as found in MathCad or Mathematica, related to a number of earlier toolkits like CLIM and DynamicWindows (now defunct), and also in some vague sense related to HTML/JavaScript/DOM. Such approaches combine text and documents with behavior and interaction. We might call them "document-based UIs" and they can be a lot easier to author, and they provide a lot more useful information and help to end users, compared to toolkits like Motif, Win32/MFC, Gtk+, and Qt.
The other interesting development is zoomable user interfaces, as in the Jazz toolkit. Zoomable user interfaces can be viewed as a very restricted form of 3D toolkit, something that is actually fairly easy to understand for users and reasonably consistent and straightforward to program for. Zoomable interfaces can also be viewed as the "structured graphics" document type complementing the document-based UIs I mentioned in the previous paragraphs.
If Linux or the open source community wants to break ground in delivering new, more usable, easy-to-author UIs, zoomable and document-based UIs are the way to go in my opinion. Hyperbolic browsers, 3D rooms, and time-ordered display are little frills around the edges.
And Sun may take competition from C# as an incentive to improve Java and also make it better for desktop applications. Sun has been dragging their feet on VM sharing, compiled code caching, genericity, and a few other features.
Well, of course, with your firm belief in the existence of an efficient mass market in the US and seeming lack of familiarity with alternative choices, that's doubtlessly the only conclusion you can reach. Of course, I'd view that reasoning as kind of circular.
To many people who have personal experience living and working in other countries for extended periods of time, and according to numerous economic studies, the US standard of living is lower than in many other western nations, even though the US is clearly economically predominant. Americans live with inconvenient and unreliable transportation systems, a flakey banking system, poorly built homes, poor nutritional choices, poor health services, and poor choices for recreational activities. Even being a reasonably well off consumer in one of the more civilized areas of the US, in many of these areas, I simply cannot get better products and services.
To me, it's pointless to argue whether the US market represents an optimal outcome for US consumers--it clearly does not. The only question to me is: why not? Why do Americans put up with living like this? I mean, people in developing nations can't afford to live any better than they do, but the US has the money and the resources to do better.
For pure Windows programmers, C# wins there and will probably be picked up by lots of VB and VisualC++ programmers. But people who live in that world are already not using Java. For everybody else, Java seems to win hands down. I think C# will neither be a complete failure nor will it do much harm to Java.
In fact, I wouldn't be surprised if the legal system or Ashcroft wouldn't try to claim that you should be suspected of terrorist activities simply because you are using software like AT&T's crowds software. Since that kind of software doesn't ship with every PC and requires at least a bit of skill and effort to install, you will be part of a small minority if you do.
The CIA wants to provide anonymization so that people in other countries with oppressive regimes can get unhindered and anonymous access to information. But "anonymous access to information" probably has a bad name in Washington right now, with all that fear and speculation surrounding terrorism.