What features did they remove this time?
on
Gnome 2.14 Released
·
· Score: 0, Troll
So given that this is a new release of GNOME, which means that each release has to have less functionality than the previous one, so it can be "easy to use", the obvious question to ask is, "What got left on the cutting room floor this time?"
The slashdot editor was doing his job; writing provocative headlines that cause people to click on the story and generate revenue for the OSTG. Any other questions?:-)
IBM definitely contributes more in the way of core kernel functionality (it's not just JFS, but also we have a number of engineers, myself included, who publically contribute on LKML and on ext2-devel on the ext2/3 filesystem). I'd have to think hard to think of any HP kernel contributors, besides the folks who work on the architecture-specific Itanium code.... (thinking....) Nope, got nothing.
That being said, I do have to give snaps to HP for employing Keith Packard and Jim Gettys. Keith in particular has been pretty much the only X developer that has been working on new core features in X11 for the past couple of years.
But in the final analysis, between IBM making 500 patents available, and all of the IBM developers contributing various enhancements to the linux Kernel, it's really not at all surprising that more people think of IBM when it comes to Linux.
Only the core C# VM is an ECMA standard. That's about as useful as the Java byte code langage without any of the Java classes. Or the Perl VM without all of CPAN. By itself, what is "open" and promised to be patent free is only the very core of.NET, which is totally useless as a stand-alone piece. It's just enouh to sucker the foolish into a bait and switch game.
If Microsoft is truly interested in using the patents only for defensive purposes, then they offer a perpetual, non-revocakable license to all of these patents, subject to the following conditions (a) that patent licensees do not sue Microsoft over patent violations in.NET, and that (b) those patents should only be used for creating implementations which are interoperable with the.NET protocols.
But I'm willing to bet several cases of virtual beer that this will never happen, because I believe, as many industry analysts and columnists also believe, that the main purpose of Longhorn is a full-frontal assault on Linux and the entire Open Source Software Stack --- and that in Microsoft's mind, it is war, and that any means, fair or foul, is allowed in this "War on OSS".
For the most part, this just means no more hi-band/lo-band split where the the ILEC is required to provide low frequency analog voice while selling the high frequency broadband side to a CLEC on the same pair. The CLEC can still get the whole loop.
This is true. But consider that this is what CLEC's do when they do SDSL. For a long time, I had to use SDSL because because my house was too far away from the Central Office (CO) for ADSL. The problem is that SDSL is substantially more expensive. I was paying $227/month for 384k symmetric. Compare that with $99/month for 1.5mbps down / 768k up, and you can see that SDSL is over twice as expensive for substantially less bandwidth. Now, some of this cost might be differential in cost of the equipment between SDSL and ADSL, and some of this might be because businesses generally want SDSL, so ISP's feel free to gauge them. But at least some of the difference must be the cost of the local loop.
Now, this being said, presumably the local bells won't be able to get away with charging more than the cost of a separate voice line, since that normally represents the cost of a copper pair plus the cost of the normal voice service. Of course, the local bells might claim that given that they often use multiplexors to multiplex several voice channels onto a single copper or fiber loop, that the cost of providing a voice connection is much less than $30/month, but the cost of the copper loop is $$$. Ultimately, we simply don't know. The big question is what kind of rates will companies like Covad be able to negotiate with its local bells for the whole copper loop.
That Slashdot chose to include the entire press release (since that is what this clear was) as part of the slashdot article. A pointer to a web page, perhaps --- the fact that Phil Zimmerman is behind a new commercial product that competes with original commercial version of PGP, perhaps. But the entire press release? Please! Why give them free advertising? (I'm assuming here that this wasn't a new way for the OSDN to raised revenues by getting an entire Slashdot article with arbitrary content from a marketing organization in exchange for $$$).
In any case, it's not really clear this story is all that interesting as news anyway, for the very simple reason that it is very doubtful that commercial versions of PGP will succeed, simply becuase for the naive user, PGP is Just Too Hard to use. The moment you have to explain certification chains to users, you've lost. The naive user (the ones who can't figure out how to set the time on their VCR's) simply won't be able to cope. And for the expert users, they'll just simply download GPG, or perhaps the old version of PGP 2.6.2. Why should they pay $$$ for a commercial command-line version?
There are two sides to every story. And so far, we've only heard Kevin Mitnick's side of the story. However, just simply listening to his claims, it's pretty clear that (a) Markoff gave him the opportunity to comment, and (b) Mitnick refused to do so unless he was paid. In the journalistic profession, it's only the dubious papers such as National Enquirer and World Wide Weekly news which are known for paying their sources for information (which can result in the obvious potential conflict of interest for the sources), so Markoff refused.
Mitnick called this "blackmail", but IMHO it sounds like he either didn't know how the journalistic world works, or is trying to cast doubt on Markoff's reporting by casting him as a demon.
Mitnck, for example, complains that Markoff was (falsely) told by one or both of his co-spirators, Steven Rhoads and Lenny Dicicco that he had hacked into NORAD in 1983. Well, that might or might not be true, but it's certainly not an "un-sourced allegation". And we don't know whether or not Markoff contacted NORAD, and regardless of whether or nor he did, but in some sense, if it was a sucessful penetration, NORAD would have no idea that they had been hacked in the first place. So much for Mitnick's complaints that Markoff should have verified the "authenticity of their claims with the alleged victims". The victims very likely wouldn't have known, one way or another!
Ultimately, a reporter stands or falls by his sources, and what an editor will do is to make sure that the editor has gotten his information from his sources, and whenever possible make sure that enough information about the sources of information is disclosed in the reporter's story so that the reader can judge for him- or her-self whether or not to believe the facts of the story.
After all, if someone asked Clinton to comment about Monica, and he refused unless he got $$$, most people would consider that quite improper. But when Mitnick tried to do the same thing (unsuccessfully), people think that he's being victimized somehow. Well, he's not. That's just not how the world works.
I agree with everything Bruce has said. I want to add one note, however. There's a much better workaround to allow RF patent licenses to be used with GPL code --- which is to simply license the code under the GPL V1 (only) license! The GPL V1 license doesn't have that pesky clause #7 referring to patents in it. (Well, it has a clause #7, but it's just the "FSF may publish revisions, and you can either specify whether you want to use only V1 or allow the FSF to change the licensing terms of your program as they see fit.)
URL to his obit. page
on
802.11 RF Amp
·
· Score: 3, Interesting
I don't think you need to worry. What Linksys is doing is not nearly as interesting as people might assume (which is I suppose is par for the course for Slashdot:-) What I'm pretty sure is going on is that the wireless access point on the linksys doesn't have a very strong radio transmitter to begin with (I'm guessing 30-50mW), and the signal amplifer just raises the transmit power to the max legal limit for the 2.4GHz band.
The Cisco 350 Access Point (and wireless cards) has better receive sensitivity (I don't know if that's due to a better built-in antenna, or better radio circuity, or both), and a stronger transmit power than most other 802.11 cards (selectable from 5mw to 100mW). In contrast, the Lucent Wavelan Silver card has a 31 mW transmitter. I don't know what the transmit power for the Linksys access point, since it's not listed on the web site or in the user's guide, but they claim an outdoor range of 1500 feet at 1 Mbps, and 500 feet at 11 Mbps. For comparison, the Orinocco access point claims 1750 feet at 1 Mbps, and 525 feet at 11 Mbps, and the Cisco 350 access point claims an outdoor range of 2000 feet at 1 Mbps and 800 feet at 11 Mbps. If we assume that both Cisco and Linksys are exagerating to an equal extent for the best case scenario, it seems pretty clear that the Lucent transmitter is less powerful than the Cisco 350.
Of course, as radio amateurs know, transmitter power doesn't have as much effect on range as some people might think. That's why QRP operators can sometimes communicate with people halfway across the globe with only a Watt or two of power. So the Linksys signal amplifier will probably not make that much of a difference.
That being said, I would recommend the Cisco 350, not because of the higher transmit power, but because the access point has better manageability (you have much finer control over how the access point operates, with various nice features such as having the AP ask your radius server whether or not a particular MAC address should be allowed, LEAP authentication/encryption, etc.). Also the Cisco 350 PC card has a full-featured Linux driver, which allows you to control the transmit power, scan for all available 802.11 networks, and so on. Another nice feature with the Cisco 350 is that you can store the WEP keys in flash memory, so that you can lend the card to house guests, without needing to reveal the WEP key. (Right now, I haven't been able to find an open source radius server that supports LEAP, so I'm using a combination of 128-bit WEP keys plus MAC address access controls. One nice thing about the 350 Access Point, as compared to the Apple airport, is that you can change WEP keys without needing to reboot the access point. So while I haven't implemented it yet, it should be possible for me to automate changing the WEP key every 24 hours, by calculating a MD5 hash of a secret plus a timestamp. That way, a shell script on my Linux laptop would allow me to get update the WEP key at the same time, automatically.)
A URL to a page describing the circumstances of his death, complete with links to the FAA report and where donations in lieu of flowers can be sent can be found at http://www.puffin.com/puffin/lnz/Leonard.htm.
Leonard was a good friend of mine. He will be missed.
FCC regulations (authorized by the Communications Act of 1934) require that company provide 60 days notice before terminating telecommunications services. This has been interpreted more recently to mean notice before cutting off voice or data services, and means that even in the case of a chapter 7 bankruptcy, the bankruptcy trustee isn't allowed to just sell all of the assets and leave customers hanging high and dry.
Furthermore, in WorldCon^Hm's case, they will almost certainly be filing for a chapter 11, which means they are trying to reorganize debts, and not shutdown the business. In a chapter 11, the advantage is that Worldcom will paradoxically be more able to get financing after they file for bankruptcy, since lenders know that they won't be screwed by past debts.
(Bankruptcy essentially creates a two legal companies from the perspective of debt --- before the bankruptcy and after the bankruptcy. It means that equity shareholders will be completely screwed, and that debt holders will be partially screwed, but hopefully the company will emerge from bankruptcy able to pay its bills. That means that creditors that lend a company money after the bankruptcy have more of a chance to get paid --- which means that suppliers will more likely be willing to give WorldCom credit, and banks will be more likely to give WorldCom short-term loans, etc.)
Now, I'm not Chinese so my opinion counts for little here, but my impression is that Unicode isn't nearly as controversial as he makes
it out. His analogy "To express it in Western terms, how would English-speakers like it if we were suddenly restricted to an alphabet
which is missing five or six of its letters because they could be considered "similar" (such as "M" and "N" sounding and looking so
much like each other) and too "complex" ("Q" and "X" - why, they are the nothing more a fancier "C" and an "Z")." ignores the fact
that Chinese orthography has a tradition of simplification and variants. I suspect Unicode is a lot more upsetting to a "reference writer
specializing in rare Taoist religious texts and medical works" than to ordinary Chinese users who want to run Photoshop or put their
wedding pictures on a web page.
Actually his original nalogy was flawed and designed to yank people's chain... A better analogy of what's going on would be to say that the Germans and the French wanted to have their own Unicode code point for the letter "A", since obviously the German A is very different from the French A. Repeat for all the letters in the alphabet. The excuses for saying that the German "A" should have a different value than a French "A" is (a) The Germans and the French hate each other, and (b) French tend to use a sans-serif'ed font. When told by the standards committee that font issues were independent of Unicode assignment, the response was this was obviously anti-European imperialism....
That's basically what's going on here with the folks who are complaining about Han Unification. Many Asian languages are desended originally from Chinese, just as many European languages are descended from Latin and Germanic roots. So it's not surprising that the systems of orthography share a lot in common. The difference is that each Asian country refuses to share any codepoints with any other Asian country, because They Hate Each Other, and there seems to be some widespread belief that doing so would somehow be causing their national language to lose face.
As someone who's Chinese, I think I can safely say to those people who like to bitch and moan about Han Unification..... Grow up!
Err., no. The URL has the year (2001, in a non-Y2K compliant format), and the month (April). The Index page shows that the reply was posted on the same day that Master Card letter was received, April 9, 2001.
Unfortunately, as far as I can tell, this is for real. And a good reason why Shakespeare had it right when he said that the first thing that should be done is to kill all the lawyers.
I too, was not impressed with Seifreid's followup. He changed his arguments on a number of different issues, and completely avoided areas where he was shown to be wrong or misleading. In a formal debate session, he would have been docked massive points by the judge. It was clear he was trying to be sensationalistic, and after reading his original article, the rebuttal, and his followup, I'm left wondering how much he fundamentally understands the tradeoffs of how public key works and what's necessary to make a useful/usable system.
One very important point which hasn't been addressed to date is that if you're using RSA authentication (and not password authentication) the risks are much reduced. Also, even if you use an insecure means of getting the public key of a host, the MITM attack only applies the *first* time you contact the host. Once you have the public key stored in your known_key file, you'll know if the public key asserted by the host ever changes. That's actually a pretty strong assurance, in real life. If you ever once had a secure channel between host A and host B, if a script kiddie breaks into your next work the following month and installs desniff, you'll get the warning message about the host key changing.
Kurt Seifried's defense against this point was that he pointed out that one Windows client has a lame message which isn't as strong as the warning made by the Unix client. That's a valid complaint, but that's a complaint against a specific implementation, and not against the protocol. So much for his claims in his original article that the ssh protocol was irretrivably broken....
In the greater scheme of things, perhaps the biggest disappointment was that Slashdot posted a link to his original drivel... His original article wouldn't have passed my editorial standards.
Oops, sorry, I hit submit too soon. SE Linux is based on Red Hat 6.1, not 6.2.
And furthermore, the important thing to remember is that this is a prototype. Hopefully it will spark discussions about adding some or all of these features into Linux 2.5, and how to do so in a clean way. I've talked with the folks at the NSA, and that's one of their main goals behind doing this release.
Whatever your opinion of the NSA might be, this is going to be a real boost to fighting the argument that "an open source
operating system can't be secure."
While I agree with you, it's important to make the distinction between an operating system which is secure, and an operating system which has high-security features. After all, this is based on Red Hat 6.2, and if the version of WU-FTPD they used happens to have some stack overruns, you can still break into the darned thing. Of course, the fact mandatory access controls are in place means that the attacker can't do as much damage, but letting someone have shell access even on a trusted OS is still a bad thing.
Having a high-security operating systems means that you both have to have the right set of features, *and* you still have to worry about fixing all of those little annoying stack overruns and format string bugs. Both parts of the story are very important.
Actually, they CAN'T release it under GPL! Huh? It's worse (better?) than that - It's public domain! We PAID for it.
Yes, to the extent that the work is done by government employees, this is true --- however, since it is based on GPL'ed code, only the changes to the code are in the public domain. The overall piece of work is still covered by the GPL. This is part of the "infectious nature" of the GPL.
Also, there's an absolutely trivial way to get around the "work done by government workers must be in the public domain". You just simply hire government contractors to do the work for you, in which case the rule doesn't apply any more. This is a really nasty loophole, especially since many senior government employees get tired of getting paid sh*t wages, and simply resign, and start working for a government contractors, who (after taking a cut, of course) resells that persons time back to the government at a much higher rate. It's a 100% lose all around for the taxpayer. We end up paying more for the same person's work, with a percentage cut being paid to the a third party as sheer overhead, and the work doesn't get have to get released into the public domain any more (the government contractor can resell code developed at government expense as some propietary, commercial product.) Lovely, eh? All because the idiots in Congress aren't willing to pay government workers --- especially in a hot field like software engineering --- what they're worth.
If you'll note on the NSA SE Linux web page, you'll see that some of the work was indeed done by contractors. Fortunately, thanks to the GPL, the overall work still has to be released under the GPL, if it's going to be released at all.
Re:What's wrong with both the HURD and Linux.
on
HURD For 'Big Iron'?
·
· Score: 4
Linux grew from humble beginnings, small i386 machines with little memory and scant resources. unfortunately, it's kept a
lot of baggage from those days even though it's come a long way and been ported to many architectures.
That's simply not true. Take a look at the latest kernel. It can support up to 64 Gigabytes of memory, and it can scale quite well up to 4 and 8 way SMP boxes. People have booted Linux on 32-way ccNUMA machines. Yes, it's not optimized for ccNUMA yet, and it probably doesn't scale all that well for > 8 way SMP yet, at least for many workloads, but it's currently quite a very long way from "small i386 machines". A "small i386 machine" is orders of magnitude than the original i386 back in 1991, and a "small i386 machine" today is comporable with the vast quantity of Unix machines which are used as servers today.
A lot of the "we scale to 64 nodes" is I think more machismo more than anything else. Sure, for system vendors they have better margins than the smaller machines. But you don't sell that many of them. One of the reasons why Cray was getting killed was that they only focused on the high-end, and they got their lunch eaten by the "low-end" machines moving upwards and killing off all of their market, so that they only had one or two customers. (Or should I say "One Agency".:-)
So personally, yes, people are interested in making Linux scale to the bigger machines, but some of this I susect is either (a) because of the technical challenge (for the Linux Kernel developers) or (b) as a marketing exercise (for the non-technical folks who are interested.)
There are many things in the kernel which do things the x86 way and force the other architectures to munge the way the
native system does things so that they look like the x86 way. When I last looked at the SPARC port, the memory
management system had to jump through hoops to change the way the SPARC processors do VM so that it looked to the
rest of the kernel like the way the x86 architecture does it.. it was very inefficient. No doubt these problems haunt the other
architectures too.
That's simply not true. There is an awful lot of that "complexity" which is optimized out by the compiler. So you should take a look at the assembly language before you make these sorts of complaints. Secondly, on the UltraSparc particularly, all of the virtual memory translations have to be done in software, since the hardware basically only provides a TLB which is manually programmed by the OS. This may be the source of some of the complexity which you saw, and which is required by all operating systems for that platform. This is actually a good thing, though, since the OS can do a much better job of managing the TLB than a typical hardware platform, and there are hooks in Linux that are especially designed for the capabilities of the UltraSparc VM architecture. So to say that Linux is only optimized for the x86 architecture is very much overstating the case.
Standards are important, and yes, that's what the Linux Standards Base is trying to do. The problem, though, is that a modern OS system has a huge number of standards, and trying to formally write them down on paper is a major task. It's a lot more than just writing down the C prototypes (although even looking at the number of C functions in libc alone is frightening); it's also documenting all of the behavioural details --- what happens in the corner cases, what the error returns are, etc., etc., etc.
And even that isn't enough to catch some compatibility problems. The classic problem in the libc 5.x days was one the stdio implementation was "cleaned up". Unfortunately, the rewrite caused programs that happened to fclose() a file pointer twice to core dump --- and netscape happened to be one of these programs. Now, calling fclose() twice violates the ANSI C specifications. It was clearly netscape which was in the wrong. But as far as users were concerned, when they upgraded to the latest version of libc 5.x, netscape broke, so it was obviously libc's fault. And from the point of view of an ISV, it's very uncomfortable to have to supply programs to a platform which can unpredictably change the rules of what's acceptable or not, even if you're in the wrong. Even the breaking of bug-comaptiblity has to be done during major version number bumps, under very carefully controlled circumstances.
Yes, this is hard; but if Linux is going to play in the big leagues, that's what's we're going to need if we want the likes of Intuit to make programs like TurboTax or Quicken to be available on Linux. (And I very much doubt that the Open Source community is going to ever provide an OSS version of TurboTax --- because it's more about having tax accounts and lawyers, which don't come cheap, and because tax code is constantly mutating.)
The other important thing to remember is that having 10 different distributions all tracking the same bug fixes in glibc and gcc and shellutils and textutils is a waste of engineering resources. Distributions distinguish each other by their installer, and their system administration tools, etc. They don't distinguish themselves (at least in a positive way, anyway) by which version of gawk or glibc or gcc they ship --- and happily enough, that's the sort of thing which standardizing will help the ISV compatibility problem.
So it's a win-win-win solution. The distributions win, because they can reduce their engineering costs. The ISV's win because they can only ship one version of their application, instead of one version for Red Hat, one version for Debian, one version for SuSE, etc. And the users win, because Linux remains unified, instead of getting fragmented like the other Unices did the last time the Unix wars were fought. (And remember, whenever we engage in this kind of intermural fighting, Microsoft ends up winning.)
Anyway, with what was shipped in the public beta two months ago I can't understand why the release surprised anybody. Going back
from KDE2 because it was just too buggy is one thing (it's included as a preview, though), but changing one of the major subsystems like
glibc or the compiler after that was obviously not going to happen.
I asked a friend of mine (in kernel development) who worked at Red Hat, because I was concerned about the use of the prerelease glibc, and I was told, oh, don't worry; it's just a beta, if there are too many problems, or if the final release hasn't been released in time, it'll get backed out. So I held my peace. In retrospect, I probably should have pushed this issue harder with other Red Hat contacts at the time.
So yes, it wasn't a complete surprise, but I was still disappointed how many prelease snapshots of many major packages (XFree86, glibc, gcc, etc.) were in the 7.0 release.
As far as compatibility goes, glibc is the great challenge and C++ not that important: When binary compatibity is a high priority goal,
C++ has never been an option when developing for Linux.
You're right that glibc compatibility is more important, and I am hoping and praying that Ulrich Drepper doesn't see fit to make any changes that break compatibility between glibc 2.1.94 and glibc 2.2 (since RedHat released a pre-release beta snapshot of glibc as well in 7.0). I've asked on various mailing lists, and I worry that Ulrich has conspicuously not pledged not to make any compatibility changes. Shiver
Still, there are quite a few applications that are written in C++, and like it or not, ABI compatibility is going to get more and more important as more and more people outside the traditional Linux user base reach out and start using Linux. This is a good thing, but it means we have to be more careful in what we release, going forward.
And I'm sorry if people think I'm picking on Red Hat. I still use Red Hat on most of my machines, and I've been using Red Hat since its 2.0 release. I'm a stockholder of Red Hat, and I have many friends who work there. But to the extent that Red Hat is a market leader in the U.S., it means that its responsibilities are greater, and it needs to be held to a higher standard --- just as Microsoft has to be held to a higher standard because it is also in a dominant market position.
The problem with the strategy which RedHat has embarked upon is that RedHat has always committed to keeping full binary compatibility during a particular major release series. So there was full binary compatibility between 5.0, 5.1, and 5.2, and between 6.0, 6.1, 6.2.
By prematurely going to a pre-release "GCC 2.96" which will not compatible with the eventual GCC 3.0, it will force Red Hat to continue to maintain the same random development snapshot through the entire 7.x series --- which if past history is any guide, might be a year or two, even if GCC 3.0 by some miracle ships in a few months.
Worse yet, it puts the other distributions in one heck of an interesting dilemma. Do they follow RedHat and use the same non-GCC supported compiler? Or do they use GCC 2.95, and then be incompatible with binaries compiled for RedHat 7.0 that happen to use C++ and shared libraries?
As we have seen in the past, the Red Hat marketroids have tried very hard to pursuade ISV's to make binaries available for Red Hat, and they've tried very hard to get the rest of the industry to believe that Red Hat === Linux.
I can't necessarily fault them for that; they have a fiduciary responsibility to their shareholders, and such microsoft-like tactics are the best way to build the RedHat brand. After all, at the recent open-source conference, Michael Tiemann boasted, "The Linux distribution game is over. Red Hat has won that game. Red Hat is the market leader in virtually every respect." (I suppose this ignores SuSe in Europe, or TurboLinux in Asia, but whatever.)
So ultimately, having them choose something with a non-standard ABI that's not going to be supported by the Open Source project, even if it is only for C++, is quite troubling.
$50K isn't that great if you have to live in an area with a high cost of living, which happens to be where many of the tech jobs are. I could make substantially more money in New York City or Silicon Valley, but my standard of living would decrease.
True, but that's just the common starting salary for techies. I've heard stories of people with only a 4-year MIT Undergraduate degree getting six-figure ($100,000+) salaries in Silicon Valley --- fresh out of school with no experience!
People who complain that techies aren't getting paid enough don't get much sympathy from me, when compared against what the rest of the country is earning. Not that I'm complaining, mind you. I'm very grateful that what I happen to love doing happens to be something which is in high demand, and so therefore I can command a somewhat higher salary than friends of mine who work just as hard, and who have more years of education than I, but whose vocation happens to be in music or theatre.
Most musicians I know would be thrilled to earn as much as $50,000/year, even if they had to live in New York City.
It's imporant to keep a sense of perspective in these things.
The key is that they WILL NOT pay a US tech what they need to survive.. $50K to start? Hell yes, that is the low end... you try and raise a family on $50K.
I've got news for you. $50k is the median salary for a family in the U.S. That's right, if you have two children and earning $50k/year (sometimes that's with two earners together bring in that much, with latchkey kids who come home with no one to greet them or supervise them after school), you are very squarely in the middle class in the United States. Statistically, 50% of the families will be earning more than you, and 50% of the families will be earning less.
Comments about how $50,000 as a starting salary is "not enough for a US tech to survive" is the sort of things which cause the rest of the country to regard us as spoiled brats. And you know, perhaps they're right.
The New York Times did a case study of 4 "middle-class" families and how they worked to make ends meet, and what their dreams and aspirations were. It was entitled "The American Middle, Just Getting By", and it was published on August 1, 1999 (front page of section 3). I strongly recommend that techies either download it from the NY Times web page (for $2.50), or go to the library and look at it in the archives (which is better 'cause it's free and the NY Times archives doesn't have the color pictures that went with the story). It's guaranteed to give you a better perspective about how the rest of the country lives. Non U.S. techies I suspect will; also find it revealing.
One of the things which this guy's analysis leaves out is there are many different types of "I/T Workers", and what might be true for one class of techies might not be true for others. There's a big difference between someone who is a systems programmer, an SAP R/3 or Oracle Financials Business Programmer, an Oracle DBA, or a Web HTML/Code Fusion/PHP jockey.
So when we talk about there being plenty of "older programmers" in the U.S., do they have the right skill set? Are they willing to learn the latest stuff? It doesn't help if we have a lot of mainframe programmers, for example. I remember one fellow in particular who thought that $30,000 for a web server that ran on an IBM mainframe was cheap, and wasn't it cool that he could put his project web page on the mainframe? I didn't have the heart to tell him that that much money would have purchased several cheap Unix/Linux boxes for which Apache would be free.
I also think that the issue of "ageism" is a red herring. (The "I can run a web server on a mainframe guy" wasn't over 30.) There are plenty of younger programmers who don't know what the heck they are doing; there are also plenty of really smart people who happy to be fairly light in their years (take Linus Torvalds, for example; he's well under 30). Similarly, there are plenty of older folks who stuck in the mud, not willing to learn anything new beyond the Cobol of their youth, and there are also those folks who might be chronologically young, but who are always willing to learn the latest stuff, and who have the benefit of learning certain lessons the hard way, and whose hard-earned experience is extremely valuable. It works both ways.
Speaking as someone who has been on both sides of the management/technical fence, it's not so easy to find competent engineers. Sure you can pay more money, but that isn't necessarily going to do it. In the Silicon Valley, companies are paying huge amounts of money for engineers, and from what I can tell, they still have large numbers of positions going unfilled.
As for me as a purely technical engineer, I'm not particularly worried about having foreigners compete with me for jobs. There will always be a need for really good, competent engineers. The real risk comes to those who just know how to do HTML, or just know how to futz with Microsoft Front Page, and who calls him or herself "an I/T worker". When the oversupply of I/T workers hits (and it will --- give it 5 or 10 years), those folks will be out of a job, because if you're still only doing HTML jockeying when you're 45, you have rocks for brains if you think that your seniority means that you deserve more money than the someone fresh out of college who can do the same thing. Companies pay people for what their jobs are worth, not just because they've warmed the same seat in a company for 15 years. (Or at least, they should. The reason why many engineers I know dislike unions is because they haven't figured out that this seniority pay thing is abhorrent to most engineers. That concept might work for the Teamsters, but not for engineers.)
Slashdot Mirror
So given that this is a new release of GNOME, which means that each release has to have less functionality than the previous one, so it can be "easy to use", the obvious question to ask is, "What got left on the cutting room floor this time?"
The slashdot editor was doing his job; writing provocative headlines that cause people to click on the story and generate revenue for the OSTG. Any other questions? :-)
IBM definitely contributes more in the way of core kernel functionality (it's not just JFS, but also we have a number of engineers, myself included, who publically contribute on LKML and on ext2-devel on the ext2/3 filesystem). I'd have to think hard to think of any HP kernel contributors, besides the folks who work on the architecture-specific Itanium code.... (thinking....) Nope, got nothing.
That being said, I do have to give snaps to HP for employing Keith Packard and Jim Gettys. Keith in particular has been pretty much the only X developer that has been working on new core features in X11 for the past couple of years.
But in the final analysis, between IBM making 500 patents available, and all of the IBM developers contributing various enhancements to the linux Kernel, it's really not at all surprising that more people think of IBM when it comes to Linux.
Only the core C# VM is an ECMA standard. That's about as useful as the Java byte code langage without any of the Java classes. Or the Perl VM without all of CPAN. By itself, what is "open" and promised to be patent free is only the very core of .NET, which is totally useless as a stand-alone piece. It's just enouh to sucker the foolish into a bait and switch game.
.NET, and that (b) those patents should only be used for creating implementations which are interoperable with the .NET protocols.
If Microsoft is truly interested in using the patents only for defensive purposes, then they offer a perpetual, non-revocakable license to all of these patents, subject to the following conditions (a) that patent licensees do not sue Microsoft over patent violations in
But I'm willing to bet several cases of virtual beer that this will never happen, because I believe, as many industry analysts and columnists also believe, that the main purpose of Longhorn is a full-frontal assault on Linux and the entire Open Source Software Stack --- and that in Microsoft's mind, it is war, and that any means, fair or foul, is allowed in this "War on OSS".
This is true. But consider that this is what CLEC's do when they do SDSL. For a long time, I had to use SDSL because because my house was too far away from the Central Office (CO) for ADSL. The problem is that SDSL is substantially more expensive. I was paying $227/month for 384k symmetric. Compare that with $99/month for 1.5mbps down / 768k up, and you can see that SDSL is over twice as expensive for substantially less bandwidth. Now, some of this cost might be differential in cost of the equipment between SDSL and ADSL, and some of this might be because businesses generally want SDSL, so ISP's feel free to gauge them. But at least some of the difference must be the cost of the local loop.
Now, this being said, presumably the local bells won't be able to get away with charging more than the cost of a separate voice line, since that normally represents the cost of a copper pair plus the cost of the normal voice service. Of course, the local bells might claim that given that they often use multiplexors to multiplex several voice channels onto a single copper or fiber loop, that the cost of providing a voice connection is much less than $30/month, but the cost of the copper loop is $$$. Ultimately, we simply don't know. The big question is what kind of rates will companies like Covad be able to negotiate with its local bells for the whole copper loop.
That Slashdot chose to include the entire press release (since that is what this clear was) as part of the slashdot article. A pointer to a web page, perhaps --- the fact that Phil Zimmerman is behind a new commercial product that competes with original commercial version of PGP, perhaps. But the entire press release? Please! Why give them free advertising? (I'm assuming here that this wasn't a new way for the OSDN to raised revenues by getting an entire Slashdot article with arbitrary content from a marketing organization in exchange for $$$).
In any case, it's not really clear this story is all that interesting as news anyway, for the very simple reason that it is very doubtful that commercial versions of PGP will succeed, simply becuase for the naive user, PGP is Just Too Hard to use. The moment you have to explain certification chains to users, you've lost. The naive user (the ones who can't figure out how to set the time on their VCR's) simply won't be able to cope. And for the expert users, they'll just simply download GPG, or perhaps the old version of PGP 2.6.2. Why should they pay $$$ for a commercial command-line version?
There are two sides to every story. And so far, we've only heard Kevin Mitnick's side of the story. However, just simply listening to his claims, it's pretty clear that (a) Markoff gave him the opportunity to comment, and (b) Mitnick refused to do so unless he was paid. In the journalistic profession, it's only the dubious papers such as National Enquirer and World Wide Weekly news which are known for paying their sources for information (which can result in the obvious potential conflict of interest for the sources), so Markoff refused.
Mitnick called this "blackmail", but IMHO it sounds like he either didn't know how the journalistic world works, or is trying to cast doubt on Markoff's reporting by casting him as a demon.
Mitnck, for example, complains that Markoff was (falsely) told by one or both of his co-spirators, Steven Rhoads and Lenny Dicicco that he had hacked into NORAD in 1983. Well, that might or might not be true, but it's certainly not an "un-sourced allegation". And we don't know whether or not Markoff contacted NORAD, and regardless of whether or nor he did, but in some sense, if it was a sucessful penetration, NORAD would have no idea that they had been hacked in the first place. So much for Mitnick's complaints that Markoff should have verified the "authenticity of their claims with the alleged victims". The victims very likely wouldn't have known, one way or another!
Ultimately, a reporter stands or falls by his sources, and what an editor will do is to make sure that the editor has gotten his information from his sources, and whenever possible make sure that enough information about the sources of information is disclosed in the reporter's story so that the reader can judge for him- or her-self whether or not to believe the facts of the story.
After all, if someone asked Clinton to comment about Monica, and he refused unless he got $$$, most people would consider that quite improper. But when Mitnick tried to do the same thing (unsuccessfully), people think that he's being victimized somehow. Well, he's not. That's just not how the world works.
I agree with everything Bruce has said. I want to add one note, however. There's a much better workaround to allow RF patent licenses to be used with GPL code --- which is to simply license the code under the GPL V1 (only) license! The GPL V1 license doesn't have that pesky clause #7 referring to patents in it. (Well, it has a clause #7, but it's just the "FSF may publish revisions, and you can either specify whether you want to use only V1 or allow the FSF to change the licensing terms of your program as they see fit.)
I don't think you need to worry. What Linksys is doing is not nearly as interesting as people might assume (which is I suppose is par for the course for Slashdot :-) What I'm pretty sure is going on is that the wireless access point on the linksys doesn't have a very strong radio transmitter to begin with (I'm guessing 30-50mW), and the signal amplifer just raises the transmit power to the max legal limit for the 2.4GHz band.
The Cisco 350 Access Point (and wireless cards) has better receive sensitivity (I don't know if that's due to a better built-in antenna, or better radio circuity, or both), and a stronger transmit power than most other 802.11 cards (selectable from 5mw to 100mW). In contrast, the Lucent Wavelan Silver card has a 31 mW transmitter. I don't know what the transmit power for the Linksys access point, since it's not listed on the web site or in the user's guide, but they claim an outdoor range of 1500 feet at 1 Mbps, and 500 feet at 11 Mbps. For comparison, the Orinocco access point claims 1750 feet at 1 Mbps, and 525 feet at 11 Mbps, and the Cisco 350 access point claims an outdoor range of 2000 feet at 1 Mbps and 800 feet at 11 Mbps. If we assume that both Cisco and Linksys are exagerating to an equal extent for the best case scenario, it seems pretty clear that the Lucent transmitter is less powerful than the Cisco 350.
Of course, as radio amateurs know, transmitter power doesn't have as much effect on range as some people might think. That's why QRP operators can sometimes communicate with people halfway across the globe with only a Watt or two of power. So the Linksys signal amplifier will probably not make that much of a difference.
That being said, I would recommend the Cisco 350, not because of the higher transmit power, but because the access point has better manageability (you have much finer control over how the access point operates, with various nice features such as having the AP ask your radius server whether or not a particular MAC address should be allowed, LEAP authentication/encryption, etc.). Also the Cisco 350 PC card has a full-featured Linux driver, which allows you to control the transmit power, scan for all available 802.11 networks, and so on. Another nice feature with the Cisco 350 is that you can store the WEP keys in flash memory, so that you can lend the card to house guests, without needing to reveal the WEP key. (Right now, I haven't been able to find an open source radius server that supports LEAP, so I'm using a combination of 128-bit WEP keys plus MAC address access controls. One nice thing about the 350 Access Point, as compared to the Apple airport, is that you can change WEP keys without needing to reboot the access point. So while I haven't implemented it yet, it should be possible for me to automate changing the WEP key every 24 hours, by calculating a MD5 hash of a secret plus a timestamp. That way, a shell script on my Linux laptop would allow me to get update the WEP key at the same time, automatically.)
-Ted (N1ZSU)
A URL to a page describing the circumstances of his death, complete with links to the FAA report and where donations in lieu of flowers can be sent can be found at
http://www.puffin.com/puffin/lnz/Leonard.htm.
Leonard was a good friend of mine. He will be missed.
... and panic.
FCC regulations (authorized by the Communications Act of 1934) require that company provide 60 days notice before terminating telecommunications services. This has been interpreted more recently to mean notice before cutting off voice or data services, and means that even in the case of a chapter 7 bankruptcy, the bankruptcy trustee isn't allowed to just sell all of the assets and leave customers hanging high and dry.
Furthermore, in WorldCon^Hm's case, they will almost certainly be filing for a chapter 11, which means they are trying to reorganize debts, and not shutdown the business. In a chapter 11, the advantage is that Worldcom will paradoxically be more able to get financing after they file for bankruptcy, since lenders know that they won't be screwed by past debts.
(Bankruptcy essentially creates a two legal companies from the perspective of debt --- before the bankruptcy and after the bankruptcy. It means that equity shareholders will be completely screwed, and that debt holders will be partially screwed, but hopefully the company will emerge from bankruptcy able to pay its bills. That means that creditors that lend a company money after the bankruptcy have more of a chance to get paid --- which means that suppliers will more likely be willing to give WorldCom credit, and banks will be more likely to give WorldCom short-term loans, etc.)
Actually his original nalogy was flawed and designed to yank people's chain... A better analogy of what's going on would be to say that the Germans and the French wanted to have their own Unicode code point for the letter "A", since obviously the German A is very different from the French A. Repeat for all the letters in the alphabet. The excuses for saying that the German "A" should have a different value than a French "A" is (a) The Germans and the French hate each other, and (b) French tend to use a sans-serif'ed font. When told by the standards committee that font issues were independent of Unicode assignment, the response was this was obviously anti-European imperialism....
That's basically what's going on here with the folks who are complaining about Han Unification. Many Asian languages are desended originally from Chinese, just as many European languages are descended from Latin and Germanic roots. So it's not surprising that the systems of orthography share a lot in common. The difference is that each Asian country refuses to share any codepoints with any other Asian country, because They Hate Each Other, and there seems to be some widespread belief that doing so would somehow be causing their national language to lose face.
As someone who's Chinese, I think I can safely say to those people who like to bitch and moan about Han Unification..... Grow up!
I would say it is a joke, nothing more.
The reply is dated April, 1 (as seen in the URL).
Err., no. The URL has the year (2001, in a non-Y2K compliant format), and the month (April). The Index page shows that the reply was posted on the same day that Master Card letter was received, April 9, 2001.
Unfortunately, as far as I can tell, this is for real. And a good reason why Shakespeare had it right when he said that the first thing that should be done is to kill all the lawyers.
I too, was not impressed with Seifreid's followup. He changed his arguments on a number of different issues, and completely avoided areas where he was shown to be wrong or misleading. In a formal debate session, he would have been docked massive points by the judge. It was clear he was trying to be sensationalistic, and after reading his original article, the rebuttal, and his followup, I'm left wondering how much he fundamentally understands the tradeoffs of how public key works and what's necessary to make a useful/usable system.
One very important point which hasn't been addressed to date is that if you're using RSA authentication (and not password authentication) the risks are much reduced. Also, even if you use an insecure means of getting the public key of a host, the MITM attack only applies the *first* time you contact the host. Once you have the public key stored in your known_key file, you'll know if the public key asserted by the host ever changes. That's actually a pretty strong assurance, in real life. If you ever once had a secure channel between host A and host B, if a script kiddie breaks into your next work the following month and installs desniff, you'll get the warning message about the host key changing.
Kurt Seifried's defense against this point was that he pointed out that one Windows client has a lame message which isn't as strong as the warning made by the Unix client. That's a valid complaint, but that's a complaint against a specific implementation, and not against the protocol. So much for his claims in his original article that the ssh protocol was irretrivably broken....
In the greater scheme of things, perhaps the biggest disappointment was that Slashdot posted a link to his original drivel... His original article wouldn't have passed my editorial standards.
Oops, sorry, I hit submit too soon. SE Linux is based on Red Hat 6.1, not 6.2.
And furthermore, the important thing to remember is that this is a prototype. Hopefully it will spark discussions about adding some or all of these features into Linux 2.5, and how to do so in a clean way. I've talked with the folks at the NSA, and that's one of their main goals behind doing this release.
Whatever your opinion of the NSA might be, this is going to be a real boost to fighting the argument that "an open source operating system can't be secure."
While I agree with you, it's important to make the distinction between an operating system which is secure, and an operating system which has high-security features. After all, this is based on Red Hat 6.2, and if the version of WU-FTPD they used happens to have some stack overruns, you can still break into the darned thing. Of course, the fact mandatory access controls are in place means that the attacker can't do as much damage, but letting someone have shell access even on a trusted OS is still a bad thing.
Having a high-security operating systems means that you both have to have the right set of features, *and* you still have to worry about fixing all of those little annoying stack overruns and format string bugs. Both parts of the story are very important.
Actually, they CAN'T release it under GPL! Huh? It's worse (better?) than that - It's public domain! We PAID for it.
Yes, to the extent that the work is done by government employees, this is true --- however, since it is based on GPL'ed code, only the changes to the code are in the public domain. The overall piece of work is still covered by the GPL. This is part of the "infectious nature" of the GPL.
Also, there's an absolutely trivial way to get around the "work done by government workers must be in the public domain". You just simply hire government contractors to do the work for you, in which case the rule doesn't apply any more. This is a really nasty loophole, especially since many senior government employees get tired of getting paid sh*t wages, and simply resign, and start working for a government contractors, who (after taking a cut, of course) resells that persons time back to the government at a much higher rate. It's a 100% lose all around for the taxpayer. We end up paying more for the same person's work, with a percentage cut being paid to the a third party as sheer overhead, and the work doesn't get have to get released into the public domain any more (the government contractor can resell code developed at government expense as some propietary, commercial product.) Lovely, eh? All because the idiots in Congress aren't willing to pay government workers --- especially in a hot field like software engineering --- what they're worth.
If you'll note on the NSA SE Linux web page, you'll see that some of the work was indeed done by contractors. Fortunately, thanks to the GPL, the overall work still has to be released under the GPL, if it's going to be released at all.
Linux grew from humble beginnings, small i386 machines with little memory and scant resources. unfortunately, it's kept a lot of baggage from those days even though it's come a long way and been ported to many architectures.
That's simply not true. Take a look at the latest kernel. It can support up to 64 Gigabytes of memory, and it can scale quite well up to 4 and 8 way SMP boxes. People have booted Linux on 32-way ccNUMA machines. Yes, it's not optimized for ccNUMA yet, and it probably doesn't scale all that well for > 8 way SMP yet, at least for many workloads, but it's currently quite a very long way from "small i386 machines". A "small i386 machine" is orders of magnitude than the original i386 back in 1991, and a "small i386 machine" today is comporable with the vast quantity of Unix machines which are used as servers today.A lot of the "we scale to 64 nodes" is I think more machismo more than anything else. Sure, for system vendors they have better margins than the smaller machines. But you don't sell that many of them. One of the reasons why Cray was getting killed was that they only focused on the high-end, and they got their lunch eaten by the "low-end" machines moving upwards and killing off all of their market, so that they only had one or two customers. (Or should I say "One Agency". :-)
So personally, yes, people are interested in making Linux scale to the bigger machines, but some of this I susect is either (a) because of the technical challenge (for the Linux Kernel developers) or (b) as a marketing exercise (for the non-technical folks who are interested.)
There are many things in the kernel which do things the x86 way and force the other architectures to munge the way the native system does things so that they look like the x86 way. When I last looked at the SPARC port, the memory management system had to jump through hoops to change the way the SPARC processors do VM so that it looked to the rest of the kernel like the way the x86 architecture does it.. it was very inefficient. No doubt these problems haunt the other architectures too.
That's simply not true. There is an awful lot of that "complexity" which is optimized out by the compiler. So you should take a look at the assembly language before you make these sorts of complaints. Secondly, on the UltraSparc particularly, all of the virtual memory translations have to be done in software, since the hardware basically only provides a TLB which is manually programmed by the OS. This may be the source of some of the complexity which you saw, and which is required by all operating systems for that platform. This is actually a good thing, though, since the OS can do a much better job of managing the TLB than a typical hardware platform, and there are hooks in Linux that are especially designed for the capabilities of the UltraSparc VM architecture. So to say that Linux is only optimized for the x86 architecture is very much overstating the case.
Standards are important, and yes, that's what the Linux Standards Base is trying to do. The problem, though, is that a modern OS system has a huge number of standards, and trying to formally write them down on paper is a major task. It's a lot more than just writing down the C prototypes (although even looking at the number of C functions in libc alone is frightening); it's also documenting all of the behavioural details --- what happens in the corner cases, what the error returns are, etc., etc., etc.
And even that isn't enough to catch some compatibility problems. The classic problem in the libc 5.x days was one the stdio implementation was "cleaned up". Unfortunately, the rewrite caused programs that happened to fclose() a file pointer twice to core dump --- and netscape happened to be one of these programs. Now, calling fclose() twice violates the ANSI C specifications. It was clearly netscape which was in the wrong. But as far as users were concerned, when they upgraded to the latest version of libc 5.x, netscape broke, so it was obviously libc's fault. And from the point of view of an ISV, it's very uncomfortable to have to supply programs to a platform which can unpredictably change the rules of what's acceptable or not, even if you're in the wrong. Even the breaking of bug-comaptiblity has to be done during major version number bumps, under very carefully controlled circumstances.
Yes, this is hard; but if Linux is going to play in the big leagues, that's what's we're going to need if we want the likes of Intuit to make programs like TurboTax or Quicken to be available on Linux. (And I very much doubt that the Open Source community is going to ever provide an OSS version of TurboTax --- because it's more about having tax accounts and lawyers, which don't come cheap, and because tax code is constantly mutating.)
The other important thing to remember is that having 10 different distributions all tracking the same bug fixes in glibc and gcc and shellutils and textutils is a waste of engineering resources. Distributions distinguish each other by their installer, and their system administration tools, etc. They don't distinguish themselves (at least in a positive way, anyway) by which version of gawk or glibc or gcc they ship --- and happily enough, that's the sort of thing which standardizing will help the ISV compatibility problem.
So it's a win-win-win solution. The distributions win, because they can reduce their engineering costs. The ISV's win because they can only ship one version of their application, instead of one version for Red Hat, one version for Debian, one version for SuSE, etc. And the users win, because Linux remains unified, instead of getting fragmented like the other Unices did the last time the Unix wars were fought. (And remember, whenever we engage in this kind of intermural fighting, Microsoft ends up winning.)
I asked a friend of mine (in kernel development) who worked at Red Hat, because I was concerned about the use of the prerelease glibc, and I was told, oh, don't worry; it's just a beta, if there are too many problems, or if the final release hasn't been released in time, it'll get backed out. So I held my peace. In retrospect, I probably should have pushed this issue harder with other Red Hat contacts at the time.
So yes, it wasn't a complete surprise, but I was still disappointed how many prelease snapshots of many major packages (XFree86, glibc, gcc, etc.) were in the 7.0 release.
You're right that glibc compatibility is more important, and I am hoping and praying that Ulrich Drepper doesn't see fit to make any changes that break compatibility between glibc 2.1.94 and glibc 2.2 (since RedHat released a pre-release beta snapshot of glibc as well in 7.0). I've asked on various mailing lists, and I worry that Ulrich has conspicuously not pledged not to make any compatibility changes. Shiver
Still, there are quite a few applications that are written in C++, and like it or not, ABI compatibility is going to get more and more important as more and more people outside the traditional Linux user base reach out and start using Linux. This is a good thing, but it means we have to be more careful in what we release, going forward.
And I'm sorry if people think I'm picking on Red Hat. I still use Red Hat on most of my machines, and I've been using Red Hat since its 2.0 release. I'm a stockholder of Red Hat, and I have many friends who work there. But to the extent that Red Hat is a market leader in the U.S., it means that its responsibilities are greater, and it needs to be held to a higher standard --- just as Microsoft has to be held to a higher standard because it is also in a dominant market position.
The problem with the strategy which RedHat has embarked upon is that RedHat has always committed to keeping full binary compatibility during a particular major release series. So there was full binary compatibility between 5.0, 5.1, and 5.2, and between 6.0, 6.1, 6.2.
By prematurely going to a pre-release "GCC 2.96" which will not compatible with the eventual GCC 3.0, it will force Red Hat to continue to maintain the same random development snapshot through the entire 7.x series --- which if past history is any guide, might be a year or two, even if GCC 3.0 by some miracle ships in a few months.
Worse yet, it puts the other distributions in one heck of an interesting dilemma. Do they follow RedHat and use the same non-GCC supported compiler? Or do they use GCC 2.95, and then be incompatible with binaries compiled for RedHat 7.0 that happen to use C++ and shared libraries?
As we have seen in the past, the Red Hat marketroids have tried very hard to pursuade ISV's to make binaries available for Red Hat, and they've tried very hard to get the rest of the industry to believe that Red Hat === Linux. I can't necessarily fault them for that; they have a fiduciary responsibility to their shareholders, and such microsoft-like tactics are the best way to build the RedHat brand. After all, at the recent open-source conference, Michael Tiemann boasted, "The Linux distribution game is over. Red Hat has won that game. Red Hat is the market leader in virtually every respect." (I suppose this ignores SuSe in Europe, or TurboLinux in Asia, but whatever.)
So ultimately, having them choose something with a non-standard ABI that's not going to be supported by the Open Source project, even if it is only for C++, is quite troubling.
True, but that's just the common starting salary for techies. I've heard stories of people with only a 4-year MIT Undergraduate degree getting six-figure ($100,000+) salaries in Silicon Valley --- fresh out of school with no experience! People who complain that techies aren't getting paid enough don't get much sympathy from me, when compared against what the rest of the country is earning. Not that I'm complaining, mind you. I'm very grateful that what I happen to love doing happens to be something which is in high demand, and so therefore I can command a somewhat higher salary than friends of mine who work just as hard, and who have more years of education than I, but whose vocation happens to be in music or theatre. Most musicians I know would be thrilled to earn as much as $50,000/year, even if they had to live in New York City. It's imporant to keep a sense of perspective in these things.
I've got news for you. $50k is the median salary for a family in the U.S. That's right, if you have two children and earning $50k/year (sometimes that's with two earners together bring in that much, with latchkey kids who come home with no one to greet them or supervise them after school), you are very squarely in the middle class in the United States. Statistically, 50% of the families will be earning more than you, and 50% of the families will be earning less.
Comments about how $50,000 as a starting salary is "not enough for a US tech to survive" is the sort of things which cause the rest of the country to regard us as spoiled brats. And you know, perhaps they're right.
The New York Times did a case study of 4 "middle-class" families and how they worked to make ends meet, and what their dreams and aspirations were. It was entitled "The American Middle, Just Getting By", and it was published on August 1, 1999 (front page of section 3). I strongly recommend that techies either download it from the NY Times web page (for $2.50), or go to the library and look at it in the archives (which is better 'cause it's free and the NY Times archives doesn't have the color pictures that went with the story). It's guaranteed to give you a better perspective about how the rest of the country lives. Non U.S. techies I suspect will; also find it revealing.
One of the things which this guy's analysis leaves out is there are many different types of "I/T Workers", and what might be true for one class of techies might not be true for others. There's a big difference between someone who is a systems programmer, an SAP R/3 or Oracle Financials Business Programmer, an Oracle DBA, or a Web HTML/Code Fusion/PHP jockey.
So when we talk about there being plenty of "older programmers" in the U.S., do they have the right skill set? Are they willing to learn the latest stuff? It doesn't help if we have a lot of mainframe programmers, for example. I remember one fellow in particular who thought that $30,000 for a web server that ran on an IBM mainframe was cheap, and wasn't it cool that he could put his project web page on the mainframe? I didn't have the heart to tell him that that much money would have purchased several cheap Unix/Linux boxes for which Apache would be free.
I also think that the issue of "ageism" is a red herring. (The "I can run a web server on a mainframe guy" wasn't over 30.) There are plenty of younger programmers who don't know what the heck they are doing; there are also plenty of really smart people who happy to be fairly light in their years (take Linus Torvalds, for example; he's well under 30). Similarly, there are plenty of older folks who stuck in the mud, not willing to learn anything new beyond the Cobol of their youth, and there are also those folks who might be chronologically young, but who are always willing to learn the latest stuff, and who have the benefit of learning certain lessons the hard way, and whose hard-earned experience is extremely valuable. It works both ways.
Speaking as someone who has been on both sides of the management/technical fence, it's not so easy to find competent engineers. Sure you can pay more money, but that isn't necessarily going to do it. In the Silicon Valley, companies are paying huge amounts of money for engineers, and from what I can tell, they still have large numbers of positions going unfilled.
As for me as a purely technical engineer, I'm not particularly worried about having foreigners compete with me for jobs. There will always be a need for really good, competent engineers. The real risk comes to those who just know how to do HTML, or just know how to futz with Microsoft Front Page, and who calls him or herself "an I/T worker". When the oversupply of I/T workers hits (and it will --- give it 5 or 10 years), those folks will be out of a job, because if you're still only doing HTML jockeying when you're 45, you have rocks for brains if you think that your seniority means that you deserve more money than the someone fresh out of college who can do the same thing. Companies pay people for what their jobs are worth, not just because they've warmed the same seat in a company for 15 years. (Or at least, they should. The reason why many engineers I know dislike unions is because they haven't figured out that this seniority pay thing is abhorrent to most engineers. That concept might work for the Teamsters, but not for engineers.)