The FBI's Uniform Crime Reports are biased against reporting white collar crime. The FBI classifies crimes as "Part I" or "Part II" crimes.
"Part I" includes most violent crimes, and "Part II" includes fraud, embezzlement, and drug-related offenses. For "Part I" crimes, complaints and arrests are recorded. For "Part II" crimes,
only arrests are reported. As a result, most white collar crime doesn't show up in the Uniform Crime Reports at all.
Thus, US information about the prevalence of white collar crime is very poor. There are surveys, but not much hard data.
I really should fix the bad interaction between the "Nagle algorithm" and "delayed ACKs". Both ideas went into TCP around the same time, and the interaction is terrible. That fixed timer for ACKs is all wrong.
Here's the real problem, and its solution.
The concept behind delayed ACKs is to bet, when receiving some data from the net, that the local application will send a reply very soon. So there's no need to send an ACK immediately; the ACK can be piggybacked on the next data going the other way. If that doesn't happen, after a 500ms delay, an ACK is sent anyway.
The concept behind the Nagle algorithm is that if the sender is doing very tiny writes (like single bytes, from Telnet), there's no reason to have more than one packet outstanding on the connection. This prevents slow links from choking with huge numbers of outstanding tinygrams.
Both are reasonable. But they interact badly in the case where an application does two or more small writes to a socket, then waits for a reply. (X-Windows is notorious for this.) When an application does that,
the first write results in an immediate packet send. The second write is held up until the first is acknowledged. But because of the delayed ACK strategy, that acknowledgement is held up for 500ms. This adds 500ms of latency to the transaction, even on a LAN.
The real problem is that 500ms unconditional delay. (Why 500ms? That was a reasonable response time for a time-sharing system of the 1980s.) As mentioned above, delaying an ACK is a bet that the local application will reply to the data just received. Some apps, like character echo in Telnet servers, do respond every time. Others, like X-Windows "clients" (really servers, but X is backwards about this), only reply some of the time.
TCP has no strategy to decide whether it's winning or losing those bets.
That's the real problem.
The right answer is that TCP should keep track of whether delayed ACKs are "winning" or "losing". A "win" is when, before the 500ms timer runs out,
the application replies. Any needed ACK is then coalesced with the next outgoing data packet. A "lose" is when the 500ms timer runs out and the delayed ACK has to be sent anyway. There should be a counter in TCP, incremented on "wins", and reset to 0 on "loses". Only when the counter exceeds some number (5 or so), should ACKs be delayed. That would eliminate the problem automatically, and the need to turn the "Nagle algorithm" on and off.
So that's the proper fix, at the TCP internals level. But I haven't done TCP internals in years, and really don't want to get back into that.
If anyone is working on TCP internals for Linux today, I can be reached at the e-mail address above. This really should be fixed, since it's been annoying people for 20 years and it's not a tough thing to fix.
The user-level solution is to avoid write-write-read sequences on sockets.
write-read-write-read is fine. write-write-write is fine. But write-write-read is a killer. So, if you can, buffer up your little writes to TCP and send them all at once. Using the standard UNIX I/O package and flushing write before each read usually works.
The G5 is a "brainiac" design, a big complex chip with a long highly parallelized pipeline. This is a relatively new approach for RISC chips, which have typically concentrated on a small core, short pipeline, and simple design with a lot of "close" cache.
It's been many years since fast "RISC" chips were simple. It's very straightforward to design a RISC CPU that executes one instruction per clock. I once met the design team for a midrange MIPS CPU, and it was about 15 people. The design team for the Pentium Pro (Intel's first superscalar, and the innards of the Pentium II and III) was over 3000 people.
Once Intel could execute more than one instruction per clock, the RISC people had to catch up. And that meant all the complexity of a superscalar CPU. The advantages of RISC then disappeared - it wasn't simpler any more.
PowerPC CPUs have been superscalar all the way to the PowerPC 601, in 1992.
That's what comes from distributing a webcast in a proprietary format with DRM. If it was a plain MPEG 4 stream, there are unprivileged programs that could play it. But players with DRM need extra privileges, so they can get their hooks deep into the system.
The point of supply and demand is that either one of two things will happen the supply mined will increase to make up for the extra demand (and cause higher prices because to increase supply means extracting oil from less profitable places) or that the price will increase, and the amount bought will decrease.
No. The "less profitable places" don't exist. We've already pumping the north slope of Alaska, the North Sea, and the dregs of what's left in Texas. There's a huge discontinuity (like 10x) in extraction cost between Middle East oil and the next step down, oil sands and shale oil. Once the cheap stuff is gone, it's not fun.
Incidentally, this applies especially to gold. There are many closed gold mines, left over from when gold went up to $800 per ounce and then crashed. If the price of gold goes up, they'll be reopened. This puts something of a ceiling on the price of gold.
Metals are different than oil in this regard. With oil, either there is oil somewhere or there isn't. There aren't high-grade and low-grade ores, with a long tail of lower and lower grade ore. Some oil is easier to get at than other oil, but the range isn't as wide as it is with metals.
Just as I don't believe we're anywhere near to running out of oil in the next 1000 years...
Er, no. Nobody in oil geology thinks that. The most optimistic projections are that peak oil is about 25 year away. The pessimistic projection is that the peak was reached last year.
The consensus is that the peak is somewhere between now and 2015.
Classical economists tend to mis-analyze oil. The price is related to cost of extraction, which is low. Until demand exceeds supply. But throwing more money at search and extraction doesn't yield much more supply. Oil discovery rates peaked in the 1960s. Economists tend to assume that if demand exceeds supply, new sources will emerge. But the geology doesn't work that way. Four specific geological conditions have to be present for an oil field, and almost all the areas on the planet that meet those conditions have been explored. About 90% of the world's oil lies in 30 known major petroleum systems.
Right now, we're just about at the point where demand will exceed capacity. Demand is still climbing, mostly due to China's industrialization. All the OPEC countries except Saudi Arabia are producing flat-out. (Kuwait, incidentally, peaked a few months ago. The US peaked in 1970.) There's general suspicion that the world's biggest oil field, Gawar in Saudi Arabia, is at peak production.
The decisive moment will be when the Gawar field peaks. That will probably be the peak of worldwide oil production. Some people think Gawar has already peaked.
Re:It's "maglev" horizontally, not vertically
on
Maglev Elevators by 2008?
·
· Score: 2, Informative
The problem is people with colds or allergies. Skydiving is dangerous for anyone with blocked sinuses. Serious ear damage can result. At skydiving speeds, it's more likely than not.
Anyone healthy enough to work in a mine probably isn't at risk for this.
You might have to swallow once in a while to equalize the pressure. But office building workers aren't expected to be that rugged.
This isn't a "ropeless elevator". It's a way to make elevators quieter by using a magnetic bearing between the elevator car and the guide rails.
That's a nice feature, but not revolutionary.
There have been some "ropeless elevator" proposals, including ones where linear induction motors drive the elevator cars. The most elaborate proposals involve multiple cars per shaft and switches, like a vertical railroad. This would cut down the amount of building space devoted to elevator shafts considerably. Mitsubishi did some R&D in this area back in the 1990s, but there's no working hardware yet. There's been some military R&D in this area for shipboard weapons lifts, but that's more like a conveyor system. Eventually somebody will probably build such a system, but not yet.
Incidentally, the limit on elevator speed is human tolerance for changes in air pressure. 8 meters per second (downward) appears to be the comfort limit. The Sears Tower elevators were originally set for 9 m/s, and a broken eardrum was reported.
Sony's infamously intrusive DRM on their audio CDs hits Macs, too. More user interaction is required for the install than on Windows, apparently.
A question I haven't seen answered: apparently the Windows version installs the spyware and backdoor even if you reject the EULA. Is this true for the Mac version?
It's really a bit late to be introducing a new product line based on IA-32. Especially coming from a chipset that was 64 bit. It was a real surprise to see Apple taking this route. Clearly, they're aiming at the "cool laptop for web browsing" crowd, not the "graphic designer using Photoshop" crowd, which used to be Apple's target market.
Heavy photoshop users will say "You expect me to go back to a system that has to swap?"
(Vaguely relevant thought: "Web 2.0" runs down the battery faster.)
On/off toggle in the elevator. It's a standard Otis option, but it's not ordered much.
Early elevator arrival notification. Tell me which elevator will be the one I'll be entering. It's common to have lobby level "This car up" signs, controlled by the dispatching system. But above the lobby level, it's rare.
VIP floor access That's more common than you might think. It's called a "priority hall call station" in the elevator industry, and is usually an RFID or swipe card reader.
A major problem with all this "Web 2.0" stuff is that it's slower. If the client is constantly going back to the server, you need more server power. This may be the reason "Web 2.0" is so heavily promoted. It sells server hardware.
I'm seeing more sites that load slowly. Sites that need ten seconds or more to load over an idle DSL line are becoming common. Often, the delay is caused by page layout designed to delay loading until all the ads load. The renderer reformats frantically as the content trickles in. Sometimes it's because the server is overloaded servicing the within-page requests.
This is a big step backwards.
On the hysteria front, there's a site devoted to AJAX page layout. It contains a long section on how to get a page with three columns of the same height. Javascript is used to compute the length of each column and align the columns.
Differences between browsers must be handled. It doesn't work right in IE Mac 5, Firefox 1.0, or Opera 5 and 6. (But it's fixed in Opera 9b and Firefox 1.5!) Special cases are required for Opera 8 and Safari. All this to get three columns. Write once, debug everywhere.
Perl 5 has closures, although it's not obvious. They're useful when you have a function that takes a callback, and you want to pass some data along with the callback function.
Is it time to phase out some TLDs as unsuccessful?
.BIZ The Internet's equivalent of a strip mall in a bad neighborhood. No major company has its primary domain in.biz. Its reputation is that bad. It's used mostly by spammers, scammers, and other low-lifes.
.INFO There's some use of.info, but not much. Is it worth the trouble?
.MUSEUM The number of museums in this TLD is so tiny there's a single page that lists all of them. Yet most of the big names in museums aren't there.
.AERO Supposedly for the aviation industry, it's almost totally unused. The registrar has put up redirect pages for the major airport codes, such as LAX, but many of those are broken or redirect to the wrong page.
When considering any new TLDs, it's worth looking at how these TLDs, from ICANN's first wave of expansion, worked out.
Freecycle is about trading physical items. That's why it has such demographics. Like eBay, it's people with too much time, too much stuff, and too much storage space. Yes, Freecycle is about free stuff, but the same
finding and shipping issues apply.
There are a few MacOS-X attacks in the wild. Cowhand-A was the most significant one of 2005. It's a Trojan, and it turns the computer into a proxy zombie for remote connections. It's primitive by Windows virus standards. It just installs a program in the startup folder, and makes no attempt to conceal itself.
There have been some gaping holes in MacOS-X browsers that allowed execution of remote code. But nobody bothered to exploit them. Or so it is thought. There's always the possibility of quiet exploits that extract some useful information from the target, ship it somewhere, then clean up and exit.
He suggests we should be writing a practical guidebook printed on long lasting paper containing "the basic accumulated scientific knowledge of humanity."
That was actually done in the 1950s, as part of the US fallout shelter program. A large, useful collection of technical and historical knowledge was put on microfilm. Thousands of copies were made, boxed up with simple readers, and distributed to fallout shelters. They're really hard to find now.
You're not getting me. If I stand at the nearest road, from 8 morning until 5 afternoon, and note every car, make and model etc, and do a lot of statistics on it. What I have created is mine. I can sell this if I want to. Hell, I can write a book and publish it. That is still covered by copyright.
Not entirely. The text of the book is covered by copyright. The page layout is covered. The statistics are not. They're not "creative". As the Supreme Court put it, in Feist vs. Rural Telephone, "The threshold for originality in copyright is low, but it exists". You cannot copyright "facts" in the US, even if you collected them.
This is the "database copyright" issue. Companies that collect data have tried to get Congress to allow copyrights for collections of facts, but Congress has declined. There's even a constitutional question over whether Congress can do that, because the specific authority for copyrights and patents in the Constitution is narrow.
As a result, you can make a database from a phone book (Feist vs. Rural Telephone), you can distribute play by play basketball scores (NBA vs. Motorola), you can make a copy of a copy of a public domain picture (Bridgeman vs. Corel), and you can extract the court decisions from copyrighted lawbooks and republish them (Westlaw) without violating US copyright law.
Slashdot Mirror
Thus, US information about the prevalence of white collar crime is very poor. There are surveys, but not much hard data.
This is the first computer virus. From 1975. With source code.
Usually, if you're talking to someone in a call center who doesn't give a last name, they're a zero.
Here's the real problem, and its solution.
The concept behind delayed ACKs is to bet, when receiving some data from the net, that the local application will send a reply very soon. So there's no need to send an ACK immediately; the ACK can be piggybacked on the next data going the other way. If that doesn't happen, after a 500ms delay, an ACK is sent anyway.
The concept behind the Nagle algorithm is that if the sender is doing very tiny writes (like single bytes, from Telnet), there's no reason to have more than one packet outstanding on the connection. This prevents slow links from choking with huge numbers of outstanding tinygrams.
Both are reasonable. But they interact badly in the case where an application does two or more small writes to a socket, then waits for a reply. (X-Windows is notorious for this.) When an application does that, the first write results in an immediate packet send. The second write is held up until the first is acknowledged. But because of the delayed ACK strategy, that acknowledgement is held up for 500ms. This adds 500ms of latency to the transaction, even on a LAN.
The real problem is that 500ms unconditional delay. (Why 500ms? That was a reasonable response time for a time-sharing system of the 1980s.) As mentioned above, delaying an ACK is a bet that the local application will reply to the data just received. Some apps, like character echo in Telnet servers, do respond every time. Others, like X-Windows "clients" (really servers, but X is backwards about this), only reply some of the time.
TCP has no strategy to decide whether it's winning or losing those bets. That's the real problem.
The right answer is that TCP should keep track of whether delayed ACKs are "winning" or "losing". A "win" is when, before the 500ms timer runs out, the application replies. Any needed ACK is then coalesced with the next outgoing data packet. A "lose" is when the 500ms timer runs out and the delayed ACK has to be sent anyway. There should be a counter in TCP, incremented on "wins", and reset to 0 on "loses". Only when the counter exceeds some number (5 or so), should ACKs be delayed. That would eliminate the problem automatically, and the need to turn the "Nagle algorithm" on and off.
So that's the proper fix, at the TCP internals level. But I haven't done TCP internals in years, and really don't want to get back into that. If anyone is working on TCP internals for Linux today, I can be reached at the e-mail address above. This really should be fixed, since it's been annoying people for 20 years and it's not a tough thing to fix.
The user-level solution is to avoid write-write-read sequences on sockets. write-read-write-read is fine. write-write-write is fine. But write-write-read is a killer. So, if you can, buffer up your little writes to TCP and send them all at once. Using the standard UNIX I/O package and flushing write before each read usually works.
John Nagle
Makes one wonder what Microsoft's real direction is. Grow the XBox line into a desktop, maybe?
It's been many years since fast "RISC" chips were simple. It's very straightforward to design a RISC CPU that executes one instruction per clock. I once met the design team for a midrange MIPS CPU, and it was about 15 people. The design team for the Pentium Pro (Intel's first superscalar, and the innards of the Pentium II and III) was over 3000 people.
Once Intel could execute more than one instruction per clock, the RISC people had to catch up. And that meant all the complexity of a superscalar CPU. The advantages of RISC then disappeared - it wasn't simpler any more.
PowerPC CPUs have been superscalar all the way to the PowerPC 601, in 1992.
You actually have to pay to watch this thing. Not only that, there's a charge for each person watching .
That's what I told Carol Lynn in 1971, when she headed the campaign to bring back Star Trek. "It's over. Give it up. Let it go".
No. The "less profitable places" don't exist. We've already pumping the north slope of Alaska, the North Sea, and the dregs of what's left in Texas. There's a huge discontinuity (like 10x) in extraction cost between Middle East oil and the next step down, oil sands and shale oil. Once the cheap stuff is gone, it's not fun.
Incidentally, this applies especially to gold. There are many closed gold mines, left over from when gold went up to $800 per ounce and then crashed. If the price of gold goes up, they'll be reopened. This puts something of a ceiling on the price of gold.
Metals are different than oil in this regard. With oil, either there is oil somewhere or there isn't. There aren't high-grade and low-grade ores, with a long tail of lower and lower grade ore. Some oil is easier to get at than other oil, but the range isn't as wide as it is with metals.
Er, no. Nobody in oil geology thinks that. The most optimistic projections are that peak oil is about 25 year away. The pessimistic projection is that the peak was reached last year. The consensus is that the peak is somewhere between now and 2015.
Classical economists tend to mis-analyze oil. The price is related to cost of extraction, which is low. Until demand exceeds supply. But throwing more money at search and extraction doesn't yield much more supply. Oil discovery rates peaked in the 1960s. Economists tend to assume that if demand exceeds supply, new sources will emerge. But the geology doesn't work that way. Four specific geological conditions have to be present for an oil field, and almost all the areas on the planet that meet those conditions have been explored. About 90% of the world's oil lies in 30 known major petroleum systems.
Right now, we're just about at the point where demand will exceed capacity. Demand is still climbing, mostly due to China's industrialization. All the OPEC countries except Saudi Arabia are producing flat-out. (Kuwait, incidentally, peaked a few months ago. The US peaked in 1970.) There's general suspicion that the world's biggest oil field, Gawar in Saudi Arabia, is at peak production.
The decisive moment will be when the Gawar field peaks. That will probably be the peak of worldwide oil production. Some people think Gawar has already peaked.
Anyone healthy enough to work in a mine probably isn't at risk for this. You might have to swallow once in a while to equalize the pressure. But office building workers aren't expected to be that rugged.
The skydiving people recommend Afrin.
1. Open a terminal window /Library/Application\ Support/M4/Resources/C/Kext ../../../.. /System/Library/Extensions/ ../StartupItems/
2. cd
3. sudo kextunload Pho*
4. cd
5. rm -rf M4
6. cd
7. Repeat step 3
8. rm -rf PhoenixNub*
9. cd
10. sudo kill -9 `ps aux | grep lsmftd | awk '{print $2}'`.
11. sudo rm -rf sfpatd/
12. Either try step 10 again, or restart the computer.
Oh, and be careful typing those "rm -rf" lines. You're running as superuser.
Here's the technical reference: "Electromagnetic Non-contact Guide System for Elevator Cars", Morishita, M., Akashi, M., Toshiba Corporation, Japan.
There have been some "ropeless elevator" proposals, including ones where linear induction motors drive the elevator cars. The most elaborate proposals involve multiple cars per shaft and switches, like a vertical railroad. This would cut down the amount of building space devoted to elevator shafts considerably. Mitsubishi did some R&D in this area back in the 1990s, but there's no working hardware yet. There's been some military R&D in this area for shipboard weapons lifts, but that's more like a conveyor system. Eventually somebody will probably build such a system, but not yet.
Incidentally, the limit on elevator speed is human tolerance for changes in air pressure. 8 meters per second (downward) appears to be the comfort limit. The Sears Tower elevators were originally set for 9 m/s, and a broken eardrum was reported.
A question I haven't seen answered: apparently the Windows version installs the spyware and backdoor even if you reject the EULA. Is this true for the Mac version?
Heavy photoshop users will say "You expect me to go back to a system that has to swap?"
(Vaguely relevant thought: "Web 2.0" runs down the battery faster.)
I'm seeing more sites that load slowly. Sites that need ten seconds or more to load over an idle DSL line are becoming common. Often, the delay is caused by page layout designed to delay loading until all the ads load. The renderer reformats frantically as the content trickles in. Sometimes it's because the server is overloaded servicing the within-page requests. This is a big step backwards.
On the hysteria front, there's a site devoted to AJAX page layout. It contains a long section on how to get a page with three columns of the same height. Javascript is used to compute the length of each column and align the columns. Differences between browsers must be handled. It doesn't work right in IE Mac 5, Firefox 1.0, or Opera 5 and 6. (But it's fixed in Opera 9b and Firefox 1.5!) Special cases are required for Opera 8 and Safari. All this to get three columns. Write once, debug everywhere.
That's what HTML tables are for.
Perl 5 has closures, although it's not obvious. They're useful when you have a function that takes a callback, and you want to pass some data along with the callback function.
When considering any new TLDs, it's worth looking at how these TLDs, from ICANN's first wave of expansion, worked out.
Freecycle is about trading physical items. That's why it has such demographics. Like eBay, it's people with too much time, too much stuff, and too much storage space. Yes, Freecycle is about free stuff, but the same finding and shipping issues apply.
So it's clearly possible to craft attacks for MacOS-X. But Mac market share is so tiny that few bother. Back before the PowerPC transition, when Apple had more market share, there were more Mac viruses. "Back in the late 1980s, viruses used to be a much bigger problem on Macs than on PCs. We here at F-Secure used to have an antivirus product for Mac but discontinued it after the macro viruses died out".
There have been some gaping holes in MacOS-X browsers that allowed execution of remote code. But nobody bothered to exploit them. Or so it is thought. There's always the possibility of quiet exploits that extract some useful information from the target, ship it somewhere, then clean up and exit.
That was actually done in the 1950s, as part of the US fallout shelter program. A large, useful collection of technical and historical knowledge was put on microfilm. Thousands of copies were made, boxed up with simple readers, and distributed to fallout shelters. They're really hard to find now.
Not entirely. The text of the book is covered by copyright. The page layout is covered. The statistics are not. They're not "creative". As the Supreme Court put it, in Feist vs. Rural Telephone, "The threshold for originality in copyright is low, but it exists". You cannot copyright "facts" in the US, even if you collected them.
This is the "database copyright" issue. Companies that collect data have tried to get Congress to allow copyrights for collections of facts, but Congress has declined. There's even a constitutional question over whether Congress can do that, because the specific authority for copyrights and patents in the Constitution is narrow.
As a result, you can make a database from a phone book (Feist vs. Rural Telephone), you can distribute play by play basketball scores (NBA vs. Motorola), you can make a copy of a copy of a public domain picture (Bridgeman vs. Corel), and you can extract the court decisions from copyrighted lawbooks and republish them (Westlaw) without violating US copyright law.