It's a stock swap merger, not a cash buy.
"Under the terms of Monday's deal, IAC will issue 1.26 shares of its common stock for each share of Ask Jeeves common stock in a tax-free transaction valued at $1.85 billion, discounting any cash involved in the buyout."
Like most mergers, it will probably be a dud. The performance history of merger and acquisition activity is, overall, negative. But because it increases volatility, it enhances CEO pay.
There are two movies: "Volcanoes of the Deep Sea", and "Aliens of the Deep". They're both IMAX. They're both produced by James Cameron. They're both out now.
"Volcanoes of the Deep Sea" is the "educational" version, and "Aliens of the Deep" is the "light entertainment" version, released by Disney.
Roger Ebert's review of Aliens of the Deep calls it "a convincing demonstration of Darwin's theory of evolution,". So even the "lite" version has evolution.
The Fort Worth Museum of Science and History, which supposedly didn't want to show "Volcanoes of the Deep Sea", is showing Aliens of the Deep.
"Cosmic Voyage" is from 1996. It's perhaps the biggest zoom shot of all time, starting from the quark level and zooming out to the entire universe over 35 minutes. It wasn't controversial at the time, and it doesn't seem to be that controversial now. Just dated. It's basically a remake of Powers of Ten, by Charles and Ray Eames.
Galapagos is playing at the IMAX in Fort Lauderdale, FL, along with two other IMAX theaters in the US. It's from 1999. Nobody seems to be that wound up about it.
It looks like some casual comment by the marketing guy for the museum in Fort Worth has been blown up out of proportion.
The big problem with "Volcanoes of the Deep Ocean" may be that it's "too educational". There's a teacher's guide, with quizzes and homework assignments. And really, there's a glut of undersea IMAX movies.
Isn't it enough to boost the priority in the queue for recently-activated threads and to un-boost the prio for threads that recently activated other threads?
No. Consider a unidirectional scheme like System V message passing.
Assume there's another CPU-bound thread C ready to run at the same priority as the original thread A. When thread A sends to thread B via queue AB, and boosts B's priority and drops A's priority, B gets control and A loses control. When B replies to A via queue BA, A is ready and waiting, but at the send to B. A hasn't yet made it to the call that reads from queue BA. At this moment, B is blocked, and A and C are ready to run. C has a higher priority, so it gets control. Eventually, C runs out its quantum, and A gets to run. Much later.
This happens on every message pass. The effect is that message passing has terrible latency, and you can only do a limited number of them per second.
This is the scheduling curse of unidirectional messaging. Botch this and everyone will know that interprocess communications suck, and a few will know why.
Some months back, I received a spam promoting the stock XLPI. Checking the web site for the company, "XcelPlus", which sells a "lubricant additive", I found this claim of FAA approval. It even had the FAA seal, which they've since removed.
I wrote to the FAA district office that covers Waco, Texas, asking if that endorsement was legitimate.
A few weeks later, I received a call from an anti-terrorism investigator at the Defense Criminal Investigation Agency. Apparently, someone had looked at the claim of FAA approval and the claim of U.S. Army approval, and decided that this might be a case of selling unapproved aircraft lubricants to the Department of Defense.
So the case was referred to the sabotage/anti-terrorism investigators.
I'm not sure what happened then. But the spam has stopped, and XLPI is down from $0.50 to $0.04.
I wasn't aware that laser fuses in DRAM had made a comeback. But they have. Today there are some bad rows and columns and they're switched out during die test by cutting some connections with a laser beam.
A few years ago, there was a patent lawsuit between EMI and Cypress Semiconductor over this technology. But that's been settled, and now the technology is more available.
But when you read the GNU HURD tutorial on Mach IPC, you see the suggestion that a program intended to send an integer to another program and wait for a reply should do two separate operations. Somebody doesn't get this.
Also, for no particularly good reason, Mach usually uses the same buffer for both send and receive, so if you use the combined send/receive form, whatever you send gets clobbered by the reply. So using this tends to involve an extra copy.
Mach IPC is incredibly complicated, You have to fill in many data structures just to send something. The implementation is complicated, too.
QNX has a nice, simple primitive:
int MsgSend(int connectionid, const void* sendmsg, int sendbytes, void* rcvmsg, int rcvbytes);
You can probably figure out how to use that just from the definition. Even the reply value is what you think it should be: the receive count if it worked, -1 if it failed, with an error code in errno.
The name of the game here is getting the primitives right.
First, this stuff has been around for years. Decades, in some cases. And it's been "real soon now" since the days of X10.
Here's a classic example, the Echelon LonWorks demo room. This has been online for many years. You can turn the lights on and off, run the window blinds up and down, read the room temperature, and do similar amusing stuff. It's all done via power line networking.
As it turns out, LonWorks was modestly successful in building automation. But it's become the standard for control of auxiliary equipment in passenger trains and transit vehicles. LonWorks is often used for destination signs, HVAC, and related functions.
LonWorks gateways to the IP world are available.
Read the manual for one. The default security is terrible. (The default password is in the manual.)
There are good security features available, but, sadly, the gateway comes with security turned off,
and setting up a system in a secure mode is a key-distribution headache, because you have to tell every device on the network what the key is.
And, yes, people have connected these things to the Internet, embedded web server and all. Dumb.
Yield data is hard to come by, but here's a business school case study with some hard numbers. Pentium 4 yields were around 60%, and DRAM yields were around 90%, in 2002. Pentium 4 yields are probably well above that point now, since that technology has matured. Note the comment in that paper that in DRAM fabs, at initial startup, yields may be as low as 5-10%, but rise to 90-98% once the fab is running properly. So that's where you put your effort, not into finding ways to use the rejects.
There have been moments in DRAM history when devices were made that were configured in some way during final test to work around bad spots. IBM did it for a while in the 1980s, I think. But with 90+% yields, it's not worth the added switching you need on chip to allow that. You could, in theory, use heavy ECC to tolerate a substantial defect rate. That's how CD-ROMs work, after all.
But it's not necessary yet.
For a while, there was a market for DRAM with bad spots for use in telephone answering machines.
This is an idea that resurfaces periodically in the semiconductor history, but historically, the yields have always come up to acceptable levels.
You cannot optimize the fast path without kernel support -- letting the scheduler know that control has passed from one task to another.
Exactly. That's one of the few things a kernel must do to get IPC right. Get that wrong, and nothing you do on top can ever fix it.
The Hurd group doesn't seem to have gotten the message on this. They seem to be going more in the direction of building a platform for OS hacking than getting the primitives right and rock-solid. The latter is the key to microkernel work. If the design is botched, it never recovers.
Once you get a microkernel right, it changes very little. Neither QNX nor VM has changed much at the kernel level in years. They don't need to; everything complicated is outside the kernel. New file systems, drivers, graphic systems, and GUIs are all user programs. This is how you get stability.
There are really only two microkernels that work - VM for IBM mainframes, and QNX. Many others have tried, but few have succeeded. Here's why.
VM is really a hypervisor, or "virtual machine monitor". The abstraction it offers to the application looks like the bare machine. So you have to run another OS under VM to get useful services.
The PC analog of VM is VMware. VMware is much bigger and uglier than VM because x86 hardware doesn't virtualize properly, and horrible hacks, including code scanning and patching, have to be employed to make VMware work at all. IBM mainframe hardware has "channels", which support protected-mode I/O. So drivers in user space work quite well.
QNX is a widely used embedded operating system. It's most commonly run on small machines like the ARM, but it works quite nicely on x86. You can run QNX on a desktop; it runs Firefox and all the GNU command-line tools.
QNX got interprocess communication right. Most academic microkernels, including Mach and L4, get it wrong. The key concept can be summed up in one phrase - "What you want is a subroutine call. What the OS usually gives you is an I/O operation". QNX has an interprocess communication primitive, "MsgSend", which works like a subroutine call - you pass a structure in, wait for the other process to respond, and you get another structure back. This makes interprocess communication not only convenient, but fast.
The performance advantage comes because a single call does the necessary send, block, and call other process operations. But the issue isn't overhead. It's CPU scheduling. If the receiving process is waiting (blocked at a "MsgReceive"), control transfers immediately to the receiving process. There's no ambiguity over whether the message is complete, as there is with pipe/socket type IPC. There's no trip through the scheduler looking for a process to run. And, most important, there's no loss of scheduling quantum.
This last is subtle, but crucial. It's why interprocess communication on UNIX, Linux, etc. loses responsiveness on heavily loaded systems.
The basic trouble with one-way IPC mechanisms, which include those of System V and Mach, is that sending creates an ambiguity about who runs next.
When you send a System V type IPC message (which is what Linux offers), the sender keeps on running and the receiving process is unblocked. Shortly thereafter, the sending process usually does an IPC receive to get a reply back, and finally blocks. This seems reasonable enough. But it kills performance, because it leads to bad scheduling decisions.
The problem is that the sending process keeps going after the send, and runs until it blocks. At this point, the kernel has to take a trip through the scheduler to find which thread to run next. If you're in a compute-bound situation, and there are several ready threads, one of them starts up. Probably not the one that just received a message, because it's just become ready to run and isn't at the head of the queue yet. So each IPC causes the process to lose its turn and go to the back of the queue. So each interprocess operation carries a big latency penalty.
This is the source of the usual observation that "IPC under Linux is slow". It's not that the implementation is slow, it's that the ill-chosen primitives have terrible scheduling properties.
This is an absolutely crucial decision in the design of a microkernel. If it's botched, the design never recovers. Mach botched it, and was never able to fix it. L4 isn't that great in this department, either.
Sockets and pipes are even worse, because you not only have the scheduling problem, you have the problem of determining when a message is complete and it's time to transfer control. The best the kernel can do is guess.
QNX is a good system technically.
The main problem with QNX, from the small user perspective, is the company's marketing operation, which is dominated by inside sales people who want to cut big
Basically, they spent some time playing with a rapid-prototyping machine that builds solids up from ABS. Then they made what's basically a printed circuit board. But they did it by making a blank board with slots for the "wires" and metal parts, then pouring in a low-melting-point metal to create "wiring".
All this was done in a very crude way, as if they were developing a process for home use.
Their metal casting technique is scary. They used "Wood's Metal", which is a solder-like alloy of tin, lead, cadmium, and bismuth. All of which are toxic. Lead and cadmium cause heavy-metal poisoning, and the body won't clear either of them.
No serious precautions seem to have been taken against inhalation - they just used gloves. At one point they tried powdered metal, which is much more of an inhalation hazard than molten liquid. They need to run their people through the usual checks for heavy-metal poisoning.
Here is a sample of what you will get You will have many lists to choose from
socks.txt is the raw lists.
and then you will have several domain connect checks lists to choose from as well.
They're down today, but SpamForum.biz carries ads for zombies, open proxies, botnets, etc.
Numbers available range from 1000 to 50,000.
When they're up, they're very entertaining.
An older spammer forum, SpecialHam.com is back up. With banner ads, even. "DarkMailer - not for newbies". "Blackbox Hosting - bulletproof hosting options" "SendSafe - bulk mail has never been this easy". "Bulkhost.com - the leader in bulk-friendly e-mail hosting".
Sites like these are where the hackers and spammers meet, find deals, and scream about being ripped off by each other. The actual deals tend to take place on ICQ.
McDonalds had a big kitchen-automation effort a few years ago. But when wages came back down after the boom, they didn't need it.
Their latest idea is to outsource the drive-through talker. The drive-through intercom will be remoted to an offsite location, where the order will be keyed into the kitchen computer network.
If we had a $15/hr minimum wage, we'd see far more robotics and automation. But what would we do with all the excess people? We tried this.
Linux security hasn't improved in years. It's still about where UNIX was in the 1980s. This looks good only because Microsoft is so awful.
What's needed is to get behind NSA Security-Enhanced Linux and push. The key apps that are regularly attacked (mail, web servers, browsers, databases, DNS) all need to be modified to work as multi-process programs with small trusted parts and big untrusted parts. Trying to patch monolithic trusted apps undergoing ongoing enhancement is never going to work.
Apple already has multi-button mice. But the buttons are located on the keyboard. "Shift-Click".
"Command-Drag". "Shift-Command-Drag"
"Option-Drag".
The original Apple Macintosh interface had a strict subject-verb grammar. You selected something (the subject), and then went to a menu item to indicate what to do with it. This is limiting, but very easy to learn. Verb-subject interfaces are also possible; those are the ones where you go into a "mode", and the next thing you click on is operated upon in that mode. Today, verb-subject interfaces are usually associated with toolbars.
Most of the "shift-click" stuff is an attempt to express verb-subject grammar. Badly. It's usually better to stick with subject-verb. Select, then indicate what you want done. Indicating what you want done can be a keypress, or a right-click floating menu.
Re:scientists are apparently good at...press relea
on
Sunlight in a Tube
·
· Score: 1
Yeah. Oak Ridge is a remnant of the Manhattan Project, now in search of a mission.
There are at least six manufacturers of tubular skylights. They're not too useful, because, as windows, they're small.
And you have to clean them, which is hard. They're used mostly by home architects who've managed to create a dark interior area and need to get out of that design mistake.
"National Security Letters" - the FBI sends these to ISPs, demanding access to account data or e-mail. There's no judicial oversight; the FBI does this all by themselves. The ISP can't talk about it.
One ISP is sueing the Justice Department, and until recently, they were under a gag order so strong they couldn't say they were in litigation.
Since there's a threat of a five year prison sentence for disclosing that you received a National Security Letter, these tend not to get publicity. But hundreds of them have been sent.
The "no fly list" mess. On at least two occasions, the "no fly list" has been used to keep opponents of Adminstration policy from travelling.
The "no fly list" is a secret, too. And there's no way to get off it.
"Guilt by association". Vague involvement with some group vaguely associated with terrorism can be punished as a terrorist act. This is getting a few terrorist wannabees, like the Virgina Jihad, a bunch of guys into paintball and Islamic rhetoric.
Jose Padilla. Padilla is apparently a small-time Chicago crook who hooked up with some al-Queda people as if they were a gang. He's being held without trial, only because Ashcroft made a big deal about him building a "dirty bomb". He never accomplished enough that he could be convicted of much, which is probably why he hasn't been charged.
The Patriot Act is overkill for the losers the Administration is catching with it.
Knuth was there first. When "Fundamental Algorithms" came out, there were almost no computer science books. There were vendor machine manuals, and books on programming languages. "A Fortran Primer", by Elliot Organick was about as good as it got. MIT students had a tech note series called HAKMEM, but few others saw those. There was a huge vacuum waiting to be filled. That's why "Fundamental Algorithms" got so much attention.
One of our biggest problems in Silicon Valley has been finding a big open space in which to test. We now have access to a huge parking lot built during the dot-com boom, adjacent to an unfinished building complex. So we have the Overbot winding in and out among the parking islands. We'll be testing there today in a few hours.
In terms of technology, Team DAD probably is most innnovative.
Everything runs on digital signal processors. They're building their own laser rangefinder this year. Last year, they got further than anybody else without wrecking. (CMU crashed three times; their HUMMV was able to survive the first two.)
Nobody seems to have a breakthrough in sensing.
(By this I mean sensing good enough to evaluate terrain. Detecting big, solid obstacles is trivial.) LIDAR line scanners are too limited, stereo vision doesn't register well on dirt, and strong intelligent vision processing requires a breakthrough that twenty years of research has failed to produce. The breakthrough needed is flash LIDAR, which exists, but wasn't ready soon enough for this year's Grand Challenge. (The rules prohibit the use of Government-funded patented technology not available for general sale by last August, and the good flash LIDAR wasn't available in time.) CMU has a LIDAR line scanner on a giant gimbal, and we have a LIDAR line scanner on an overly large tilt head, but that's an interim solution and a technical dead end.
On the other hand, GPS and inertial gear gets better and cheaper every year. It's surprising how good it is.
This year, everybody who makes it to the starting line should disappear over the horizon at the start. The minimal level of performance to make it through the "site visit" hurdle is above that demonstrated by most of the vehicles entered last year.
And this year, DARPA is putting tank traps on the course.
Even though Apple Computer could sue your ass off because they have a clause in their EULA disallowing it, it's a really stupid clause
Yes, it is a really stupid clause, because it's an "illegal tie-in sale". IBM lost that one decades ago, trying to prevent clones of their mainframes. That's how the third-party IBM mainframe market was created.
the safety record of shuttle flights is exemplary.
Compared to what? So far, the Shuttle has killed 14 people in two crashes. Apollo lost three people in a ground test, of course, but nobody in flight. Mercury and Gemini never lost any. Soyuz had two fatal accidents, killing four people.
Slashdot Mirror
Like most mergers, it will probably be a dud. The performance history of merger and acquisition activity is, overall, negative. But because it increases volatility, it enhances CEO pay.
The Fort Worth Museum of Science and History, which supposedly didn't want to show "Volcanoes of the Deep Sea", is showing Aliens of the Deep.
The Charleston Science Museum is also showing Aliens of the Deep.
"Cosmic Voyage" is from 1996. It's perhaps the biggest zoom shot of all time, starting from the quark level and zooming out to the entire universe over 35 minutes. It wasn't controversial at the time, and it doesn't seem to be that controversial now. Just dated. It's basically a remake of Powers of Ten, by Charles and Ray Eames.
Galapagos is playing at the IMAX in Fort Lauderdale, FL, along with two other IMAX theaters in the US. It's from 1999. Nobody seems to be that wound up about it.
It looks like some casual comment by the marketing guy for the museum in Fort Worth has been blown up out of proportion.
The big problem with "Volcanoes of the Deep Ocean" may be that it's "too educational". There's a teacher's guide, with quizzes and homework assignments. And really, there's a glut of undersea IMAX movies.
No. Consider a unidirectional scheme like System V message passing.
Assume there's another CPU-bound thread C ready to run at the same priority as the original thread A. When thread A sends to thread B via queue AB, and boosts B's priority and drops A's priority, B gets control and A loses control. When B replies to A via queue BA, A is ready and waiting, but at the send to B. A hasn't yet made it to the call that reads from queue BA. At this moment, B is blocked, and A and C are ready to run. C has a higher priority, so it gets control. Eventually, C runs out its quantum, and A gets to run. Much later.
This happens on every message pass. The effect is that message passing has terrible latency, and you can only do a limited number of them per second.
This is the scheduling curse of unidirectional messaging. Botch this and everyone will know that interprocess communications suck, and a few will know why.
I wrote to the FAA district office that covers Waco, Texas, asking if that endorsement was legitimate.
A few weeks later, I received a call from an anti-terrorism investigator at the Defense Criminal Investigation Agency. Apparently, someone had looked at the claim of FAA approval and the claim of U.S. Army approval, and decided that this might be a case of selling unapproved aircraft lubricants to the Department of Defense. So the case was referred to the sabotage/anti-terrorism investigators.
I'm not sure what happened then. But the spam has stopped, and XLPI is down from $0.50 to $0.04.
A few years ago, there was a patent lawsuit between EMI and Cypress Semiconductor over this technology. But that's been settled, and now the technology is more available.
Mach RPC is built on top of Mach ports, but an RPC call is not a single kernel-level operation. So you have the scheduling problem.
Interestingly, although it's very obscure, the kernel call level below mach_msg_send actually does support a combined send/block/receive operation. As the MIT document points out, this "enables certain internal optimizations".
But when you read the GNU HURD tutorial on Mach IPC, you see the suggestion that a program intended to send an integer to another program and wait for a reply should do two separate operations. Somebody doesn't get this.
Also, for no particularly good reason, Mach usually uses the same buffer for both send and receive, so if you use the combined send/receive form, whatever you send gets clobbered by the reply. So using this tends to involve an extra copy.
Mach IPC is incredibly complicated, You have to fill in many data structures just to send something. The implementation is complicated, too. QNX has a nice, simple primitive:
You can probably figure out how to use that just from the definition. Even the reply value is what you think it should be: the receive count if it worked, -1 if it failed, with an error code in errno.
The name of the game here is getting the primitives right.
First, this stuff has been around for years. Decades, in some cases. And it's been "real soon now" since the days of X10.
Here's a classic example, the Echelon LonWorks demo room. This has been online for many years. You can turn the lights on and off, run the window blinds up and down, read the room temperature, and do similar amusing stuff. It's all done via power line networking.
As it turns out, LonWorks was modestly successful in building automation. But it's become the standard for control of auxiliary equipment in passenger trains and transit vehicles. LonWorks is often used for destination signs, HVAC, and related functions.
LonWorks gateways to the IP world are available. Read the manual for one. The default security is terrible. (The default password is in the manual.) There are good security features available, but, sadly, the gateway comes with security turned off, and setting up a system in a secure mode is a key-distribution headache, because you have to tell every device on the network what the key is.
And, yes, people have connected these things to the Internet, embedded web server and all. Dumb.
There have been moments in DRAM history when devices were made that were configured in some way during final test to work around bad spots. IBM did it for a while in the 1980s, I think. But with 90+% yields, it's not worth the added switching you need on chip to allow that. You could, in theory, use heavy ECC to tolerate a substantial defect rate. That's how CD-ROMs work, after all. But it's not necessary yet.
For a while, there was a market for DRAM with bad spots for use in telephone answering machines.
This is an idea that resurfaces periodically in the semiconductor history, but historically, the yields have always come up to acceptable levels.
The Hurd group doesn't seem to have gotten the message on this. They seem to be going more in the direction of building a platform for OS hacking than getting the primitives right and rock-solid. The latter is the key to microkernel work. If the design is botched, it never recovers.
Once you get a microkernel right, it changes very little. Neither QNX nor VM has changed much at the kernel level in years. They don't need to; everything complicated is outside the kernel. New file systems, drivers, graphic systems, and GUIs are all user programs. This is how you get stability.
VM is really a hypervisor, or "virtual machine monitor". The abstraction it offers to the application looks like the bare machine. So you have to run another OS under VM to get useful services.
The PC analog of VM is VMware. VMware is much bigger and uglier than VM because x86 hardware doesn't virtualize properly, and horrible hacks, including code scanning and patching, have to be employed to make VMware work at all. IBM mainframe hardware has "channels", which support protected-mode I/O. So drivers in user space work quite well.
QNX is a widely used embedded operating system. It's most commonly run on small machines like the ARM, but it works quite nicely on x86. You can run QNX on a desktop; it runs Firefox and all the GNU command-line tools.
QNX got interprocess communication right. Most academic microkernels, including Mach and L4, get it wrong. The key concept can be summed up in one phrase - "What you want is a subroutine call. What the OS usually gives you is an I/O operation". QNX has an interprocess communication primitive, "MsgSend", which works like a subroutine call - you pass a structure in, wait for the other process to respond, and you get another structure back. This makes interprocess communication not only convenient, but fast.
The performance advantage comes because a single call does the necessary send, block, and call other process operations. But the issue isn't overhead. It's CPU scheduling. If the receiving process is waiting (blocked at a "MsgReceive"), control transfers immediately to the receiving process. There's no ambiguity over whether the message is complete, as there is with pipe/socket type IPC. There's no trip through the scheduler looking for a process to run. And, most important, there's no loss of scheduling quantum.
This last is subtle, but crucial. It's why interprocess communication on UNIX, Linux, etc. loses responsiveness on heavily loaded systems. The basic trouble with one-way IPC mechanisms, which include those of System V and Mach, is that sending creates an ambiguity about who runs next.
When you send a System V type IPC message (which is what Linux offers), the sender keeps on running and the receiving process is unblocked. Shortly thereafter, the sending process usually does an IPC receive to get a reply back, and finally blocks. This seems reasonable enough. But it kills performance, because it leads to bad scheduling decisions.
The problem is that the sending process keeps going after the send, and runs until it blocks. At this point, the kernel has to take a trip through the scheduler to find which thread to run next. If you're in a compute-bound situation, and there are several ready threads, one of them starts up. Probably not the one that just received a message, because it's just become ready to run and isn't at the head of the queue yet. So each IPC causes the process to lose its turn and go to the back of the queue. So each interprocess operation carries a big latency penalty.
This is the source of the usual observation that "IPC under Linux is slow". It's not that the implementation is slow, it's that the ill-chosen primitives have terrible scheduling properties. This is an absolutely crucial decision in the design of a microkernel. If it's botched, the design never recovers. Mach botched it, and was never able to fix it. L4 isn't that great in this department, either.
Sockets and pipes are even worse, because you not only have the scheduling problem, you have the problem of determining when a message is complete and it's time to transfer control. The best the kernel can do is guess.
QNX is a good system technically. The main problem with QNX, from the small user perspective, is the company's marketing operation, which is dominated by inside sales people who want to cut big
All this was done in a very crude way, as if they were developing a process for home use. Their metal casting technique is scary. They used "Wood's Metal", which is a solder-like alloy of tin, lead, cadmium, and bismuth. All of which are toxic. Lead and cadmium cause heavy-metal poisoning, and the body won't clear either of them. No serious precautions seem to have been taken against inhalation - they just used gloves. At one point they tried powdered metal, which is much more of an inhalation hazard than molten liquid. They need to run their people through the usual checks for heavy-metal poisoning.
There are rapid prototyping machines that deposit metal, and that's probably a more useful direction.
All this is a long, long way from self-replication.
Anonymous SOCKS proxies.
Here is a sample of what you will get You will have many lists to choose from
socks.txt is the raw lists. and then you will have several domain connect checks lists to choose from as well.
samples are provided.
ICQ: 340450685
Only 2 Available Slots Remain
# socks.txt Updated Dec 28, 14:58 (8076 proxies)
# msn.txt Updated Dec 28, 14:52 (4591 proxies)
# aol.txt Updated Dec 28, 14:53 (4551 proxies)
# hotmail.txt Updated Dec 28, 14:54 (4589 proxies)
# yahoo.txt Updated Dec 28, 14:56 (4539 proxies)
# gmail.txt Updated Dec 28, 14:57 (4590 proxies)
# http.txt Updated Dec 28, 14:59 (1189 proxies)
Must have References.
The "non-standard ports" is the giveaway. They're not just finding open proxy servers. They're making them.
There's also a nice how-to on how to spam with proxies on Google Answers.
When they're up, they're very entertaining.
An older spammer forum, SpecialHam.com is back up. With banner ads, even. "DarkMailer - not for newbies". "Blackbox Hosting - bulletproof hosting options" "SendSafe - bulk mail has never been this easy". "Bulkhost.com - the leader in bulk-friendly e-mail hosting".
Sites like these are where the hackers and spammers meet, find deals, and scream about being ripped off by each other. The actual deals tend to take place on ICQ.
Their domain (their main asset) just became less valuable.
Been there, done that. Look up "connection machine".
Their latest idea is to outsource the drive-through talker. The drive-through intercom will be remoted to an offsite location, where the order will be keyed into the kitchen computer network.
If we had a $15/hr minimum wage, we'd see far more robotics and automation. But what would we do with all the excess people? We tried this.
What's needed is to get behind NSA Security-Enhanced Linux and push. The key apps that are regularly attacked (mail, web servers, browsers, databases, DNS) all need to be modified to work as multi-process programs with small trusted parts and big untrusted parts. Trying to patch monolithic trusted apps undergoing ongoing enhancement is never going to work.
So quit gloating and start coding, Linux people.
The original Apple Macintosh interface had a strict subject-verb grammar. You selected something (the subject), and then went to a menu item to indicate what to do with it. This is limiting, but very easy to learn. Verb-subject interfaces are also possible; those are the ones where you go into a "mode", and the next thing you click on is operated upon in that mode. Today, verb-subject interfaces are usually associated with toolbars.
Most of the "shift-click" stuff is an attempt to express verb-subject grammar. Badly. It's usually better to stick with subject-verb. Select, then indicate what you want done. Indicating what you want done can be a keypress, or a right-click floating menu.
There are at least six manufacturers of tubular skylights. They're not too useful, because, as windows, they're small. And you have to clean them, which is hard. They're used mostly by home architects who've managed to create a dark interior area and need to get out of that design mistake.
Plastic skylights are bigger and more useful.
That's easier than it used to be. The National Intellectual Property Rights coordination Center, a unit of Homeland Security, handles this. There's even an online form.
Before you can enforce a copyright, you must register it with the Library of Congress. This costs $30. So that's step one.
The Patriot Act is overkill for the losers the Administration is catching with it.
Knuth was there first. When "Fundamental Algorithms" came out, there were almost no computer science books. There were vendor machine manuals, and books on programming languages. "A Fortran Primer", by Elliot Organick was about as good as it got. MIT students had a tech note series called HAKMEM, but few others saw those. There was a huge vacuum waiting to be filled. That's why "Fundamental Algorithms" got so much attention.
One of our biggest problems in Silicon Valley has been finding a big open space in which to test. We now have access to a huge parking lot built during the dot-com boom, adjacent to an unfinished building complex. So we have the Overbot winding in and out among the parking islands. We'll be testing there today in a few hours.
In terms of technology, Team DAD probably is most innnovative. Everything runs on digital signal processors. They're building their own laser rangefinder this year. Last year, they got further than anybody else without wrecking. (CMU crashed three times; their HUMMV was able to survive the first two.)
Nobody seems to have a breakthrough in sensing. (By this I mean sensing good enough to evaluate terrain. Detecting big, solid obstacles is trivial.) LIDAR line scanners are too limited, stereo vision doesn't register well on dirt, and strong intelligent vision processing requires a breakthrough that twenty years of research has failed to produce. The breakthrough needed is flash LIDAR, which exists, but wasn't ready soon enough for this year's Grand Challenge. (The rules prohibit the use of Government-funded patented technology not available for general sale by last August, and the good flash LIDAR wasn't available in time.) CMU has a LIDAR line scanner on a giant gimbal, and we have a LIDAR line scanner on an overly large tilt head, but that's an interim solution and a technical dead end.
On the other hand, GPS and inertial gear gets better and cheaper every year. It's surprising how good it is.
This year, everybody who makes it to the starting line should disappear over the horizon at the start. The minimal level of performance to make it through the "site visit" hurdle is above that demonstrated by most of the vehicles entered last year.
And this year, DARPA is putting tank traps on the course.
Yes, it is a really stupid clause, because it's an "illegal tie-in sale". IBM lost that one decades ago, trying to prevent clones of their mainframes. That's how the third-party IBM mainframe market was created.
Compared to what? So far, the Shuttle has killed 14 people in two crashes. Apollo lost three people in a ground test, of course, but nobody in flight. Mercury and Gemini never lost any. Soyuz had two fatal accidents, killing four people.