First, it is a fact that installing Linux on some ancient and not so ancient PCs is tough. That said, the problems are often with the specific distribution rather than being endemic. I always keep a recent Knoppix live CD on hand. If I cannot boot Knoppix on the PC (having tried the various useful boot switches available) then I assume making things work on that PC will be too hard. If I can boot Knoppix, making it work with other recent distributions is only a matter or working out what was wrong and resolving the problem.

When asking for help, you need to develop the combination of a thick skin and a grovelling disposition. In my experience, those who are most knowledgeable are helpful, but very very busy. Most of the time, you need to rely on arseholes who have time on their hands to help, but find it more fun to make you suffer first.

Say, you have an idea for improving the efficiency of solar panels. Commercializing it will cost many millions of dollars, but there is a healthy expanding market. Why not? Well, if there are several patents held by other organizations on inferior solar panels, but including necessary aspects of your better design, this severely restricts future profits from sale of the improved panels, and the viability of development.

Unfortunately, this is not just theoretical. It is the what happens time and time again. Often, the obvious aspects of some technology get patented early which makes it uneconomic to do the necessary optimization of the process for a decade or more.

there's got to be some way we can put the fault on Micro$oft?

Most people on /. are too young to properly comprehend the situation. Blaming Microsoft for everything that goes wrong in IT only became standard operating procedure in the 1990s. Since the system is supposedly based on a 1980s era Data General mini, we need to resurrect our blame processes from that era. This failure was clearly engineered by IBM. Not only that, but they are using their huge muscle to block third party maintenance of the hardware.

Hey, many visitors to Congress go there because they want to know how their government works. The experience you relate shows that they are doing their best to demonstrate. Why else do you think legislation can take so long and so much legislation fall by the wayside because it cannot be completed. The rules for our Congress critters and Senators are as time consuming and nonsensical as those for visitors.

I agree with all your points, with a few caveats that I shall mostly not bother with.

For your own information

• There is no problem sending ZIP (or other compressed format) files through Gmail, depending on the names of the embedded files. It is trying to block executable files within the zip archive.
• To overcome the problem sending executable files through Gmail. just change the filetype. For instance, change "myprog.exe" to "myprog.exe.rename", "myscript.vbs" to "myscript.vbs.rename" and "myarchive.zip" with embedded executables to "myarchive.zip.rename". Everything is then fine.

Your post made be laugh. Thanks for that. But, seriously, Fastmail.FM is not a free email service. The "Guest" account is severely crippled (as you correctly point out) but is really only intended to allow people to get a feel for the service before paying to use the service for real.

As for your point that serious FM users know all the names and positions of the key folks at FM, that is because of the open communication on the EmailDiscussions forums. It is a compact, transparent organization with good people.

Teh Google is reading my mail, but then it's ignoring most of it. Since the government is already reading my mail, who cares about google?

If you are using Fastmail.FM with secure login, the government most likely is not reading your mail. I suspect NSA can break SSL, but I am confident it is expensive and they only do so on an extremely selective basis.

Okay, so could someone who is familiar with who these guys are explain what they have to offer? From a quick look, my impression is that as a consumer who doesn't necessarily need 5 9's of reliability, there isn't much reason for me to use them over Gmail.

For most casual email users (and even some not so casual) Gmail is quite sufficient. I happen to use Gmail extensively (but not exclusively) myself. However, I have several customers who are small business users and, for them, Fastmail.FM is usually a much superior alternative. It's not just a question of reliability (though FM, today, is more reliable then Gmail) but also because of features. Gmail has better search and a cleaner UI than FM, but otherwise all the feature advantages lie with FM. For instance

• an executive being able to share some of his emails with his PA but not others;
• support for multiple personalities so that an entrepreneur can easily wear multiple hats switching intuitively between them;
• the ability to select which emails get forwarded to your smart phone based on almost any criteria;
• very easy realtime backup of both received and sent emails to a backup server (for which I invariably use Gmail)

These are the kinds of things that really matter to many users.

it ain't cheap to upgrade to gmail levels of storage.

I guess "cheap" is a subjective term. The additional cost to upgrade from "Full" to "Enhanced" membership (6GB email space plus 2GB file space) is US$20 per year. Casual email users might balk at that, but is is surely an acceptable cost for people who use email as a critical tool.

Self-encrypting viruses that choose to infect non-common running process images (i.e. avoid Windows system files) might have different signatures everywhere and still require manual analysis.

Hmmm... This is somewhat similar to an issue mentioned in the article: polymorphic viruses. It raises an interesting question. Do existing AV products try to detect such behavior in newly executed code? I am really not sure how tricky the algorithms would be to detect code that is trying to encrypt itself or modify its own executable code. However, most regular software (funnily enough excepting security software trying to avoid detection by malware!) does not need to do this, so such code should probably be blocked and reported by default.

It is worth noting that the disk drives at the museum are not first generation. An original IBM 350 weighed over a ton! It had a capacity of about 4.4 MB and a peak transfer rate a little over 8KB per sec. It is amazing to realize that a modern consumer 2TB drive has the capacity of about 400,000 IBM 350 drives and a transfer rate over 10,000 times faster.

... I have yet to see any application based on any large "cloud" based service have response times as bad as their site right now. A 20x slowdown would under load would be orders of magnitude better than they are achieving. Hmmm ... could one of the reasons some companies prefer to outsource applications be that there is extra capacity to handle peak load conditions?

Your recollections are different from mine. Prior to Google, I tended to use AltaVista and Hotbot. Searches took at least ten times as long. Results rarely included any recently created pages. The number of indexed pages was several orders of magnitude less than Google handles today (which in turn is one order of magnitude, or so, greater than current competitors). In spite of the fact that gaming of search engines is overwhelmingly targeted at Google, Google still does a relatively better job of finding the genuinely useful pages. Is Google perfect? No, of course not. Search is still only a partially solved problem. However, since its inception, Google has come up with most of the practical advances in the state of the art, as well as the best infrastructure for its implementation.

I very much hope the Office of the US Trustee, IBM, Novell and others do not appeal the delay. Of course, they have excellent grounds for doing so, but the result would likely just be a longer delay. SCO has successfully gamed the system, and will probably gain a six week delay in the process. If this is appealed, it will probably take longer than six weeks just to argue and get a decision. Meanwhile, SCO will argue that the purchase agreement cannot go forward with the Chapter 7 conversion hanging over their head (BS, of course, but prove it).

If you have the cash, IBM has always been (and still is) the virtualization king. This started with CP-67 (originally for development) and gradually evolved via VM/370, VM/SP and VM/ESA into a platform for running multiple production OS in parallel. IBM, along the way, added a hardware level partitioning capability called LPAR. IBM mainframes today have LPAR to allow partitioning of the real machine into (for all practical purposes) multiple completely independent computers. One or more of those can be running z/VM (a very powerful and mature hypervisor in its own right). On a big zSeries, it is entirely reasonable to run a few thousand separate Linux instances with good stability and efficiency.