why fighting spam will remain a difficult task
on
Meet the Spammers
·
· Score: 2
This article, a lead August story at New.Architect Magazine, written by a clueless idiot who only thinks he understands technology, shows why fighting spam will remain a difficult task for the forseeable future. If he can't understand that spammers will forge email addresses, and that it's trivial to do, and that any test must do the same thing to be valid, he shouldn't even be writing in a technology oriented publication, much less be allowed to pursue such claims in court. It's people like that, that spammers love to have around.
ttyp0's point is probably that the cost of the long distance phone call is what keeps the level of junk FAX's down. Of course junk FAX costs money, and considering the paper and the phone line time, certainly even more than spam. But that cost of making the phone call at least keeps the volume in check. With costs for sending spam being on the order of $0.0001 (1/100th of a penny) or less, depending what method the spammer is using, it becomes attractive for not only anyone to get into doing it, but also for them to use the shotgun approach and use millions of addresses. And if even 0.0001% of recipients are gullible enough to respond, the spammer has at least broken even on his own costs. That run of just one million, assuming 1 second (and that's a low assumption) to delete the message, costs recipients an aggregated minimum of $1500.00 in lost time at minimum wage. In reality it often takes more time to delete, involves people who are paid more for their time, and the cost of bandwidth, server operation and system/network administrator time needs to be added in, too. The real costs are much higher.
I met Bob in January 2000. He is most definitely a cool dude. I'd rank him up there with the likes of Buckminster Fuller (of geodesic dome fame, whom I also had the pleasure to meet in person)... someone who knows a lot of things about a lot of things and understands how they affect each other. According to Bob, the Y2K issue was actually raised in the 1950's, but I don't know of any publications about it. The funny thing is, while we have a lot less software that breaks in year 2000, we have a lot that can't handle 105 year old ladies who forget to register to attend grade school, all because people want to type in 2 digits for a year.
You'll either get a perfect reception, or not at all. Because the level of information goes up relative to bandwidth, the noise immunity goes down. If the signal is strong enough to overcome the noise, it works. Where analog gave perfect reception before, it is plenty strong enough for digital to come in error-free with even more information than what the analog had. So you can get a much higher definition, or multiple channels of lower definition, in the same bandwidth. But if that signal strength is lower to where the image is somewhat snowy, the digital data will be in error, and that portion of the signal gets replaced with related previous signal. In small amounts you may never notice. A little more and you will see chunks of the image "lag" from previous frames, etc. A lot and the whole frame freezes. When it persists, you get nothing (usually a blue screen, but that's just whatever the equipment was designed to substitute). The whole point is, though, that there is a threshold of signal above which digital works, below which it fails. And that threshold, when the signal is analog, is adequate for viewing purposes and is likely to be commonly experienced in what is known as "Grade B contour" for those using OTA reception. Cable should provide better reception in most cases, but we shouldn't be forced to get cable just to get TV at all where OTA worked before.
In FreeBSD, I think jail can do this. In Linux there is an add-on called vserver that can do this (assign a private address to the context where you do the builds). Of course it can write all over the files in the chrooted directory, and that can compromize the resultant binary.
Now address the digital modulation (how the bits get into the RF spectrum). This is where HDTV falls on its face. At the same signal level where you would just minimally get a snow-free NTSC analog picture (grade B), DTV totally breaks up and you get nothing but occaisional flashes through the blue muck. The only way DTV is really going to work outside of metropolitan areas is for either the metro TV stations to crank up the power on the order of 50-100 MW-ERP, or start dropping in repeater stations around grade B areas (where previously this was only done well beyond grade B, now it will have to be done within). Another option the FCC has is to have a rule that bans any laws, restrictions, or covenants against erecting the necessary outdoor antenna to gain new signal strength. Cable is an option, but it has to stay an option; it cannot be a requirement. OTA must remain viable.
I haven't looked at the specs for today's crop of 64-bit processors. Since I started programming in C back in 1982, I've gradually weened myself off assembly language. By 1992 that was mostly complete (did a little Sparc assembly late last year). So I don't really have much motivation to invest time in understanding a new machine architecture from the CPU instruction perspective. Thus, I don't really know what today's 64-bit CPUs can, or cannot do in this regard... but...
What a good 64-bit CPU needs to be able to do includes:
Have a complete 32-bit operational mode where everything can be done.
Have access to 64-bit (and 128-bit if applicable) data operations while in 32-bit mode.
Make it possible and easy for a kernel in 64-bit mode to handle virtual processes in either 32-bit mode or 64-bit mode selectable invidually by process (e.g. would not force them all to be running the same mode).
Supporting 64-bit processes from a 32-bit kernel would be a nice touch, too, but not really essential.
Be available in varying physical bus sizes for different scales of needs in different markets, such as 32-bit for embedded to small desktop, and 64-bit to high end workstation to server to number cruncher.
Architecturally support even larger physical bus of 128-bit when times comes for that performance level to be market worthy.
Support data fetch/store operations of all sizes 8-bit, 16-bit, 32-bit, and 64-bit. A size of 128-bit would be a plus.
Fast byte order reversal instructions for all sizes.
Statefully interruptable CPU instructions to support fast MD5, RSA, AES, and other crypto needs (the world is going to be doing more and more crypto, so get used to it).
Statefully interruptable CPU instructions for codecs, including Ogg Vorbis.
Huh, where am I? Where's the light. Oh crap, it's 6:00 already. Where has the night gone. Damn, and I was having a good dream, too. Oh well, another dull day at work.
So then maybe they made it too low level to begin with. It should have been a basic message passing in the buffer kind of thing. I have not looked at the spec and I think I don't even want to in order to avoid polluting my mind. But the best approach would have been a higher level message/packet kind of thing with a few parameters to give status, identify device, device specific parameters/status, and a chunk/window of data. Things like timing and signals should be handled by the controller.
Part of the trouble is that because vendors can supply Windows drivers, they feel free to change hardware interfaces, and so, this becomes a major problem. There need to be standards in this realm, as well as other places like system calls, libraries, and protocols.
It would be more like the exploding brain syndrome. I doubt it can throw someone in the air or knock down a wall, but possibly shatter a big hole in that wall.
This is NOT for Linux. Instead, it is for Redhat and Mandrake. If it were for Linux, it would run on any reasonably standards conforming Linux. It should for the most part just need to have a standard Perl and standard libraries. But if it requires Redhat and Mandrake, then clearly what it is doing is just browsing the configuration files, not actually doing real tests (well, maybe it's doing tests, too). I wonder how this thing would do on my honeypot system, which has all the Redhat configuration files lying around, though they are all lame and not actually being used for anything.
Not only that, drivers written by hardware vendors tend to be buggier than drivers written by the OS people for the OS they will be used in. Bill Gates has even blamed much of the buggieness of Windows on this. The bugs tend to be in interfacing with the OS itself, In fact, I've even seen it myself, where selecting certain options in the HP printer driver property menu on NT would instantly blue-screen. Linux tends to have more of the latter since OS enthusiasts are doing most of the work.
OSS typically lags commercial software support, unless the hardware standards designers and hardware manufacturers work with Linux and/or Linux people right from the start. All too often, the first sample a Linux developer has to go on is bought retail the day a new product is released, and often with no hardware specs to go on. I once contacted a hardware standards group by telephone to inquire about getting a copy of the standard for development purposes. If I wasn't a member of their organization, then I'd have to pay $10,000 and sign a non-disclosure agreement. I was told membership was "very exclusive and expensive". That standard was eventually released when products came out. That was the I2O standard.
If USB (the interface that hardware presents to core driver software) had been designed well in the first place, then speed would not matter, except for content of data elements that describe speeds (e.g. a value that says this is running at 12mbps or this is running at 480mbps, or the argument to a command that says force this to run at such and such a speed). Maybe they needed to add speed information and speed control, but that wouldn't be a whole change that needs a whole new software architecture (that's something that could have been added in an overnight coding session). What you'd get is data being transferred 40 times faster with 480 mbps.
Without looking at the specs to see, it's rather obvious that the hardware people just redesigned the interface all over again. Can't someone teach those people some things about reusability and refactoring? And USB isn't the only place this happens. Of course you do need to occaisionally add something to an interface, so a tweaked driver will be needed to fully take advantage of new hardware ideas. But a whole redesign isn't called for... unless the old design was a POS. But was it the hardware or the software that was a POS? Looks to me like it was the hardware. We'll see when the next speed step occurs. Surely, the Firewire people won't stay 80Mbps down for long. They'll probably aim for somewhere in the 800 to 1600 range next, I bet (if not already). Will the next generation be compatible while still running at the higher speed?
It's not the government's place to dictate what is or is not a good business decision. What is a good decision for the nation is, though. But even then there are limits. But it might use tax incentives for that.
I hope we are not characterizing every H-1B worker as bad. Some are good. But the proportion of bad does appear to be quite high. The problem is, you don't really see how bad they are for quite some time in many cases. Too little real QA goes on, especially in software development.
The good H-1B workers are underpaid. If they are as good as the domestic worker they replaced, they should get the same salary (you know, same merit, same salary thing). But that's not happening. And the companies know that most H-1B workers won't change jobs, because of the extra paperwork and hassle of doing so, and the contract terms they are usually stuck with of paying back the first employer for a prorated cost of bringing them in. So in this captive state, an extra $5K a year isn't very interesting. And the H-1B worker isn't really interested in an extra $5K on the career track, because he's only here for 5-6 years anyway. Someone who's life is here has their career here, and moving to a better job has significance not only in the short term, but also in the long term.
Expensive, maybe so. And maybe what the lead guy needs to do is just code the whole damned thing himself and make it clear to everyone up the line to CEO that he's in there saving the company's ass to make sure the project gets delivered. Maybe, just maybe, they will reward him by firing 3 idiots and hiring 2 qualified people to replace them (at a gain in productivity). Too bad salaries get counted as expenses and executive stock options get counted as capital investments (well, not at WorldCom or Enron anymore). It should be the other way around. Then it would make financial sense to hire good people and keep them happy.
The ones with merit are the ones getting shafted. People with 30 years experience are walking out the door when someone with 1 year experience walks in to do the same job at half the pay. These H-1B legal fees you refer to amount to a little over $1000 filing fee, and a little over $1000 preparation costs. That's a bargain compared to the money savings in H-1B. It's the smaller companies that get stuck with the big fees preparing these documents because they don't know anything about it. Big companies like Microsoft, Sun, Texas Instruments, etc, have standard H-1B templates that lawyers have already researched and have proven to work. So they can run them through a mill, and they do.
Of course many H-1Bs have been laid off. But in terms of proportion, it hasn't happened to them as much as it has happened to domestic workers. And the reason is that any round of letting people go isn't just to remove the dead wood (that does happen, too), but also to cut costs. Some of the people still working at major corporations are total idiots. I've even met 2 of them. I'm not talking about rapidly certified people, I'm talking the top of the line experts who have 20-30 years experience and can do any task in their field and do it well. And it's not about changing technologies. I know a programmer with 24 years experience who was in doing Java as soon as it came out, and he got let go because "he's too expensive". Companies don't really need top level skills; they just say that so they can continue to fool the government into thinking there's a shortage of people even while 700,000 high tech people are looking for work (far more than the H-1B cap).
As long as US companies don't put US workers first in their hiring, and as long as US companies are lying about the lack of available technical people just so they can get an H-1B brought in cheap to underpay and abuse, then why the hell should I go out of my way to favor these US companies in their foreign markets. Sure, I'd like to see more jobs here, but the fact is that companies like MSFT and SUNW are still doing more of their hiring overseas or bringing people in from overseas, than local. When you look at layoff stats and see that H-1Bs are much lower in their layoff percentages than US workers, for the larger of these companies, if you can even pry the accurate information out of them, then you know that what was going on during the peak is also still going on during the slump. And its about saving money, not about getting real talent. So I'm all in favor of Peru giving MSFT the shaft, not because I dislike MSFT products, but because I'm majorly annoyed at US companies for trying to keep US workers from being part of the benefit of global markets they sell to. I hope they give SUNW the same shaft.
Who the hell hired those idiots? There are too many GOOD programmers looking for work to accept this excuse. Whoever hired them should take the responsibility as being the principle cause of the failure, and replace them on the spot. GOOD programmers can pick up on a project fast. Afterall, this is only a 20K project. That's relatively small. So this will set you back at most another month. Just do it. Please don't encourage BAD programmers to stay in the field.
Allowing specifically those that are well trained and have experience (experience is what employers are saying they demand, so it should be part of the requirement). Unfortunately, there are stories of Americans having to actually train their H-1B replacements. Not all are coming here in a way that contributes any greater than the American who would lose their job, and have to put their family on public welfare (the replacement jobs, like flipping hamburgers, does not cover the costs of raising a family).
I'm all for having the best talent from abroad come into this country. But that means we have to do something to ensure that companies don't cheat on the system (and lots of companies, especially the big ones, cheat on everything they can) and bring in less trained and inexperienced people just so they can get a cheap warm body.
And that brings up your point about the fraction of an hour processing. That's wrong. I don't dispute that it is happening that way, but I dispute that it should not be allowed to happen that way. Each application should be thoroughly reviewed, including calling up references in the applicant's home country to verify past employment, training, and education. Then the position description needs to be reviewed and compared to the current job market to ensure that there is a genuine need for that specific role. And finally, the salary level should be set not by the current method of paying just the amount a generic programmer (for any programmer) or a generic engineer (for any engineer) makes. It should be set at a level that is appropriate for the job requirements. If it is a specialized programmer job, it most certainly will be well above the current $47,000 level for a generic programmer with 2 years experience. Someone with a degree in computer science, and experience doing this sort of thing, taking on a job as a lead software engineer for a Java/Oracle/Solaris based banking job should be getting at least $85,000 to $140,000 depending on which part of the USA the job is located. Companies are currently bringing people in at the $47,000 required level (because the law is blind to measuring the worth), even in California.
I'm not opposed to the principle of H-1B at all. I am opposed to the abuse of the process, which I believe is happening in as much as 80% of cases.
There should be full investigation for each application, including a thorough non-discriminatory security investigation.
Each position to be fill must have been posted online on the company web site and at least 2 of the top 5 web job boards, for a minimum of 3 months before the H-1B process begins.
A limit of 1% of the workforce, or 5 people, whichever is higher, should be applicable to each company.
All H-1B applicants shall be given the same full benefits that all other employees get, and not expected to work any more hours than the non-H-1B employees.
After 3 months, the H-1B worker shall be free to change jobs within the country.
The above would ensure that H-1Bs are even BETTER for American, and help ensure that experienced Americans get jobs, too. Personally, I'd rather see this turned instead into a true residency program. If they are good enough to be GOOD for American, then they are good enough to stay if they want.
Slashdot Mirror
This article, a lead August story at New.Architect Magazine, written by a clueless idiot who only thinks he understands technology, shows why fighting spam will remain a difficult task for the forseeable future. If he can't understand that spammers will forge email addresses, and that it's trivial to do, and that any test must do the same thing to be valid, he shouldn't even be writing in a technology oriented publication, much less be allowed to pursue such claims in court. It's people like that, that spammers love to have around.
ttyp0's point is probably that the cost of the long distance phone call is what keeps the level of junk FAX's down. Of course junk FAX costs money, and considering the paper and the phone line time, certainly even more than spam. But that cost of making the phone call at least keeps the volume in check. With costs for sending spam being on the order of $0.0001 (1/100th of a penny) or less, depending what method the spammer is using, it becomes attractive for not only anyone to get into doing it, but also for them to use the shotgun approach and use millions of addresses. And if even 0.0001% of recipients are gullible enough to respond, the spammer has at least broken even on his own costs. That run of just one million, assuming 1 second (and that's a low assumption) to delete the message, costs recipients an aggregated minimum of $1500.00 in lost time at minimum wage. In reality it often takes more time to delete, involves people who are paid more for their time, and the cost of bandwidth, server operation and system/network administrator time needs to be added in, too. The real costs are much higher.
I met Bob in January 2000. He is most definitely a cool dude. I'd rank him up there with the likes of Buckminster Fuller (of geodesic dome fame, whom I also had the pleasure to meet in person) ... someone who knows a lot of things about a lot of things and understands how they affect each other. According to Bob, the Y2K issue was actually raised in the 1950's, but I don't know of any publications about it. The funny thing is, while we have a lot less software that breaks in year 2000, we have a lot that can't handle 105 year old ladies who forget to register to attend grade school, all because people want to type in 2 digits for a year.
You'll either get a perfect reception, or not at all. Because the level of information goes up relative to bandwidth, the noise immunity goes down. If the signal is strong enough to overcome the noise, it works. Where analog gave perfect reception before, it is plenty strong enough for digital to come in error-free with even more information than what the analog had. So you can get a much higher definition, or multiple channels of lower definition, in the same bandwidth. But if that signal strength is lower to where the image is somewhat snowy, the digital data will be in error, and that portion of the signal gets replaced with related previous signal. In small amounts you may never notice. A little more and you will see chunks of the image "lag" from previous frames, etc. A lot and the whole frame freezes. When it persists, you get nothing (usually a blue screen, but that's just whatever the equipment was designed to substitute). The whole point is, though, that there is a threshold of signal above which digital works, below which it fails. And that threshold, when the signal is analog, is adequate for viewing purposes and is likely to be commonly experienced in what is known as "Grade B contour" for those using OTA reception. Cable should provide better reception in most cases, but we shouldn't be forced to get cable just to get TV at all where OTA worked before.
In FreeBSD, I think jail can do this. In Linux there is an add-on called vserver that can do this (assign a private address to the context where you do the builds). Of course it can write all over the files in the chrooted directory, and that can compromize the resultant binary.
Actually the odds are 3409878560:1. Go do the math.
Now address the digital modulation (how the bits get into the RF spectrum). This is where HDTV falls on its face. At the same signal level where you would just minimally get a snow-free NTSC analog picture (grade B), DTV totally breaks up and you get nothing but occaisional flashes through the blue muck. The only way DTV is really going to work outside of metropolitan areas is for either the metro TV stations to crank up the power on the order of 50-100 MW-ERP, or start dropping in repeater stations around grade B areas (where previously this was only done well beyond grade B, now it will have to be done within). Another option the FCC has is to have a rule that bans any laws, restrictions, or covenants against erecting the necessary outdoor antenna to gain new signal strength. Cable is an option, but it has to stay an option; it cannot be a requirement. OTA must remain viable.
Sounds to me like they are soliciting to be "bought off".
The phone number for HP's chief legal counsel would be better. Get it. Use it.
I haven't looked at the specs for today's crop of 64-bit processors. Since I started programming in C back in 1982, I've gradually weened myself off assembly language. By 1992 that was mostly complete (did a little Sparc assembly late last year). So I don't really have much motivation to invest time in understanding a new machine architecture from the CPU instruction perspective. Thus, I don't really know what today's 64-bit CPUs can, or cannot do in this regard ... but ...
What a good 64-bit CPU needs to be able to do includes:
- Have a complete 32-bit operational mode where everything can be done.
- Have access to 64-bit (and 128-bit if applicable) data operations while in 32-bit mode.
- Make it possible and easy for a kernel in 64-bit mode to handle virtual processes in either 32-bit mode or 64-bit mode selectable invidually by process (e.g. would not force them all to be running the same mode).
- Supporting 64-bit processes from a 32-bit kernel would be a nice touch, too, but not really essential.
- Be available in varying physical bus sizes for different scales of needs in different markets, such as 32-bit for embedded to small desktop, and 64-bit to high end workstation to server to number cruncher.
- Architecturally support even larger physical bus of 128-bit when times comes for that performance level to be market worthy.
- Support data fetch/store operations of all sizes 8-bit, 16-bit, 32-bit, and 64-bit. A size of 128-bit would be a plus.
- Fast byte order reversal instructions for all sizes.
- Statefully interruptable CPU instructions to support fast MD5, RSA, AES, and other crypto needs (the world is going to be doing more and more crypto, so get used to it).
- Statefully interruptable CPU instructions for codecs, including Ogg Vorbis.
Huh, where am I? Where's the light. Oh crap, it's 6:00 already. Where has the night gone. Damn, and I was having a good dream, too. Oh well, another dull day at work.So then maybe they made it too low level to begin with. It should have been a basic message passing in the buffer kind of thing. I have not looked at the spec and I think I don't even want to in order to avoid polluting my mind. But the best approach would have been a higher level message/packet kind of thing with a few parameters to give status, identify device, device specific parameters/status, and a chunk/window of data. Things like timing and signals should be handled by the controller.
Part of the trouble is that because vendors can supply Windows drivers, they feel free to change hardware interfaces, and so, this becomes a major problem. There need to be standards in this realm, as well as other places like system calls, libraries, and protocols.
It would be more like the exploding brain syndrome. I doubt it can throw someone in the air or knock down a wall, but possibly shatter a big hole in that wall.
This is NOT for Linux. Instead, it is for Redhat and Mandrake. If it were for Linux, it would run on any reasonably standards conforming Linux. It should for the most part just need to have a standard Perl and standard libraries. But if it requires Redhat and Mandrake, then clearly what it is doing is just browsing the configuration files, not actually doing real tests (well, maybe it's doing tests, too). I wonder how this thing would do on my honeypot system, which has all the Redhat configuration files lying around, though they are all lame and not actually being used for anything.
So a whole new set of commands, just to be able to go faster?
Not only that, drivers written by hardware vendors tend to be buggier than drivers written by the OS people for the OS they will be used in. Bill Gates has even blamed much of the buggieness of Windows on this. The bugs tend to be in interfacing with the OS itself, In fact, I've even seen it myself, where selecting certain options in the HP printer driver property menu on NT would instantly blue-screen. Linux tends to have more of the latter since OS enthusiasts are doing most of the work.
OSS typically lags commercial software support, unless the hardware standards designers and hardware manufacturers work with Linux and/or Linux people right from the start. All too often, the first sample a Linux developer has to go on is bought retail the day a new product is released, and often with no hardware specs to go on. I once contacted a hardware standards group by telephone to inquire about getting a copy of the standard for development purposes. If I wasn't a member of their organization, then I'd have to pay $10,000 and sign a non-disclosure agreement. I was told membership was "very exclusive and expensive". That standard was eventually released when products came out. That was the I2O standard.
If USB (the interface that hardware presents to core driver software) had been designed well in the first place, then speed would not matter, except for content of data elements that describe speeds (e.g. a value that says this is running at 12mbps or this is running at 480mbps, or the argument to a command that says force this to run at such and such a speed). Maybe they needed to add speed information and speed control, but that wouldn't be a whole change that needs a whole new software architecture (that's something that could have been added in an overnight coding session). What you'd get is data being transferred 40 times faster with 480 mbps.
Without looking at the specs to see, it's rather obvious that the hardware people just redesigned the interface all over again. Can't someone teach those people some things about reusability and refactoring? And USB isn't the only place this happens. Of course you do need to occaisionally add something to an interface, so a tweaked driver will be needed to fully take advantage of new hardware ideas. But a whole redesign isn't called for ... unless the old design was a POS. But was it the hardware or the software that was a POS? Looks to me like it was the hardware. We'll see when the next speed step occurs. Surely, the Firewire people won't stay 80Mbps down for long. They'll probably aim for somewhere in the 800 to 1600 range next, I bet (if not already). Will the next generation be compatible while still running at the higher speed?
It's not the government's place to dictate what is or is not a good business decision. What is a good decision for the nation is, though. But even then there are limits. But it might use tax incentives for that.
I hope we are not characterizing every H-1B worker as bad. Some are good. But the proportion of bad does appear to be quite high. The problem is, you don't really see how bad they are for quite some time in many cases. Too little real QA goes on, especially in software development.
The good H-1B workers are underpaid. If they are as good as the domestic worker they replaced, they should get the same salary (you know, same merit, same salary thing). But that's not happening. And the companies know that most H-1B workers won't change jobs, because of the extra paperwork and hassle of doing so, and the contract terms they are usually stuck with of paying back the first employer for a prorated cost of bringing them in. So in this captive state, an extra $5K a year isn't very interesting. And the H-1B worker isn't really interested in an extra $5K on the career track, because he's only here for 5-6 years anyway. Someone who's life is here has their career here, and moving to a better job has significance not only in the short term, but also in the long term.
Expensive, maybe so. And maybe what the lead guy needs to do is just code the whole damned thing himself and make it clear to everyone up the line to CEO that he's in there saving the company's ass to make sure the project gets delivered. Maybe, just maybe, they will reward him by firing 3 idiots and hiring 2 qualified people to replace them (at a gain in productivity). Too bad salaries get counted as expenses and executive stock options get counted as capital investments (well, not at WorldCom or Enron anymore). It should be the other way around. Then it would make financial sense to hire good people and keep them happy.
The ones with merit are the ones getting shafted. People with 30 years experience are walking out the door when someone with 1 year experience walks in to do the same job at half the pay. These H-1B legal fees you refer to amount to a little over $1000 filing fee, and a little over $1000 preparation costs. That's a bargain compared to the money savings in H-1B. It's the smaller companies that get stuck with the big fees preparing these documents because they don't know anything about it. Big companies like Microsoft, Sun, Texas Instruments, etc, have standard H-1B templates that lawyers have already researched and have proven to work. So they can run them through a mill, and they do.
Of course many H-1Bs have been laid off. But in terms of proportion, it hasn't happened to them as much as it has happened to domestic workers. And the reason is that any round of letting people go isn't just to remove the dead wood (that does happen, too), but also to cut costs. Some of the people still working at major corporations are total idiots. I've even met 2 of them. I'm not talking about rapidly certified people, I'm talking the top of the line experts who have 20-30 years experience and can do any task in their field and do it well. And it's not about changing technologies. I know a programmer with 24 years experience who was in doing Java as soon as it came out, and he got let go because "he's too expensive". Companies don't really need top level skills; they just say that so they can continue to fool the government into thinking there's a shortage of people even while 700,000 high tech people are looking for work (far more than the H-1B cap).
Merit? HR has no clue how to measure that.
As long as US companies don't put US workers first in their hiring, and as long as US companies are lying about the lack of available technical people just so they can get an H-1B brought in cheap to underpay and abuse, then why the hell should I go out of my way to favor these US companies in their foreign markets. Sure, I'd like to see more jobs here, but the fact is that companies like MSFT and SUNW are still doing more of their hiring overseas or bringing people in from overseas, than local. When you look at layoff stats and see that H-1Bs are much lower in their layoff percentages than US workers, for the larger of these companies, if you can even pry the accurate information out of them, then you know that what was going on during the peak is also still going on during the slump. And its about saving money, not about getting real talent. So I'm all in favor of Peru giving MSFT the shaft, not because I dislike MSFT products, but because I'm majorly annoyed at US companies for trying to keep US workers from being part of the benefit of global markets they sell to. I hope they give SUNW the same shaft.
Who the hell hired those idiots? There are too many GOOD programmers looking for work to accept this excuse. Whoever hired them should take the responsibility as being the principle cause of the failure, and replace them on the spot. GOOD programmers can pick up on a project fast. Afterall, this is only a 20K project. That's relatively small. So this will set you back at most another month. Just do it. Please don't encourage BAD programmers to stay in the field.
Allowing specifically those that are well trained and have experience (experience is what employers are saying they demand, so it should be part of the requirement). Unfortunately, there are stories of Americans having to actually train their H-1B replacements. Not all are coming here in a way that contributes any greater than the American who would lose their job, and have to put their family on public welfare (the replacement jobs, like flipping hamburgers, does not cover the costs of raising a family).
I'm all for having the best talent from abroad come into this country. But that means we have to do something to ensure that companies don't cheat on the system (and lots of companies, especially the big ones, cheat on everything they can) and bring in less trained and inexperienced people just so they can get a cheap warm body.
And that brings up your point about the fraction of an hour processing. That's wrong. I don't dispute that it is happening that way, but I dispute that it should not be allowed to happen that way. Each application should be thoroughly reviewed, including calling up references in the applicant's home country to verify past employment, training, and education. Then the position description needs to be reviewed and compared to the current job market to ensure that there is a genuine need for that specific role. And finally, the salary level should be set not by the current method of paying just the amount a generic programmer (for any programmer) or a generic engineer (for any engineer) makes. It should be set at a level that is appropriate for the job requirements. If it is a specialized programmer job, it most certainly will be well above the current $47,000 level for a generic programmer with 2 years experience. Someone with a degree in computer science, and experience doing this sort of thing, taking on a job as a lead software engineer for a Java/Oracle/Solaris based banking job should be getting at least $85,000 to $140,000 depending on which part of the USA the job is located. Companies are currently bringing people in at the $47,000 required level (because the law is blind to measuring the worth), even in California.
I'm not opposed to the principle of H-1B at all. I am opposed to the abuse of the process, which I believe is happening in as much as 80% of cases.
The above would ensure that H-1Bs are even BETTER for American, and help ensure that experienced Americans get jobs, too. Personally, I'd rather see this turned instead into a true residency program. If they are good enough to be GOOD for American, then they are good enough to stay if they want.
So can I use my list of UUnet customers to market to them network connectivity from a company not entering into bankruptcy? It is public information.
Anyone can lie. Suits are "money motivated" to lie. That's the American Corporate Culture way.