First, this isn't blur, it's pixelation, with big pixels. That's not the same as blur. True blur, like Gaussian blur in Photoshop, doesn't actually destroy that much information. After Gaussian blurring, each pixel has a unique value, but it's a linear combination of values from nearby pixels. There's almost as much information as before blurring; the only true losses are from rounding. That's a reversible process.
Pixelation, though, substantially reduces the amount of information in the image. Before, each pixel had a unique value. After, only each square has a unique value. So information really has been destroyed. However, if, after pixelation, the target object to be identified still has several pixels, some kind of attack might work. You need to use big enough pixel blocks that multiple target objects (like three or more letters or numbers) map to a single block. Of course, visually this will lose you the "there's sort of some number there but I can't make it out" look.
Pixelation with some crypto-grade noise added would probably solve the problem. (Remember, if the attacker can predict the noise algorithm, it doesn't help.)
It's kind of a cute video. The couple makes out around their friends, who seem to be completely indifferent to it, like they've seen this before. They take pictures of each other. The girl looks at the camera a few times; she knows she's being recorded and is cool with it. Then they go off and have sex in the surf, and again, there's a glance towards the camera now and then. Good sex scene. No big deal.
I'm surprised there's any objection from Brazil about this. I'd expect whining from the religious right in the US, but from Brazil?
JavaScript has a security policy. The security model is that 1) scripts can only talk to the site from which the script came, and 2) scripts can only alter documents from the site from which the script came. The security model is enforced only at a few points, notably the XMLHttpRequest object and at points where Javascript stores into the document object tree.
Other than those few enforcement points, JavaScript objects in the same browser instance can communicate freely. This offers a number of potential exploits, some of which are listed in the paper.
If the security model is tightened up, prohibiting all intercommunication between Javascript objects from different sites, "mashups" no longer work, so it's too late to tighten this up without breaking some popular sites.
This is going to be hard to fix without breaking existing programs. Javascript has a very weak concept of what's immutable. It might work to mark functions as "dirty" if changed once loaded, then forbid "new" on "dirty" functions. That would prevent changing the base instance of a class without breaking too much else, and would fix this new vulnerability. But it wouldn't fix all potential vulnerabilities in that area. As long as multiple scripts share global variables, there's going to be potential for trouble.
Maybe "https" pages should be locked down more. "Secure" pages should be single source - everything has to come from one specific domain address. No frames, no cross-site anything - one secure site per window, and no shared data with other pages whatsoever. That's a start.
As everyone with a clue points out, he needs a heat exchanger in there somewhere.
Control Data, in Chippewa Falls, MN, used to use an outside water cooling loop which pumped warm water into the ground via one well, and pulled in cold water via another well. Ground temperature a few hundred feet down was relatively constant year round.
I once worked at a large industrial R&D center which had a sizable decorative pond with water spraying into the air in front of the building. This was actually a heat sink for the dummy loads on hydraulic transmissions. (The plant ran life cycle tests on units up to locomotive transmissions.)
But these were facilities that needed to dump tens of megawatts of heat. For a few hundred watts, it's silly.
"vi" wasn't first, but it was free.
on
The Birth of vi
·
· Score: 3, Interesting
Long before Bill Joy, UNIX had a good full-screen editor - the RAND editor.
The RAND editor dated from the early 1970s. I used it at Ford Aerospace, and it was much nicer than "vi".
But it wasn't free. You had to pay RAND for each copy.
The RAND editor was much closer to "what you see is what you get" than "vi". It was a full-screen editor with all the commands on function keys. All the keys like "insert", "delete", etc. did what you'd expect. Labels were provided to show what each function key did. So it was far more user-friendly than "vi".
The RAND editor was modestly portable from terminal to terminal. It worked best on HP terminals of the period, and was table driven so that it could support different devices. But you had to change the tables in C and rebuild to add support for a new device.
The RAND editor had fewer "mode" issues than "vi". What you typed went in at the cursor position. For a few special commands, like "find", a special line at the bottom of the screen was used. But you could always see visually what was going on. Much better look and feel than "vi".
Those of us who had both available used the RAND editor.
Some of what Joy is credited for in the early days of UNIX reflects the fact that he worked for a tax-funded organization working under a contract that allowed them to give software away.
I like the eye-defocusing detector. That's probably a better measurement of driving impairment. That's a fairly standard device; the phenomenon that causes "redeye" in photographs can be sensed and measured with an IR source and camera.
What to do with the information is an interesting problem. I'd think in terms of fitting something like an anti-collision radar system like the old Eaton VORAD, and if there's any indication of driver impairment, enforce much larger stopping distances by speed limiting.
Where he goes off track is at "Fortunately, policymakers wishing to address theses problems can draw on the extensive
theoretical literature exploring the economics of congestion. Much of the literature has focused
on the choice between flat-rate pricing and usage-sensitive pricing. The primary finding of this
literature is that competitive markets will reach an efficient equilibrium if each user is charged a
usage-sensitive price set equal to their marginal contribution to congestion. 28" Reference 28 is to "28 See, e.g., Eitan Berglas, On the Theory of Clubs, 66 AM. ECON REV. 116, 119 (1976).", which is a classic paper on periodic vs per-use pricing for things like gyms and swimming pools, but is not about congestion at all.
Yao does get some things right. He recognizes that the billing cost (he says "transaction cost", but means billing overhead) for things like the Internet is higher than the cost of providing the service, and this distorts the economics from the pay-for-what-you-get model economists usually like.
But then he goes off into a right-wing rant on why vertically integrated monopolies are good. The competition between the vertically integrated monopolies will supposedly prevent prices from rising. However, he states that as an article of faith, without support. Historically, when a market gets down to small number of players, (two or three), price competition tends to weaken. The fewer the players, the easier de-facto collusion becomes.
He ignores many issues. Time scale, for example. Congestion is a problem on a scale of minutes, while carrier-switching by end users occurs on a scale of months.
He also ignores contractual lock-in and technical lock-in, which makes carrier switching more expensive. If the end user's strategy is to minimize their costs over the next year, then carriers can raise their rates each year by any amount less than the cost of switching, and get away with it. He ignores that completely.
(This is a chronic problem with economists. Like control theorists, they study feedback systems, but unlike control theorists, they don't consider time domain issues like stability, settling time, oscillation, and phase locking issues much.)
There's also the technical issue in Internet congestion that the congestion is mostly at the edges. If you have your own wire to the central office, as with DSL, why should there be price differentiation depending on what data you're sending and receiving? Yet it's the DSL providers who don't want network neutrality. It's not the backbone providers. Thus, congestion isn't the real issue. Wanting a bigger piece of the TV viewer's entertainment spending is.
There are people who've written well about the economics of network congestion, but this guy isn't one of them.
The big advantage COBOL has is that the language is serious about data storage. The language knows about structured files, databases, indices, and formatted fields. COBOL was the first language to have data structures.
Look at what a mess it is to talk to a database from Perl, Python, Java, or C/C++. There's fussy glue code required, and the language doesn't help you make sure that field XYZ in the database comes out as field XYZ in the program. In COBOL, it's straightforward. The language knows about databases. There's even a good interface to MySQL.
It also has some formatting capabilities that HTML should have had. You can write CREDIT-CARD-NUMBER PICTURE 9999-9999-9999-9999. In some systems, that will eventually result in an input field on a green screen that will only accept four fields of all numbers with all digits filled in and will display a blank form field accordingly. HTML FORM fields should have worked that way.
There are some real advantages to a language where components outside the individual programs can see, check, and use the data declarations.
1:58 P.M. -
The Speaker-elect was escorted into the Chamber by the Escort Committee and introduced by Representative-elect Boehner, Republican Leader, before assuming the Chair.
1:43 P.M. -
Roll call 2 - Election of the Speaker Ms. Pelosi 233, Mr. Boehner 202. Ms. Pelosi was elected Speaker of the House.
Bush said of Pelosi as Speaker, before the elections, "That's not going to happen."
Many computer rooms have packaged units which both heat and cool, and some also both humidify and dehumidify. That's fine if you only have one. If you have more than one, they need to be interlocked so you don't get one cooling while another is heating, or one humidifying while another is dehumidifying. If you get into that situation, everything will seem to be just fine, but your energy bills will be maybe 5x what they should be.
Saw that situation in a server room at Stanford a few years ago.
Yeah, and it's a huge hassle in vacant commercial buildings. Somebody needs to run every water tap and flush every toilet about once a month, or the whole place will stink up. Then the smell gets into the carpeting, which makes it hard to rent the building.
For special situations, there are calibrated drip valves. These are often found
as part of fire sprinkler systems, which usually have a drain valve for when you need to drain the system for maintenance. The water from the drain valve has to go somewhere, which usually means a sewer connection. But you can't hook a water line to a sewer line; there are situations when you'd suck sewerage into the water system. So there has to be a vacuum break open to air. After the vacuum break, there's a U-trap with water to keep sewer gas inside. But since such drains are seldom used, the water will evaporate. So a tiny bit of water has to be dripped into the drain to keep up with evaporation. There are special "drip valves" for this.
One of the things you need to know about if you run large data centers.
What I think is that however it does not look to me that robotics as an industry could ever enjoy the _same_ degree of modularization enjoyed by the computer industry.
Take a look at the LynxMotion Servo Erector Set. Modular robot kits are already here, and we're not taking about Lego.
Or - and let's face it, this is a good idea - the most contested articles will have to end up restricted to people with a certain editing "score".
Doesn't help. The people who add good content typically don't make large numbers of edits, or add large numbers of articles. They write a good article or two on something they really know something about, and leave. The people who have huge edit counts are typically deleting material, not adding it. There's no obvious way to identify the good writers prospectively.
Wikis are so over
on
Wikinomics
·
· Score: 2, Interesting
Wikipedia is drowning under the incoming dreck. Here are the last ten new articles on
Wikipedia today:
"Minnesota School of Cosmetology" ("The Minnesota School of Cosmetology is a private, for-profit, cosmetology school") -- Spam.
"DiveBuddy" (a social network site for SCUBA divers.) -- Spam, deleted.
"George and Carol Olmsted Foundation" ("The Olmsted Scholar Program was established by General George Olmsted.") -- Copied from web site, tagged as copyvio, deleted.
Axxess2 ("Axxess2: Your special service provider for tailor made turn key solutions that guarantee you and your clients secure and successful access.") -- Spam, deleted.
"Mormons for justice" ("Morons Of Justice") -- Attack article, deleted.
"Scandinavian Simvastatin Survival study" (Medical article, no references) -- Might be valid, but can't tell. Tagged with "Verify".
"Geraldine Santiago", created by user "Geraldinesantiago" ('Geraldine Santiago, published author and licensed realtor") - Spam, deleted.
CoWare ("CoWare, Inc is the leading supplier of platform-driven electronic system level (ESL) design software and services.") - ad.
"Ellis Industries" ("A very elite, botique booking agency for some of the hottest bands in today's modern hardcore/pop/punk rock scene...") -- Spam, deleted.
"Dustin Thornton", created by user "dustin" - D'oh. Challenged as non-notable.
Net new encyclopedic content added: zero. That's Wikipedia today. It takes an army of hard working editors to fight off all the obvious dreck, and they're falling behind.
The number of people who've actually done anything in this area isn't that big yet,
and not many of those who have write much beyond academic papers.
There's something of a dearth of mid-level robot material. There's the low-end stuff from Tab Books, and the theory from IEEE Transaction on Robotics, but not much practically-oriented material in the middle. I try to encourage people to take the high end technology and actually use it.
Gates has changed direction. This is significant.
on
Bill Gates on Robots
·
· Score: 5, Informative
This is a significant change in direction for Bill Gates. Up until 2000 or so, he'd publicly stated that robotics wasn't going anywhere.
I ran one of the DARPA Grand Challenge teams, Team Overbot, so I'm reasonably familar with what's going on in this area. It was amazing to me how much progress was made in three years. Much of the progress was in subsystems.
Four years ago, a high precision combination GPS/INS/compass system cost about $100,000,
and required 4U of rack space with air conditioning. (CMU's first vehicle actually had such a unit.) Now, such units are about $6K, the size of a thick book, and don't need A/C. LIDAR units have gone from mechanical line scanners to solid state 3D flash units; although these are still expensive, low-volume items, there's no fundamental reason they couldn't be brought down to camcorder prices.
More interestingly, computer vision in unstructured environments is actually starting to work. That was the real innovation in the Stanford vehicle - a vision system that could look at a distant section of a road and decide if it was similar to the nearby section.
Several LIDAR units profiled the near section, and if the near section was OK and the far section was visually similar, the vehicle could outdrive its LIDAR range. I was amazed that that worked, but it did. It's a Bayesian statistics system, and quite clever.
Then there are the new generation of hobbyist robots. See Robots Dreams, which follows Japanese hobby robotics. You can get a good humanoid robot about 50cm high for about $1000 now.
It's interesting how this happened. Robotics hobbyists have been playing around with R/C servos for decades, and quietly, under consumer pressure, those servos have been getting better.
The motors used to be too weak, but better magnets fixed that. Then people complained of bearing failure, so the manufacturers switched to ball bearings. Then applied loads would sometimes strip gear teeth, so the manufacturers had to go to better gear materials. Then the things were overpowered for their dumb control algorithm, so each servo got an embedded micro controller. Then it was necessary to tune the control algorithm depending on load, so the interface became more intelligent and bidirectional.
And suddenly we had servos strong enough for the legs of a small running robot.
In the hobbyist community, though, the software is way too dumb. Hobbyists are still using BASIC STAMPs and typically don't do much very exciting on the control front. By contrast, Grand Challenge vehicles typically had many CPUs running highly concurrent software. We had two Pentium IV machines running QNX and running about fifteen real time programs, along with five programmable motor controllers each closing some control loop.
Gates is onto something with building better tools for hobbyist robotics. The Microsoft approach to robotics is clunky (it's a rehash of web technologies, including SOAP), but
it has more integration than anything seen before, so it will catch on.
Once we get the theory and technology from the high end down into hobbyist level hardware, things are really going to take off. We have the parts now.
You can't run a commercial business with volunteers in the US. It's illegal. Violates minimum wage laws. AOL ran into this in 1995, and had to pay back pay to all their forum moderators. "Labor attorney Victor Van Bourg added that volunteers "are employees of the companies, and they should be paid," he said."
With Wikipedia, it wouldn't be hard to establish that many editors are doing real work. There are rules, supervision, control, standards, and lists of things to be done. That's work.
As I wrote once before, social networking sites, like nightclubs, have a life cycle. They start out, get some users, and if they're well run and lucky, become cool. Then they become too popular, the percentage of losers goes up, the cool people leave, and they go into a slow decline.
This has already happened to AOL (peaked sometime last century), Geocities (peaked before 2002), Nerve (peaked in 2002), and Tribe (peaked in Q1 2006). Facebook, Myspace, and LinkedIn look flat, but it's too early to tell.
Who's on the way up? YouTube, which is rapidly acquiring social-networking features.
(Slashdot, incidentally, peaked in Q1 2006, when Digg took off.)
Those are kind of lame predictions. We can do better.
Telcos move into the music business. We're about to see a big collision - phone companies vs. the music industry. The music player will move into the phone, and
the telcos will control music distribution. Big losers: broadcast radio and Apple.
Flat-screen TVs pass CRT sales. 2007 will be the year Joe Sixpack gets a flat screen. Look for low-end units with fewer cables and connectors.
Semi-automatic driving deployment begins. The driverless car is coming.
In the meantime, we're starting to see cars shipping with systems that prevent
rear-end collisions. Those systems will acquire more control authority.
ISP authentication of client systems starts. Microsoft's system for
authenticating systems during DHCP negotiation starts to be adopted by ISPs.
This has many implications, some related to DRM, others to spam. Look for
things like "you have to run Vista to send more than three e-mails per hour"
as a way to make a dent in the zombie problem.
Robots start to matter. There's been quite a bit of progress lately. Look for more machines doing real work in service industries.
I wasn't happy about that either. Garbage collection in a language with destructors leads to wierd semantics, which is why Microsoft's "Managed C++" is a nightmare. I corresponded a bit with Walter Bright in the early days of D, but didn't press the issue.
What seems to work in practice is reference counting. GC gets most of the academic attention, but Perl and Python are both basically reference counted, and the result seems to be that programmers in those languages can ignore memory allocation. Java programmers have to pay a bit more attention, worrying about when GC will run and when finalizers will be called. Reference counting is deterministic; the same thing will happen every time, so timing is repeatable. That's not true of GC.
There are two basic problems with reference counts - overhead and cycles. Overhead can be dealt with by hoisting reference count updates out of loops at compile time, so that you're not frantically updating reference counts within an inner loop. Hoisting (along with common subexpression elimination), by the
way, is also the answer to subscript checking overhead.
Cycles are a more serious problem. Conceptually, the answer is strong and weak pointers (in the Perl sense, not the Java sense), which allows the programmer to express things like trees. (Links towards the leaves should be strong pointers; back pointers towards the head should be weak pointers.)
In practice, cycles aren't a serious problem, because they're generated by design errors and tend to happen in normal program operation, so they show up early in testing as memory leaks. Dangling pointers, on the other hand, tend to show up in error cases, which is why they survive testing to become delivered bugs.
Ideally, you'd like to detect cycles at the moment they're created, at least for debug purposes. This is quite possible, although there's substantial overhead.
Attempts to retrofit reference counting to C++ via templates have been made, but they are never airtight. To get anything done, raw pointers have to leak out, which makes the reference counting scheme very brittle.
In terms of mere size, this is comparable to steam engines of 1904. The Interborough Rapid Transit Company (the "IRT" to New Yorkers) built a plant in 1904 with a total output of 132,000 horsepower. The compound steam engines had bigger cylinders than this Diesel; 42 inches and 86 inches, compared to 38 inches for the new marine Diesel.
That was the high point of piston engines. Electrical generation was already converting from pistons to turbines, and even that 1904 IRT plant had a few smaller steam turbines.
There have been much more powerful marine powerplants than this, but they're usually multi-engine turbine systems.
There's an annoying tendency in commercial shipping to have only one engine on large ships, which occasionally leads to accidents.
Waxman is coming back, and so is oversight
on
2006's Bill of Wrongs
·
· Score: 4, Interesting
On Tuesday, they become the Majority Office. Congressman Waxman becomes committee chair. Investigations will start shortly thereafter. We're going to see plenty of Administration officials being asked hard questions. Under oath. On TV. That's how Waxman works.
"As set forth in House Rule X, clause 4, the Committee on Government Reform may, at any time, conduct investigations of any matter regardless of whether another standing committee has jurisdiction over the matter."
Slashdot Mirror
First, this isn't blur, it's pixelation, with big pixels. That's not the same as blur. True blur, like Gaussian blur in Photoshop, doesn't actually destroy that much information. After Gaussian blurring, each pixel has a unique value, but it's a linear combination of values from nearby pixels. There's almost as much information as before blurring; the only true losses are from rounding. That's a reversible process.
Pixelation, though, substantially reduces the amount of information in the image. Before, each pixel had a unique value. After, only each square has a unique value. So information really has been destroyed. However, if, after pixelation, the target object to be identified still has several pixels, some kind of attack might work. You need to use big enough pixel blocks that multiple target objects (like three or more letters or numbers) map to a single block. Of course, visually this will lose you the "there's sort of some number there but I can't make it out" look.
Pixelation with some crypto-grade noise added would probably solve the problem. (Remember, if the attacker can predict the noise algorithm, it doesn't help.)
What's Google being sued for?
It's kind of a cute video. The couple makes out around their friends, who seem to be completely indifferent to it, like they've seen this before. They take pictures of each other. The girl looks at the camera a few times; she knows she's being recorded and is cool with it. Then they go off and have sex in the surf, and again, there's a glance towards the camera now and then. Good sex scene. No big deal.
I'm surprised there's any objection from Brazil about this. I'd expect whining from the religious right in the US, but from Brazil?
Mod parent up.
In Vista, Microsoft puts central control from the mothership in Redmond into the OS.
Apple's answer to this: integrate spam into the OS.
Earth to Cupertino: bad idea.
(Idea for an new exploit: write an adware program which randomly injects ad slides into PowerPoint presentations.)
Nobody is explaining this right.
JavaScript has a security policy. The security model is that 1) scripts can only talk to the site from which the script came, and 2) scripts can only alter documents from the site from which the script came. The security model is enforced only at a few points, notably the XMLHttpRequest object and at points where Javascript stores into the document object tree.
Other than those few enforcement points, JavaScript objects in the same browser instance can communicate freely. This offers a number of potential exploits, some of which are listed in the paper.
If the security model is tightened up, prohibiting all intercommunication between Javascript objects from different sites, "mashups" no longer work, so it's too late to tighten this up without breaking some popular sites.
This is going to be hard to fix without breaking existing programs. Javascript has a very weak concept of what's immutable. It might work to mark functions as "dirty" if changed once loaded, then forbid "new" on "dirty" functions. That would prevent changing the base instance of a class without breaking too much else, and would fix this new vulnerability. But it wouldn't fix all potential vulnerabilities in that area. As long as multiple scripts share global variables, there's going to be potential for trouble.
Maybe "https" pages should be locked down more. "Secure" pages should be single source - everything has to come from one specific domain address. No frames, no cross-site anything - one secure site per window, and no shared data with other pages whatsoever. That's a start.
As everyone with a clue points out, he needs a heat exchanger in there somewhere.
Control Data, in Chippewa Falls, MN, used to use an outside water cooling loop which pumped warm water into the ground via one well, and pulled in cold water via another well. Ground temperature a few hundred feet down was relatively constant year round.
I once worked at a large industrial R&D center which had a sizable decorative pond with water spraying into the air in front of the building. This was actually a heat sink for the dummy loads on hydraulic transmissions. (The plant ran life cycle tests on units up to locomotive transmissions.)
But these were facilities that needed to dump tens of megawatts of heat. For a few hundred watts, it's silly.
Long before Bill Joy, UNIX had a good full-screen editor - the RAND editor. The RAND editor dated from the early 1970s. I used it at Ford Aerospace, and it was much nicer than "vi". But it wasn't free. You had to pay RAND for each copy.
The RAND editor was much closer to "what you see is what you get" than "vi". It was a full-screen editor with all the commands on function keys. All the keys like "insert", "delete", etc. did what you'd expect. Labels were provided to show what each function key did. So it was far more user-friendly than "vi".
The RAND editor was modestly portable from terminal to terminal. It worked best on HP terminals of the period, and was table driven so that it could support different devices. But you had to change the tables in C and rebuild to add support for a new device.
The RAND editor had fewer "mode" issues than "vi". What you typed went in at the cursor position. For a few special commands, like "find", a special line at the bottom of the screen was used. But you could always see visually what was going on. Much better look and feel than "vi".
Those of us who had both available used the RAND editor.
Some of what Joy is credited for in the early days of UNIX reflects the fact that he worked for a tax-funded organization working under a contract that allowed them to give software away.
I like the eye-defocusing detector. That's probably a better measurement of driving impairment. That's a fairly standard device; the phenomenon that causes "redeye" in photographs can be sensed and measured with an IR source and camera.
What to do with the information is an interesting problem. I'd think in terms of fitting something like an anti-collision radar system like the old Eaton VORAD, and if there's any indication of driver impairment, enforce much larger stopping distances by speed limiting.
I'm reading his papers, and I'm not too impressed. Read his "Network Neutrality and the Economics of Congestion", where he pontificates on that subject.
Where he goes off track is at "Fortunately, policymakers wishing to address theses problems can draw on the extensive theoretical literature exploring the economics of congestion. Much of the literature has focused on the choice between flat-rate pricing and usage-sensitive pricing. The primary finding of this literature is that competitive markets will reach an efficient equilibrium if each user is charged a usage-sensitive price set equal to their marginal contribution to congestion. 28" Reference 28 is to "28 See, e.g., Eitan Berglas, On the Theory of Clubs, 66 AM. ECON REV. 116, 119 (1976).", which is a classic paper on periodic vs per-use pricing for things like gyms and swimming pools, but is not about congestion at all.
Yao does get some things right. He recognizes that the billing cost (he says "transaction cost", but means billing overhead) for things like the Internet is higher than the cost of providing the service, and this distorts the economics from the pay-for-what-you-get model economists usually like.
But then he goes off into a right-wing rant on why vertically integrated monopolies are good. The competition between the vertically integrated monopolies will supposedly prevent prices from rising. However, he states that as an article of faith, without support. Historically, when a market gets down to small number of players, (two or three), price competition tends to weaken. The fewer the players, the easier de-facto collusion becomes.
He ignores many issues. Time scale, for example. Congestion is a problem on a scale of minutes, while carrier-switching by end users occurs on a scale of months. He also ignores contractual lock-in and technical lock-in, which makes carrier switching more expensive. If the end user's strategy is to minimize their costs over the next year, then carriers can raise their rates each year by any amount less than the cost of switching, and get away with it. He ignores that completely. (This is a chronic problem with economists. Like control theorists, they study feedback systems, but unlike control theorists, they don't consider time domain issues like stability, settling time, oscillation, and phase locking issues much.)
There's also the technical issue in Internet congestion that the congestion is mostly at the edges. If you have your own wire to the central office, as with DSL, why should there be price differentiation depending on what data you're sending and receiving? Yet it's the DSL providers who don't want network neutrality. It's not the backbone providers. Thus, congestion isn't the real issue. Wanting a bigger piece of the TV viewer's entertainment spending is.
There are people who've written well about the economics of network congestion, but this guy isn't one of them.
In 2002, Apple made it up to 5th place in servers with a 1.5% US market share. (Outside the US, zilch.)
By 2005, they were in 10th place with an 0.5% worldwide market share. (Article title: "Apple gaining momentum in server market". Maybe 2004 was worse.)
The big advantage COBOL has is that the language is serious about data storage. The language knows about structured files, databases, indices, and formatted fields. COBOL was the first language to have data structures.
Look at what a mess it is to talk to a database from Perl, Python, Java, or C/C++. There's fussy glue code required, and the language doesn't help you make sure that field XYZ in the database comes out as field XYZ in the program. In COBOL, it's straightforward. The language knows about databases. There's even a good interface to MySQL.
It also has some formatting capabilities that HTML should have had. You can write CREDIT-CARD-NUMBER PICTURE 9999-9999-9999-9999. In some systems, that will eventually result in an input field on a green screen that will only accept four fields of all numbers with all digits filled in and will display a blank form field accordingly. HTML FORM fields should have worked that way.
There are some real advantages to a language where components outside the individual programs can see, check, and use the data declarations.
Bush said of Pelosi as Speaker, before the elections, "That's not going to happen."
So, wasn't the new congress going to start trying to do something about these signing statements?
Soon. The new Democratic majority in Congress is being sworn in right now, today, this hour.
Many computer rooms have packaged units which both heat and cool, and some also both humidify and dehumidify. That's fine if you only have one. If you have more than one, they need to be interlocked so you don't get one cooling while another is heating, or one humidifying while another is dehumidifying. If you get into that situation, everything will seem to be just fine, but your energy bills will be maybe 5x what they should be.
Saw that situation in a server room at Stanford a few years ago.
Yeah, and it's a huge hassle in vacant commercial buildings. Somebody needs to run every water tap and flush every toilet about once a month, or the whole place will stink up. Then the smell gets into the carpeting, which makes it hard to rent the building.
For special situations, there are calibrated drip valves. These are often found as part of fire sprinkler systems, which usually have a drain valve for when you need to drain the system for maintenance. The water from the drain valve has to go somewhere, which usually means a sewer connection. But you can't hook a water line to a sewer line; there are situations when you'd suck sewerage into the water system. So there has to be a vacuum break open to air. After the vacuum break, there's a U-trap with water to keep sewer gas inside. But since such drains are seldom used, the water will evaporate. So a tiny bit of water has to be dripped into the drain to keep up with evaporation. There are special "drip valves" for this.
One of the things you need to know about if you run large data centers.
What I think is that however it does not look to me that robotics as an industry could ever enjoy the _same_ degree of modularization enjoyed by the computer industry.
Take a look at the LynxMotion Servo Erector Set. Modular robot kits are already here, and we're not taking about Lego.
Or - and let's face it, this is a good idea - the most contested articles will have to end up restricted to people with a certain editing "score".
Doesn't help. The people who add good content typically don't make large numbers of edits, or add large numbers of articles. They write a good article or two on something they really know something about, and leave. The people who have huge edit counts are typically deleting material, not adding it. There's no obvious way to identify the good writers prospectively.
Wikipedia is drowning under the incoming dreck. Here are the last ten new articles on Wikipedia today:
Net new encyclopedic content added: zero. That's Wikipedia today. It takes an army of hard working editors to fight off all the obvious dreck, and they're falling behind.
The number of people who've actually done anything in this area isn't that big yet, and not many of those who have write much beyond academic papers. There's something of a dearth of mid-level robot material. There's the low-end stuff from Tab Books, and the theory from IEEE Transaction on Robotics, but not much practically-oriented material in the middle. I try to encourage people to take the high end technology and actually use it.
This is a significant change in direction for Bill Gates. Up until 2000 or so, he'd publicly stated that robotics wasn't going anywhere.
I ran one of the DARPA Grand Challenge teams, Team Overbot, so I'm reasonably familar with what's going on in this area. It was amazing to me how much progress was made in three years. Much of the progress was in subsystems. Four years ago, a high precision combination GPS/INS/compass system cost about $100,000, and required 4U of rack space with air conditioning. (CMU's first vehicle actually had such a unit.) Now, such units are about $6K, the size of a thick book, and don't need A/C. LIDAR units have gone from mechanical line scanners to solid state 3D flash units; although these are still expensive, low-volume items, there's no fundamental reason they couldn't be brought down to camcorder prices.
More interestingly, computer vision in unstructured environments is actually starting to work. That was the real innovation in the Stanford vehicle - a vision system that could look at a distant section of a road and decide if it was similar to the nearby section. Several LIDAR units profiled the near section, and if the near section was OK and the far section was visually similar, the vehicle could outdrive its LIDAR range. I was amazed that that worked, but it did. It's a Bayesian statistics system, and quite clever.
Then there are the new generation of hobbyist robots. See Robots Dreams, which follows Japanese hobby robotics. You can get a good humanoid robot about 50cm high for about $1000 now. It's interesting how this happened. Robotics hobbyists have been playing around with R/C servos for decades, and quietly, under consumer pressure, those servos have been getting better. The motors used to be too weak, but better magnets fixed that. Then people complained of bearing failure, so the manufacturers switched to ball bearings. Then applied loads would sometimes strip gear teeth, so the manufacturers had to go to better gear materials. Then the things were overpowered for their dumb control algorithm, so each servo got an embedded micro controller. Then it was necessary to tune the control algorithm depending on load, so the interface became more intelligent and bidirectional. And suddenly we had servos strong enough for the legs of a small running robot.
In the hobbyist community, though, the software is way too dumb. Hobbyists are still using BASIC STAMPs and typically don't do much very exciting on the control front. By contrast, Grand Challenge vehicles typically had many CPUs running highly concurrent software. We had two Pentium IV machines running QNX and running about fifteen real time programs, along with five programmable motor controllers each closing some control loop. Gates is onto something with building better tools for hobbyist robotics. The Microsoft approach to robotics is clunky (it's a rehash of web technologies, including SOAP), but it has more integration than anything seen before, so it will catch on.
Once we get the theory and technology from the high end down into hobbyist level hardware, things are really going to take off. We have the parts now.
You can't run a commercial business with volunteers in the US. It's illegal. Violates minimum wage laws. AOL ran into this in 1995, and had to pay back pay to all their forum moderators. "Labor attorney Victor Van Bourg added that volunteers "are employees of the companies, and they should be paid," he said."
With Wikipedia, it wouldn't be hard to establish that many editors are doing real work. There are rules, supervision, control, standards, and lists of things to be done. That's work.
As I wrote once before, social networking sites, like nightclubs, have a life cycle. They start out, get some users, and if they're well run and lucky, become cool. Then they become too popular, the percentage of losers goes up, the cool people leave, and they go into a slow decline.
This has already happened to AOL (peaked sometime last century), Geocities (peaked before 2002), Nerve (peaked in 2002), and Tribe (peaked in Q1 2006). Facebook, Myspace, and LinkedIn look flat, but it's too early to tell.
Who's on the way up? YouTube, which is rapidly acquiring social-networking features.
(Slashdot, incidentally, peaked in Q1 2006, when Digg took off.)
I wasn't happy about that either. Garbage collection in a language with destructors leads to wierd semantics, which is why Microsoft's "Managed C++" is a nightmare. I corresponded a bit with Walter Bright in the early days of D, but didn't press the issue.
What seems to work in practice is reference counting. GC gets most of the academic attention, but Perl and Python are both basically reference counted, and the result seems to be that programmers in those languages can ignore memory allocation. Java programmers have to pay a bit more attention, worrying about when GC will run and when finalizers will be called. Reference counting is deterministic; the same thing will happen every time, so timing is repeatable. That's not true of GC.
There are two basic problems with reference counts - overhead and cycles. Overhead can be dealt with by hoisting reference count updates out of loops at compile time, so that you're not frantically updating reference counts within an inner loop. Hoisting (along with common subexpression elimination), by the way, is also the answer to subscript checking overhead.
Cycles are a more serious problem. Conceptually, the answer is strong and weak pointers (in the Perl sense, not the Java sense), which allows the programmer to express things like trees. (Links towards the leaves should be strong pointers; back pointers towards the head should be weak pointers.)
In practice, cycles aren't a serious problem, because they're generated by design errors and tend to happen in normal program operation, so they show up early in testing as memory leaks. Dangling pointers, on the other hand, tend to show up in error cases, which is why they survive testing to become delivered bugs.
Ideally, you'd like to detect cycles at the moment they're created, at least for debug purposes. This is quite possible, although there's substantial overhead.
Attempts to retrofit reference counting to C++ via templates have been made, but they are never airtight. To get anything done, raw pointers have to leak out, which makes the reference counting scheme very brittle.
In terms of mere size, this is comparable to steam engines of 1904. The Interborough Rapid Transit Company (the "IRT" to New Yorkers) built a plant in 1904 with a total output of 132,000 horsepower. The compound steam engines had bigger cylinders than this Diesel; 42 inches and 86 inches, compared to 38 inches for the new marine Diesel.
That was the high point of piston engines. Electrical generation was already converting from pistons to turbines, and even that 1904 IRT plant had a few smaller steam turbines.
There have been much more powerful marine powerplants than this, but they're usually multi-engine turbine systems. There's an annoying tendency in commercial shipping to have only one engine on large ships, which occasionally leads to accidents.
Check out the Committee on Government Reform, United States House of Representatives, Minority Office. This is the official view of congressional Democrats of what the administration has been doing wrong. They're the minority office, so they can't do much except update their web site.
On Tuesday, they become the Majority Office. Congressman Waxman becomes committee chair. Investigations will start shortly thereafter. We're going to see plenty of Administration officials being asked hard questions. Under oath. On TV. That's how Waxman works.
"As set forth in House Rule X, clause 4, the Committee on Government Reform may, at any time, conduct investigations of any matter regardless of whether another standing committee has jurisdiction over the matter."