I hope that gets modded up. It illustrates very well why one shouldn't airily dismiss a security threat and why defence in depth is desirable.
I was very disappointed to see Bruch Schneier dismiss these issues on the basis that an ATM is like a vault, and therefore inherently secure. That idea showed a lack of understanding of how real-world exploits occur - usually through a combination of weaknesses.
The people that make these kinds of decisions are not fools.
I'd like to believe that, but remember Bank of America's online credit card processing was taken down by an MS worm recently. And OS advocacy aside, Windows is just not a good fit for this application. I'd have to conclude that anyone planning to use Windows in an ATM was more influenced by marketing than by objective assessment. That may not make them fools, but they are not showing good judgement.
We can't have the level of unemployment we have now, much less more, and expect to remain a world power...much less a technology and industry leader.
I disagree. The fortunes of US workers have nothing to do with the fortunes of multinational corporations nominally called "US Corporations." Imagine a future where the US has 60% unemployment. IBM has no US employees except for Sales and Field Service. All engineering and corporate management is distributed across India, China and Korea. IBM still gives to US political campaigns, and the US will defend IBM's interests anywhere in the world. The US has the best military, funded by taxes from "US Corporations". US Corporations hold most of the intellectual property such as patents, making them the world technology leaders. It doesn't matter where in the world the engineering talent is; it matters who owns the patents.
We're starting to see that what's good for the US economy might not be good for all or any US citizens. Imagine if all salaries and wages in the US were magically cut in half. Would that be good for the economy? Yes! Corporate earnings would go way up as their payrolls went down. And the flood of cheap labor would enable businesses that are not currently viable.
Would it be good for normal people? No! Many people would have to get a second job to make ends meet. People would have to lower their standard of living. Who benefits? Investors, wherever they are. They could be in Italy, Taiwan, Africa - every time US workers get poorer, they get richer.
A common fallacy is that reduced purchasing power of the US workers would hurt the US economy. On the contrary, poor people spend a higher proportion of their income than rich people. And they often spend it on things that are more profitable to corporations, such as late fees. Also, US corporations do not have to cater to US residents.
I hold no position on the outsourcing issue, but I'd like to illuminate the fact that workers and investors do not have the same interests.
I don't think that should have been modded "troll". Linux, at least Red Hat, is definitely afflicted with dependency hell. And I agree that BSD feels more "well-defined". On installing OpenBSD I was quite impressed to see the completeness of the man pages.
But looking at people I know who run BSD, they largely fall into two categories: they have servers that predate the maturity of Linux, and see no reason to switch, or they are trying to distance themselves from the Gnome/KDE/turn-linux-into-windows crowd. While I understand the latter, I find it a bit funny.
Thanks. This issue has been irritating me, and you expressed it well. The idea that OS X is "based on" BSD seems deeply appealing to both Mac zealots and BSD zealots. Definitely a marketing coup.
This topic came up today, and a Unix guy who is programming a MacOS application was there. I asked him, "How much of BSD is used when a normal user uses MacOS X?" (Meaning no terminals). After thinking a moment, he answered "None."
Now he may have missed some odds and ends, but given his background and the fact that he's spending hours a day neck-deep in a MacOS X application, I think he's substantially right.
Classic SF was based on the impact of technological advancement. The heros could be geeks (like Hari Selden) or action heroes who merely wielded technology. But the crux seems to be victory through scientific cleverness. And in the 50s and 60s, that was credible; scientific cleverness was giving the US the dominant role.
But now the tables are turned. Scientific cleverness is no longer worth very much - only business/legal cleverness is. The US will go from an exporter to an importer of technical know-how, while remaining the leader in marketing that know-how. No new invention will rock the world. If an established interest is threatened by a new invention, it will demand government intervention and get it, either by special legislative action or through lawsuits and IP enforcement. There is no more room for Promethean technical endeavors.
The US has reached stasis, like "Directive 10-289" in Atlas Shrugged. We know that our "upper ranks" are riddle with corruption. The badly run businesses with bad products are winning, due to increased market inefficiencies and barriers to entry. The wrongdoers in high places are not punished.
This puts us in a backwards-looking mood. Rather than the unlimited future, we want to find our way back to sanity. We want Aragorn to ride up and strike Darl McBride's head from his shoulders in one blow. We want sturdy Hobbit archers to invade the ICANN meeting and send the scoundrels packing.
All the ingredients of classic SF - computers, robots, space travel - have lost their charm. Their future development will only benefit corporations. The idea that technology could alter the power structure is over. We look to the past, even a mythical past, because the future does not look good.
The application arm ports the profitable bits of MS software to Linux, and continues to do decent business. The OS arm gradually tapers off...
Ah, but Microsoft has also seen that future. Hence.NET. So the "OS arm" becomes the ".NET arm" supporting.NET on a range of OS's. And when all the mainstream developers are targetting.NET, the underlying OS ceases to matter strategically. Linux will be down there somewhere, but it won't matter. And.NET will have encrypted channels to the motherboard so its DRM magic flows through Linux untouched and unseen.
You're kidding, but maybe it could. The article says Lamo performed almost all his hacking with an ordinary web browser. So it probably consisted of URL modification.
I don't think it's very often that you find a claim of an invention that a large number of people feel "uncertain" about.
On the contrary, many major inventions are hotly disputed. Usually they were invented independently by several people around the same time. For example, Alexander Bell and Elisha Gray invented the telephone concurrently. Bell won the legal battle.
This is a great post, but all the cases for code generation boil down to the last - target language does not have the right kind of abstractions. I have used code generation to generate C and other things. But I can't imagine auto-generating Perl, because Perl is more flexible. Actually, I once did grind a big spec through a Perl script to generate Perl that I then maintained by hand - but what I generated was a big data structure describing the spec, rather than a bunch of actual procedural code. The core engine that interpreted the data structure didn't need to change. I could have accomplished the same thing by having the live code parse the spec every time it ran, but there was some data I needed to clean up after the import, and I didn't want the speed penalty.
I agree about popular OO languages - they're a poor fit for a lot of business and web applications.
Code generation can have a legitimate place. I guess there are two logical ways to use it. Given a processor that transforms "metasource" into "source", either you maintain the metasource and never hand-edit the source, or you run the generator just once to create a rough framework, and then discard the metasource and maintain the source. I've done both, saving time and aggravation.
But code generation can be a sign that the wrong language is being used. The author recognizes this, but points out that the individual programmer may not be able to make that choice. True, but the example he gives of generating EJB's seems to show how flawed the Java/EJB idea is in handling database-backed apps.
Perl inherently supports a more generic approach to data that mates more seamlessly with relational databases. For example:
my $user = $dbh->selectrow_hashref(
"select * from user where id=?",
undef,
$userid, ); # now the user record is a hashref we can manipulate: $user->{ favorite_color } = 'blue'; # store it update_row('user', $user);
(I'm not recommending this particular sequence of events, of course - slight concurrency problem.) update_row() is not standard, but most Perl programmers can see how it's written. It's generic, so it can update any table as long as the primary key is called 'ID'. And it leverages Oracle's caching so the SQL is not recompiled.
The reason is that as CPUs get faster and OS's get better at multitasking, it becomes more tempting to make the peripheral very cheap and dumb and move its functions into the host computer. Thus we get the win(modem|printer|scanner).
Generally, you can escape from this by buying the more expensive stuff, which is more standards complaint. In the case of printers, above a certain level they support PCL and/or Postscript. Postscript can also control options like duplexing, although it's not 100% standard.
However, I'm not aware of any equivalent high-level standards for scanners.
I think your absolutism regarding graffiti should be tempered by the circumstances. Michael Fay spray-painted a lot of people's cars - I agree that he deserved what he got. But someone who spraypaints the side of a warehouse shouldn't be seen in the same light. Although it's technically "private" property, it doesn't have the same direct path to the owner's heart and blood pressure. In fact, it's probably owned by a corporation.
While SPEWS's tactics may appear "doomed to failure" in your eyes, they are having a noticeable effect on spam-friendly ISPs. If you read nanae you regularly see ISPs that have ignored all spam complaints for months or years finally start dumping their spammers in response to a SPEWS listing.
I'm responding to you because you're more coherent than most of your "teammates". Most of the anti-spews posts contain either false statements (for example, that SPEWS has listings which violate its stated criteria) or credulity-stretching narratives with the key facts omitted. In the latter category we find the company that's listed on SPEWS because some spam was sent from their IP's three years ago. Of course neither company name nor IP address is included in the sad story, so nobody can verify it.
That last case is a good example of the emotional divide. If you're anti-SPEWS, you probably think the story is true. If you're pro-SPEWS, you've read too many similar stories on nanae and seen them all debunked. It's always possible that story N+1 is true, just as it's possible that perpetual motion machine N+1 really works.
Many anti-spam people have become so calloused from dealing with endless lies, threats and manipulation that they are unable to discuss the problem in a civil manner. Either that, or the combative personality types sought out the combative roles.
Slashdot Mirror
I hope that gets modded up. It illustrates very well why one shouldn't airily dismiss a security threat and why defence in depth is desirable.
I was very disappointed to see Bruch Schneier dismiss these issues on the basis that an ATM is like a vault, and therefore inherently secure. That idea showed a lack of understanding of how real-world exploits occur - usually through a combination of weaknesses.
I'd like to believe that, but remember Bank of America's online credit card processing was taken down by an MS worm recently. And OS advocacy aside, Windows is just not a good fit for this application. I'd have to conclude that anyone planning to use Windows in an ATM was more influenced by marketing than by objective assessment. That may not make them fools, but they are not showing good judgement.
I didn't know that. So I sent mail to a nonexistent domain, and sure enough I got a bounce from 64.94.110.11. Yuck.
Try spews.bl.reynolds.net.au. But I'm surprised that an absence of SPEWS made a big difference to your filtering - I find that they block very little.
Otherwise, agreed.
[red]$ host weriowerwer.com
weriowerwer.com. has address 64.94.110.11
[red]$ host -t mx weriowerwer.com
[red]$
The MX record determines where mail gets sent.
verisignsucks.com
verisignsucks.com
.com left?
Is this the only
I disagree. The fortunes of US workers have nothing to do with the fortunes of multinational corporations nominally called "US Corporations." Imagine a future where the US has 60% unemployment. IBM has no US employees except for Sales and Field Service. All engineering and corporate management is distributed across India, China and Korea. IBM still gives to US political campaigns, and the US will defend IBM's interests anywhere in the world. The US has the best military, funded by taxes from "US Corporations". US Corporations hold most of the intellectual property such as patents, making them the world technology leaders. It doesn't matter where in the world the engineering talent is; it matters who owns the patents.
We're starting to see that what's good for the US economy might not be good for all or any US citizens. Imagine if all salaries and wages in the US were magically cut in half. Would that be good for the economy? Yes! Corporate earnings would go way up as their payrolls went down. And the flood of cheap labor would enable businesses that are not currently viable.
Would it be good for normal people? No! Many people would have to get a second job to make ends meet. People would have to lower their standard of living.
Who benefits? Investors, wherever they are. They could be in Italy, Taiwan, Africa - every time US workers get poorer, they get richer.
A common fallacy is that reduced purchasing power of the US workers would hurt the US economy. On the contrary, poor people spend a higher proportion of their income than rich people. And they often spend it on things that are more profitable to corporations, such as late fees. Also, US corporations do not have to cater to US residents.
I hold no position on the outsourcing issue, but I'd like to illuminate the fact that workers and investors do not have the same interests.
I don't think that should have been modded "troll". Linux, at least Red Hat, is definitely afflicted with dependency hell. And I agree that BSD feels more "well-defined". On installing OpenBSD I was quite impressed to see the completeness of the man pages.
But looking at people I know who run BSD, they largely fall into two categories: they have servers that predate the maturity of Linux, and see no reason to switch, or they are trying to distance themselves from the Gnome/KDE/turn-linux-into-windows crowd. While I understand the latter, I find it a bit funny.
Thanks. This issue has been irritating me, and you expressed it well. The idea that OS X is "based on" BSD seems deeply appealing to both Mac zealots and BSD zealots. Definitely a marketing coup.
This topic came up today, and a Unix guy who is programming a MacOS application was there. I asked him, "How much of BSD is used when a normal user uses MacOS X?" (Meaning no terminals). After thinking a moment, he answered "None."
Now he may have missed some odds and ends, but given his background and the fact that he's spending hours a day neck-deep in a MacOS X application, I think he's substantially right.
How about: "Linux is for people who just want to get the job done; BSD is for people trying to prove how 31337 they are."
Only partly serious.
Classic SF was based on the impact of technological advancement. The heros could be geeks (like Hari Selden) or action heroes who merely wielded technology. But the crux seems to be victory through scientific cleverness. And in the 50s and 60s, that was credible; scientific cleverness was giving the US the dominant role.
But now the tables are turned. Scientific cleverness is no longer worth very much - only business/legal cleverness is. The US will go from an exporter to an importer of technical know-how, while remaining the leader in marketing that know-how. No new invention will rock the world. If an established interest is threatened by a new invention, it will demand government intervention and get it, either by special legislative action or through lawsuits and IP enforcement. There is no more room for Promethean technical endeavors.
The US has reached stasis, like "Directive 10-289" in Atlas Shrugged. We know that our "upper ranks" are riddle with corruption. The badly run businesses with bad products are winning, due to increased market inefficiencies and barriers to entry. The wrongdoers in high places are not punished.
This puts us in a backwards-looking mood. Rather than the unlimited future, we want to find our way back to sanity. We want Aragorn to ride up and strike Darl McBride's head from his shoulders in one blow. We want sturdy Hobbit archers to invade the ICANN meeting and send the scoundrels packing.
All the ingredients of classic SF - computers, robots, space travel - have lost their charm. Their future development will only benefit corporations. The idea that technology could alter the power structure is over. We look to the past, even a mythical past, because the future does not look good.
Ah, but Microsoft has also seen that future. Hence
I posted the parent, and like an idiot forgot to log in. So I'm trying to drag it up from the obscure gutter where it lies.
At the risk of sounding immodest, it is more insightful than 100 breaking-into-car analogies.
You're kidding, but maybe it could. The article says Lamo performed almost all his hacking with an ordinary web browser. So it probably consisted of URL modification.
On the contrary, many major inventions are hotly disputed. Usually they were invented independently by several people around the same time. For example, Alexander Bell and Elisha Gray invented the telephone concurrently. Bell won the legal battle.
This is a great post, but all the cases for code generation boil down to the last - target language does not have the right kind of abstractions. I have used code generation to generate C and other things. But I can't imagine auto-generating Perl, because Perl is more flexible. Actually, I once did grind a big spec through a Perl script to generate Perl that I then maintained by hand - but what I generated was a big data structure describing the spec, rather than a bunch of actual procedural code. The core engine that interpreted the data structure didn't need to change. I could have accomplished the same thing by having the live code parse the spec every time it ran, but there was some data I needed to clean up after the import, and I didn't want the speed penalty.
I agree about popular OO languages - they're a poor fit for a lot of business and web applications.
Code generation can have a legitimate place. I guess there are two logical ways to use it. Given a processor that transforms "metasource" into "source", either you maintain the metasource and never hand-edit the source, or you run the generator just once to create a rough framework, and then discard the metasource and maintain the source. I've done both, saving time and aggravation.
But code generation can be a sign that the wrong language is being used. The author recognizes this, but points out that the individual programmer may not be able to make that choice. True, but the example he gives of generating EJB's seems to show how flawed the Java/EJB idea is in handling database-backed apps.
Perl inherently supports a more generic approach to data that mates more seamlessly with relational databases. For example:
my $user = $dbh->selectrow_hashref(
"select * from user where id=?",
undef,
$userid,
);
# now the user record is a hashref we can manipulate:
$user->{ favorite_color } = 'blue';
# store it
update_row('user', $user);
(I'm not recommending this particular sequence of events, of course - slight concurrency problem.)
update_row() is not standard, but most Perl programmers can see how it's written. It's generic, so it can update any table as long as the primary key is called 'ID'. And it leverages Oracle's caching so the SQL is not recompiled.
The reason is that as CPUs get faster and OS's get better at multitasking, it becomes more tempting to make the peripheral very cheap and dumb and move its functions into the host computer. Thus we get the win(modem|printer|scanner).
Generally, you can escape from this by buying the more expensive stuff, which is more standards complaint. In the case of printers, above a certain level they support PCL and/or Postscript. Postscript can also control options like duplexing, although it's not 100% standard.
However, I'm not aware of any equivalent high-level standards for scanners.
I think your absolutism regarding graffiti should be tempered by the circumstances. Michael Fay spray-painted a lot of people's cars - I agree that he deserved what he got. But someone who spraypaints the side of a warehouse shouldn't be seen in the same light. Although it's technically "private" property, it doesn't have the same direct path to the owner's heart and blood pressure. In fact, it's probably owned by a corporation.
But if it were a list of MD5 hashes of email addresses, spammers couldn't use it to get the email addresses.
While SPEWS's tactics may appear "doomed to failure" in your eyes, they are having a noticeable effect on spam-friendly ISPs. If you read nanae you regularly see ISPs that have ignored all spam complaints for months or years finally start dumping their spammers in response to a SPEWS listing.
You can query SPEWS at spews.bl.reynolds.net.au
I'm responding to you because you're more coherent than most of your "teammates". Most of the anti-spews posts contain either false statements (for example, that SPEWS has listings which violate its stated criteria) or credulity-stretching narratives with the key facts omitted. In the latter category we find the company that's listed on SPEWS because some spam was sent from their IP's three years ago. Of course neither company name nor IP address is included in the sad story, so nobody can verify it.
That last case is a good example of the emotional divide. If you're anti-SPEWS, you probably think the story is true. If you're pro-SPEWS, you've read too many similar stories on nanae and seen them all debunked. It's always possible that story N+1 is true, just as it's possible that perpetual motion machine N+1 really works.
Many anti-spam people have become so calloused from dealing with endless lies, threats and manipulation that they are unable to discuss the problem in a civil manner. Either that, or the combative personality types sought out the combative roles.