We'd considered doing something like this for ad links. We offer the AdRater plug-in, which checks the legitimacy of advertised sites and puts a rating icon atop each ad. For some ad URLs, we can decode the URL and see what site is being advertised, so we don't have to follow the link.
But there are cases where that's not enough. Sometimes the advertised site is just a redirector, and we'd like to follow the redirection chain and rate the ultimate target. Sometimes, the ad links are obfusicated. (Google doesn't do that; DoubleClick does.) For those cases, we'd have to pre-read the ad site from the plug-in in the user's browser, but not render the ad into a window.
If we do that, every advertiser sees a false click-through for every ad displayed. The AdWords advertiser community would not be happy.
This isn't really "AI". It's basically a way of feeding measured performance data back into the compiler. Intel compilers for embedded CPUs have been doing that for years.
With modern superscalar CPUs, it's not always clear whether an optimization transformation is a win or a lose. This varies with the implementation, not the architecture. For some x86 CPUs, unrolling a loop is a win; for others, it's a lose. Whether it's a win or a lose may depend on details of the loop and of the CPU implementation, like how much register renaming capacity the CPU has.
Whether this is a good idea, though, is questionable. You can get an executable very well tuned to a given CPU implementation, but run it on a different CPU and it may be worse than the vanilla version. MIPS machines (remember MIPS?) can get faster execution if the executable is complied for the specific target CPU, not the generic MIPS architecture. This effect is strong enough that MIPS applications tended to come with multiple executables, any of which would run on any of MIPS machines, but would work better if the executable matched. This is a pain from a distribution and development standpoint.
The embedded community goes in for stuff like this, but that's because they ship the CPU and the code together and know it matches. For general-use software, a 10% speed improvement probably isn't worth the multiple version headache.
Also, if you have multiple versions for different CPUs, some bugs may behave differently on different CPUs, which is a maintenance headache.
Gallium is a by-product of bauxite refining, so there's no fundamental shortage. But only a small percentage of the world's bauxite production is run through a process for gallium extraction.
A very real problem is that the extraction of many of the rarer minerals is energy-intensive. Huge amounts of raw materials have to be processed to get small amounts of gallium, indium, or zirconium. With low energy prices, this isn't so bad, but as energy prices go up, so do the prices of the harder-to-extract raw materials.
Human civilization is about 5000 years old.
Industrial civilization is only about 200 years old. Most of the easy to extract ores were mined out decades ago. There aren't enough extractable minerals to keep it going another 200 years.
We haven't had a new, big energy source in 50 years now. It's been 50 years since the first commercial power reactor sold its first kilowatt hour. There's nothing promising on the horizon, either. Expecting energy-intensive extraction methods to solve the minerals problem isn't a promising direction.
Operations serious about security do a badge exchange when you enter the facility. You present your "outside" badge, which is validated at the security checkpoint, and exchange it for your "inside" badge, which never leaves the facility. This forces the security people to really check your outside badge, and makes the inside badges harder to copy, since they're not seen outside the facility. Information about what areas you're allowed to access appears only on inside badges. Outside badges won't open anything; inside badges may also be keys.
There are places with tight security like that, and I've been to some of them. The overhead is high. For bidding purposes at a major aerospace company, we used to estimate that running a project at SECRET doubled the bid, and running at TOP SECRET ran the price up by 4x or more. At the higher levels, computers are in metal rooms with welded seams raised off the floor (so Security can check underneath) and with RF-tight airlocks. Signing documents in and out of files takes a big chunk of staff resources and time. There's a big bureaucracy associated with accountability.
One of the serious side effects of running highly classified projects is that the people working on them become obsolete in place. They're so cut off from the outside world that they don't keep up, outside their very narrow area of expertise. That's why I left aerospace and went to the commercial world.
The Word format document is interesting. Much of this has previously been reverse engineered, but it's good to see the documentation. First, there are several layers of packaging and encapsulation before you get to the actual content (the "WordDocument stream"). The actual content is an indexed collection of "characters", but they're not stored in sequence. Section 2.4.1 (page 37) describes the algorithm for retrieving character N. It's clearly essential to do some caching to read the document efficiently. This seems to be a mechanism to allow "fast save", where only parts of the document file are updated.
Within Word files, there are lists of properties which apply to a range of characters. This is the basic structure of formatting information. It's not, though, the only form of formatting information. Some info, like paragraph boundaries, table cell boundaries, and section boundaries, are stored as character values in the character stream.
This should be a big help to Open Office's import filter, which has trouble getting correct positioning info from Word documents.
The user must be in charge. Not the remote site. Not any "toolbars".
Specifically,
All "toolbars", "branding", codecs, DRM keys, and other installed browser helper objects must show as clearly identified items that can be easily disabled, restored to their initial state, or removed completely.
Nothing is ever downloaded to any place other than the browser cache without explicit interaction from the user. This specifically includes codecs and DRM code.
Pages cannot disable menus or menu items. The "back" button always works, although pages are permitted to notice that they were reached via the "back" button.
If the user chooses to disable popups, all popups must be disabled.
All pop-ups must be on top. No "pop-unders".
Pop-ups are treated as subordinate pages of the page from which they were launched. When the parent page closes, so must the pop-up.
Ad-blocking support should conceal from the remote site that the ad is being blocked.
Windows that are not on top should be limited in their resource consumption when they have active content running.
You get the idea. When it's user vs. website or user vs. toolbar, the user wins.
Nobody really "upgrades" existing PCs any more. Over 80% of desktops are never opened once installed, and for laptops, the percentage is even higher. It's consumer electronics. The "upgrade" market for PCs isn't mainstream; it's more like the "speed shop" market for cars.
I'd thought of this a while back. The general idea is that given blocks A B C,
A XOR B = some copyrighted content, A XOR C = some public domain content, B XOR C = junk.
This can be extended to require more than two blocks at a time. It's probably not defensible legally, and you have to store and ship around twice as much data.
If you get both cable Internet and DSL, there are some interesting options. Cable usually has better downlink bandwidth than DSL, but DSL has better uplink bandwidth, especially during peak periods. So sending some or all of the upstream packets on the DSL link while getting all the incoming traffic on the cable link could be a win. The IP of the cable link can be used for sending on the DSL link or the cable link. The downstream direction of the DSL link is unused.
You'll need to configure a local router to handle this, but you don't need to go all the way
to BGP and getting your own autonomous system number.
Oh, the virtual circuit guy. I interviewed with Telenet when they had 13 employees, so I met him in the 1970s. Telenet HQ was in a big mansion-like house. It seemed too weird to succeed, and I didn't want the job.
The virtual circuit vs. datagram battle is almost forgotten now, but it was a major issue
before fiber optics provided vast cheap long-haul bandwidth. Remember, the ARPANET backbone was only 56Kb. Long-haul leased bandwidth was incredibly expensive through the 1980s.
If the backbone bandwidth is the constraint on network traffic, congestion management of a pure datagram network is very tough. I had to run such a network in the early 1980s, which is why I have all those classic RFCs and papers on network congestion. We figured out how TCP should play nice to avoid congestion collapse, and how fair queuing could give the network some defenses against overload. That was enough to make a network of reasonably-well behaved nodes not doing anything with real-time constraints behave.
In the days of congested backbones, virtual circuits were looking like the future, because they were more manageable. Bandwidth could be assigned at connection setup, and each connection throttled. Tymnet and Telenet worked that way. That approach became obsolete when local area networks became widely used; none of them were virtual circuit, so the backbone had to be at the datagram level. Then fibre optics came along and saved the backbone.
We still don't really know what to do when the backbone is the bottleneck and latency matters. "p2p" file transfer isn't the problem, though. HDTV over the Internet is the problem. There isn't enough backbone bandwidth to support the world's couch potatoes with real-time HDTV streams.
Microsoft at one point proposed a system where real-time HDTV would be multicast, while video on demand would be heavily buffered. That could work, but multicasting with bandwidth guarantees requires more centralized control than the Internet usually has today, which is probably why Microsoft and parts of the broadcast industry liked it.
The "p2p" thing is a side issue. The big issue is going to be who gets to throttle whose HDTV streams. The cable guys want really, really bad to charge extra for those streams, regardless of who originates them.
Air travel isn't profitable
on
Terminal Chaos
·
· Score: 1
Overall, the entire history of aviation is a slight financial loss. Someone worked that out around 2000, before 9/11. It's striking how many airlines go bankrupt. We've lost two so far this year (Aloha and ATA), and those are just the ones that ceased operations outright.
No, they're only available where the original declaration is visible. Try:
void arraylength(int tab[])
{ printf("size of tab: %d\n",sizeof(tab)); }
which won't work. "sizeof" is not meaningful in that context.
Compare FORTRAN, which allows
SUBROUTINE ARRAYLENGTH(TAB, N)
INT TAB(N) ! conformant array declaration using param
WRITE(*,*) SIZE(TAB) ! write size of array, as known by language
This carries along the info needed for subscript checking. It also encourages
users to request the size of an array from a known good source.
The retrofit of conformant arrays into FORTRAN wasn't perfect, but it's
ahead of C/C++. ISO Pascal, of course, also has conformant arrays, as do Modula 1/2/3, Ada, and Delphi.
There's really nothing new there. It's the usual Strostrup stuff. He's still in denial about C++ being the cause of most of the buffer overflows, system crashes, and security holes in the world.
The fundamental problem with C was the "array=pointer" concept. If array sizes were carried along with arrays, we'd have far less trouble. Even FORTRAN has conformant
array parameters. That should have been fixed in C++, but it wasn't, and as a result, we had
two more decades of buffer overflow problems. This isn't a performance issue, by
the way; Modula 3 got it right, but Modula 3 disappeared for non-technical reasons - Compaq bought DEC and
closed down the software R&D operation.
C++ is also the only language that has hiding ("abstraction") without memory safety. C has neither; almost all later languages (Java, Delphi, all the scripting languages) have both.
C++ stands alone in this unsafe place. Nobody ever repeated that mistake. So subtly incorrect calls to objects can result in the object overflowing.
Yes, some of these problems can be papered over with templates. The C++ committee is full of templateheads, focused on template features that few will use and fewer will use correctly and productively. That crowd is still struggling to make auto_ptr work.
Most of Wikipedia is a collection of static pages. Most users of Wikipedia are just reading the latest version of an article, to which they were taken by a non-Wikipedia search engine.
So all Wikipedia has to do for them is serve a static page. No database work or page generation is required.
Older revisions of pages come from the database, as do the versions one sees during editing and previewing, the history information, and such. Those operations involve the MySQL databases. There are only about 10-20 updates per second taking place in the editing end of the system. When a page is updated, static copies are propagated out to the static page servers after a few tens of seconds.
Article editing is a check-out/check in system. When you start editing a page, you get a version token, and when you update the page, the token has to match the latest revision or you get an edit conflict. It's all standard form requests; there's no need for frantic XMLHttpRequest processing while you're working on a page.
Because there are no ads, there's no overhead associated with inserting variable ad info into the pages. No need for ad rotators, ad trackers, "beacons" or similar overhead.
The big breakthrough was the DARPA Grand Challenge. Up until the 2005 DARPA Grand Challenge, mobile robots had been something of a joke. They'd been a joke since Elektro was shown at the 1939 World's Fair. But on the second day of the 2005 Grand Challenge event at the California Motor Speedway, suddenly they stopped being a joke. Forty-three autonomous vehicles were running around and they all worked. The ones that didn't had been eliminated in previous rounds.
Up until the Grand Challenge, robotics R&D had been done by small research groups under no pressure to produce working systems. Most systems were one-offs that were never deployed. DARPA figured out how to get results. There was a carrot (the $2 million prize), and a stick (universities that didn't get results risked having their DARPA funding for robotics cut off.)
The other big result from the DARPA Grand Challenge was that robotics projects became much larger. Nobody had 50-100 people on a robotics R&D project until then (well, maybe Honda). Robotics projects used to be a professor and 2 or 3 grad students. Suddenly stuff was getting done faster.
DoD started pushing harder. Robots like Big Dog got enough money to be forced through to working systems. Little tracked machines were going to battlefields in quantity, and enough engineering effort was put into mechanical reliability to make the things really work.
CPU power helped. Texture-based vision now works.
Vision-based SLAM went from a 2D algorithm that sometimes worked indoors to a solid technology that worked outdoors. Much of early vision processing is now done in
GPUs, which are just right for doing dumb local operations like convolution in bulk.
GPS and inertial hardware got better and cheaper.
Some of the mundane parts, like servomotor controllers, improved considerably. Compact hydraulic systems improved substantially.
It's finally happening.
As for the hard stuff, situational awareness and common sense, watch the NPCs in games get smarter.
As I point out occasionally, social networking sites have a life cycle, like good nightclubs and restaurants. They start up, if they're lucky, the cool people go there. They grow, they get too many losers, the cool people leave, and they decline.
Once upon a time AOL was cool. That was a long time ago. Geocities and EZboard were cool for a while. Remember them? Nerve and Tribe were once cool; now they're dying. Now it's Myspace's turn. Today, to a teenager, Myspace is what your little brother uses. Social networking sites have a shelf life of maybe five years.
This is reflected in traffic stats, which is where I got a clear picture of this effect.
The Alexa traffic statistics were useful for seeing when a site peaked. Unfortunately, the Alexa people recently "widgetized" their site, and they broke the "Max" button on their traffic graphs, so you can't currently see historical data for past years. Maybe they'll fix it.
California prosecutors have used B&P code section 17538 when dealing with complaints against online businesses. If the business didn't comply with the address disclosure requirements, but accepted credit cards, the maximum penalty is six months in jail for that alone. Do anything that brings your anonymous business to the attention of prosecutors, and they have that hammer to hold over you.
Geodesic domes work quite well if built properly from the right materials. They've been protecting big radars in arctic environments since the 1950s, which is an impressive achievement.
The residential domeheads took a wrong turn when they tried to make small domes out of "natural materials". Trying to shingle a sphere was a terrible idea. Putting together prefab parts is the way to go. Fibreglas works well, but the "Mr. Natural" types didn't like Fibreglas. As Fuller pointed out, domes have to be manufactured products made cheaply, with precision, in quantity.
There's also a subtle structural problem with domes that wasn't well understood until they could be computer-simulated. The abstract geometry produces a good structure. But in the real world, differential thermal expansion, when the sun is hitting one side of the dome more than the other, produces sizable stresses in the dome, which distorts slighlty. This was one of the major causes of leaks.
The other major problems come from the fact that domes require a whole range of architectural components specifically designed for them, from electrical conduits to kitchen cabinets to windows. Parts designed for rectangular structures don't fit well.
There's been a formal study of bad WHOIS data by the Government Accounting Office, the investigative arm of Congress, titled "Prevalence of False Contact Information for Registered Domain Names", on this topic. They found at least 8% of contact info in WHOIS to be totally bogus. They also, as a test of ICANN, submitted 45 "WHOIS information problem reports", of which 11 resulted in correction and 33 did not. But GAO didn't break down the data by registrar.
We've been interested in this issue at SiteTruth for some time. We take a broader view of "bad" web sites than most; we consider any commercial site that lacks valid business name and address information to be bogus. Over 35% of Google AdWords advertisers fail that test. For advertisers whose ads appear on Myspace, the ratio is much higher.
Originally, we tried to get contact information from WHOIS data, but the data quality
was so appallingly bad that we had to develop another approach. We have a system that looks for contact info the way a user would, looking at pages with names like "About", "Contact", and such, trying to find a user-readable street address. We also have some big databases of business addresses to check against. This turns out to work much better than looking at WHOIS data when the goal is to find the business behind the web site.
(You can see this info using our AdRater plug-in for Firefox. Download our plug-in to see the ratings for each Google advertiser as the ads go by. Unless you're already blocking all such ads, of course.)
This decision cites Bridgeman vs. Corel favorably. Four times. This is important.
The key decision on "originality" in US copyright law is Feist vs. Rural Telephone. The information in lists, like telephone directories, is not a creative work and is copyrightable. You can scan in the phone book, load it into a database, and make it available on the web. Feist was a U.S. Supreme Court decision, and it created the third-party phone book industry, then made possible much useful repurposing of existing data. The decision in Feist stems from the Constitutional definition of copyright: "To promote the progress of science and useful arts, by securing for limited times to authors and inventors the exclusive right to their respective writings and discoveries." The Supreme Court ruled that originality is required.
Based on Feist, a district court ruled, in Bridgeman vs. Corel, that photos of public domain paintings are not copyrightable. This opened the door to much free reuse of photos of old images, such as famous old artworks. There was much griping about Bridgeman from the museum community, one of the gripes being that it was "only" a district court decision. Well, now we have the Tenth Circuit Court of Appeals saying not only that Bridgeman is good law (see p.18 of the decision), but that the concept in Bridgeman extends to 3D models of existing objects. So that's settled in US law.
ISPs should never muck with a TCP stream. They're entitled to send ICMP messages. ICMP Destination Unreachable has codes for things like "(13) Communications Administratively Prohibited" and "(10) Destination host administratively prohibited". Then at least the user knows 1) that somebody along the route didn't like the packet, and 2) who to blame. There's a right way to do this, and sending an RST isn't it.
Client software may not pass all the ICMP info up to the user, but that could be fixed easily enough.
Slashdot Mirror
We'd considered doing something like this for ad links. We offer the AdRater plug-in, which checks the legitimacy of advertised sites and puts a rating icon atop each ad. For some ad URLs, we can decode the URL and see what site is being advertised, so we don't have to follow the link. But there are cases where that's not enough. Sometimes the advertised site is just a redirector, and we'd like to follow the redirection chain and rate the ultimate target. Sometimes, the ad links are obfusicated. (Google doesn't do that; DoubleClick does.) For those cases, we'd have to pre-read the ad site from the plug-in in the user's browser, but not render the ad into a window.
If we do that, every advertiser sees a false click-through for every ad displayed. The AdWords advertiser community would not be happy.
This is the same problem AVG hit.
This isn't really "AI". It's basically a way of feeding measured performance data back into the compiler. Intel compilers for embedded CPUs have been doing that for years.
With modern superscalar CPUs, it's not always clear whether an optimization transformation is a win or a lose. This varies with the implementation, not the architecture. For some x86 CPUs, unrolling a loop is a win; for others, it's a lose. Whether it's a win or a lose may depend on details of the loop and of the CPU implementation, like how much register renaming capacity the CPU has.
Whether this is a good idea, though, is questionable. You can get an executable very well tuned to a given CPU implementation, but run it on a different CPU and it may be worse than the vanilla version. MIPS machines (remember MIPS?) can get faster execution if the executable is complied for the specific target CPU, not the generic MIPS architecture. This effect is strong enough that MIPS applications tended to come with multiple executables, any of which would run on any of MIPS machines, but would work better if the executable matched. This is a pain from a distribution and development standpoint.
The embedded community goes in for stuff like this, but that's because they ship the CPU and the code together and know it matches. For general-use software, a 10% speed improvement probably isn't worth the multiple version headache.
Also, if you have multiple versions for different CPUs, some bugs may behave differently on different CPUs, which is a maintenance headache.
Gallium is a by-product of bauxite refining, so there's no fundamental shortage. But only a small percentage of the world's bauxite production is run through a process for gallium extraction.
A very real problem is that the extraction of many of the rarer minerals is energy-intensive. Huge amounts of raw materials have to be processed to get small amounts of gallium, indium, or zirconium. With low energy prices, this isn't so bad, but as energy prices go up, so do the prices of the harder-to-extract raw materials.
Human civilization is about 5000 years old. Industrial civilization is only about 200 years old. Most of the easy to extract ores were mined out decades ago. There aren't enough extractable minerals to keep it going another 200 years.
We haven't had a new, big energy source in 50 years now. It's been 50 years since the first commercial power reactor sold its first kilowatt hour. There's nothing promising on the horizon, either. Expecting energy-intensive extraction methods to solve the minerals problem isn't a promising direction.
Operations serious about security do a badge exchange when you enter the facility. You present your "outside" badge, which is validated at the security checkpoint, and exchange it for your "inside" badge, which never leaves the facility. This forces the security people to really check your outside badge, and makes the inside badges harder to copy, since they're not seen outside the facility. Information about what areas you're allowed to access appears only on inside badges. Outside badges won't open anything; inside badges may also be keys.
There are places with tight security like that, and I've been to some of them. The overhead is high. For bidding purposes at a major aerospace company, we used to estimate that running a project at SECRET doubled the bid, and running at TOP SECRET ran the price up by 4x or more. At the higher levels, computers are in metal rooms with welded seams raised off the floor (so Security can check underneath) and with RF-tight airlocks. Signing documents in and out of files takes a big chunk of staff resources and time. There's a big bureaucracy associated with accountability.
One of the serious side effects of running highly classified projects is that the people working on them become obsolete in place. They're so cut off from the outside world that they don't keep up, outside their very narrow area of expertise. That's why I left aerospace and went to the commercial world.
The Word format document is interesting. Much of this has previously been reverse engineered, but it's good to see the documentation. First, there are several layers of packaging and encapsulation before you get to the actual content (the "WordDocument stream"). The actual content is an indexed collection of "characters", but they're not stored in sequence. Section 2.4.1 (page 37) describes the algorithm for retrieving character N. It's clearly essential to do some caching to read the document efficiently. This seems to be a mechanism to allow "fast save", where only parts of the document file are updated.
Within Word files, there are lists of properties which apply to a range of characters. This is the basic structure of formatting information. It's not, though, the only form of formatting information. Some info, like paragraph boundaries, table cell boundaries, and section boundaries, are stored as character values in the character stream.
This should be a big help to Open Office's import filter, which has trouble getting correct positioning info from Word documents.
The user must be in charge. Not the remote site. Not any "toolbars". Specifically,
You get the idea. When it's user vs. website or user vs. toolbar, the user wins.
Nobody really "upgrades" existing PCs any more. Over 80% of desktops are never opened once installed, and for laptops, the percentage is even higher. It's consumer electronics. The "upgrade" market for PCs isn't mainstream; it's more like the "speed shop" market for cars.
I'd thought of this a while back. The general idea is that given blocks A B C, A XOR B = some copyrighted content, A XOR C = some public domain content, B XOR C = junk. This can be extended to require more than two blocks at a time. It's probably not defensible legally, and you have to store and ship around twice as much data.
If you get both cable Internet and DSL, there are some interesting options. Cable usually has better downlink bandwidth than DSL, but DSL has better uplink bandwidth, especially during peak periods. So sending some or all of the upstream packets on the DSL link while getting all the incoming traffic on the cable link could be a win. The IP of the cable link can be used for sending on the DSL link or the cable link. The downstream direction of the DSL link is unused. You'll need to configure a local router to handle this, but you don't need to go all the way to BGP and getting your own autonomous system number.
Oh, the virtual circuit guy. I interviewed with Telenet when they had 13 employees, so I met him in the 1970s. Telenet HQ was in a big mansion-like house. It seemed too weird to succeed, and I didn't want the job.
The virtual circuit vs. datagram battle is almost forgotten now, but it was a major issue before fiber optics provided vast cheap long-haul bandwidth. Remember, the ARPANET backbone was only 56Kb. Long-haul leased bandwidth was incredibly expensive through the 1980s.
If the backbone bandwidth is the constraint on network traffic, congestion management of a pure datagram network is very tough. I had to run such a network in the early 1980s, which is why I have all those classic RFCs and papers on network congestion. We figured out how TCP should play nice to avoid congestion collapse, and how fair queuing could give the network some defenses against overload. That was enough to make a network of reasonably-well behaved nodes not doing anything with real-time constraints behave.
In the days of congested backbones, virtual circuits were looking like the future, because they were more manageable. Bandwidth could be assigned at connection setup, and each connection throttled. Tymnet and Telenet worked that way. That approach became obsolete when local area networks became widely used; none of them were virtual circuit, so the backbone had to be at the datagram level. Then fibre optics came along and saved the backbone.
We still don't really know what to do when the backbone is the bottleneck and latency matters. "p2p" file transfer isn't the problem, though. HDTV over the Internet is the problem. There isn't enough backbone bandwidth to support the world's couch potatoes with real-time HDTV streams.
Microsoft at one point proposed a system where real-time HDTV would be multicast, while video on demand would be heavily buffered. That could work, but multicasting with bandwidth guarantees requires more centralized control than the Internet usually has today, which is probably why Microsoft and parts of the broadcast industry liked it.
The "p2p" thing is a side issue. The big issue is going to be who gets to throttle whose HDTV streams. The cable guys want really, really bad to charge extra for those streams, regardless of who originates them.
Overall, the entire history of aviation is a slight financial loss. Someone worked that out around 2000, before 9/11. It's striking how many airlines go bankrupt. We've lost two so far this year (Aloha and ATA), and those are just the ones that ceased operations outright.
Array sizes ARE carried along with arrays.
No, they're only available where the original declaration is visible. Try:
void arraylength(int tab[])
{ printf("size of tab: %d\n",sizeof(tab)); }
which won't work. "sizeof" is not meaningful in that context.
Compare FORTRAN, which allows
SUBROUTINE ARRAYLENGTH(TAB, N)
INT TAB(N) ! conformant array declaration using param
WRITE(*,*) SIZE(TAB) ! write size of array, as known by language
This carries along the info needed for subscript checking. It also encourages users to request the size of an array from a known good source.
The retrofit of conformant arrays into FORTRAN wasn't perfect, but it's ahead of C/C++. ISO Pascal, of course, also has conformant arrays, as do Modula 1/2/3, Ada, and Delphi.
First, read the printable version of the article on one page. The original version is one paragraph per page, surrounded by ads and related dreck.
There's really nothing new there. It's the usual Strostrup stuff. He's still in denial about C++ being the cause of most of the buffer overflows, system crashes, and security holes in the world.
The fundamental problem with C was the "array=pointer" concept. If array sizes were carried along with arrays, we'd have far less trouble. Even FORTRAN has conformant array parameters. That should have been fixed in C++, but it wasn't, and as a result, we had two more decades of buffer overflow problems. This isn't a performance issue, by the way; Modula 3 got it right, but Modula 3 disappeared for non-technical reasons - Compaq bought DEC and closed down the software R&D operation.
C++ is also the only language that has hiding ("abstraction") without memory safety. C has neither; almost all later languages (Java, Delphi, all the scripting languages) have both. C++ stands alone in this unsafe place. Nobody ever repeated that mistake. So subtly incorrect calls to objects can result in the object overflowing.
Yes, some of these problems can be papered over with templates. The C++ committee is full of templateheads, focused on template features that few will use and fewer will use correctly and productively. That crowd is still struggling to make auto_ptr work.
Most of Wikipedia is a collection of static pages. Most users of Wikipedia are just reading the latest version of an article, to which they were taken by a non-Wikipedia search engine. So all Wikipedia has to do for them is serve a static page. No database work or page generation is required.
Older revisions of pages come from the database, as do the versions one sees during editing and previewing, the history information, and such. Those operations involve the MySQL databases. There are only about 10-20 updates per second taking place in the editing end of the system. When a page is updated, static copies are propagated out to the static page servers after a few tens of seconds.
Article editing is a check-out/check in system. When you start editing a page, you get a version token, and when you update the page, the token has to match the latest revision or you get an edit conflict. It's all standard form requests; there's no need for frantic XMLHttpRequest processing while you're working on a page.
Because there are no ads, there's no overhead associated with inserting variable ad info into the pages. No need for ad rotators, ad trackers, "beacons" or similar overhead.
Well, what do you expect? IT today is boring. It was exciting once, but today, it's routine. Especially at the lower levels.
This is another end-of-life open sourcing. Tru64 is a legacy OS from the 1980s, but it still has some users, so HP is dumping the code out there.
ICAAN released a final draft for public comment today, June 22, 2008.
Public comment closes June 23, 2008.
The robots are coming.
The big breakthrough was the DARPA Grand Challenge. Up until the 2005 DARPA Grand Challenge, mobile robots had been something of a joke. They'd been a joke since Elektro was shown at the 1939 World's Fair. But on the second day of the 2005 Grand Challenge event at the California Motor Speedway, suddenly they stopped being a joke. Forty-three autonomous vehicles were running around and they all worked. The ones that didn't had been eliminated in previous rounds.
Up until the Grand Challenge, robotics R&D had been done by small research groups under no pressure to produce working systems. Most systems were one-offs that were never deployed. DARPA figured out how to get results. There was a carrot (the $2 million prize), and a stick (universities that didn't get results risked having their DARPA funding for robotics cut off.)
The other big result from the DARPA Grand Challenge was that robotics projects became much larger. Nobody had 50-100 people on a robotics R&D project until then (well, maybe Honda). Robotics projects used to be a professor and 2 or 3 grad students. Suddenly stuff was getting done faster.
DoD started pushing harder. Robots like Big Dog got enough money to be forced through to working systems. Little tracked machines were going to battlefields in quantity, and enough engineering effort was put into mechanical reliability to make the things really work.
CPU power helped. Texture-based vision now works. Vision-based SLAM went from a 2D algorithm that sometimes worked indoors to a solid technology that worked outdoors. Much of early vision processing is now done in GPUs, which are just right for doing dumb local operations like convolution in bulk. GPS and inertial hardware got better and cheaper. Some of the mundane parts, like servomotor controllers, improved considerably. Compact hydraulic systems improved substantially.
It's finally happening.
As for the hard stuff, situational awareness and common sense, watch the NPCs in games get smarter.
As I point out occasionally, social networking sites have a life cycle, like good nightclubs and restaurants. They start up, if they're lucky, the cool people go there. They grow, they get too many losers, the cool people leave, and they decline.
Once upon a time AOL was cool. That was a long time ago. Geocities and EZboard were cool for a while. Remember them? Nerve and Tribe were once cool; now they're dying. Now it's Myspace's turn. Today, to a teenager, Myspace is what your little brother uses. Social networking sites have a shelf life of maybe five years.
This is reflected in traffic stats, which is where I got a clear picture of this effect. The Alexa traffic statistics were useful for seeing when a site peaked. Unfortunately, the Alexa people recently "widgetized" their site, and they broke the "Max" button on their traffic graphs, so you can't currently see historical data for past years. Maybe they'll fix it.
The Next Cool Thing will probably be phone-based.
I don't want my real physical address listed on my domain for the world to see, and I don't have a P.O. box.
We get that a lot. Now go read California Business and Professions Code Section 17358, which applies if you sell to California, and the European Electronic Commerce Directive (2000/31/EC), which applies if you sell in Europe. Anonymous businesses are illegal in most of the developed world. Deal with it.
California prosecutors have used B&P code section 17538 when dealing with complaints against online businesses. If the business didn't comply with the address disclosure requirements, but accepted credit cards, the maximum penalty is six months in jail for that alone. Do anything that brings your anonymous business to the attention of prosecutors, and they have that hammer to hold over you.
Geodesic domes work quite well if built properly from the right materials. They've been protecting big radars in arctic environments since the 1950s, which is an impressive achievement.
The residential domeheads took a wrong turn when they tried to make small domes out of "natural materials". Trying to shingle a sphere was a terrible idea. Putting together prefab parts is the way to go. Fibreglas works well, but the "Mr. Natural" types didn't like Fibreglas. As Fuller pointed out, domes have to be manufactured products made cheaply, with precision, in quantity.
There's also a subtle structural problem with domes that wasn't well understood until they could be computer-simulated. The abstract geometry produces a good structure. But in the real world, differential thermal expansion, when the sun is hitting one side of the dome more than the other, produces sizable stresses in the dome, which distorts slighlty. This was one of the major causes of leaks.
The other major problems come from the fact that domes require a whole range of architectural components specifically designed for them, from electrical conduits to kitchen cabinets to windows. Parts designed for rectangular structures don't fit well.
There's been a formal study of bad WHOIS data by the Government Accounting Office, the investigative arm of Congress, titled "Prevalence of False Contact Information for Registered Domain Names", on this topic. They found at least 8% of contact info in WHOIS to be totally bogus. They also, as a test of ICANN, submitted 45 "WHOIS information problem reports", of which 11 resulted in correction and 33 did not. But GAO didn't break down the data by registrar.
We've been interested in this issue at SiteTruth for some time. We take a broader view of "bad" web sites than most; we consider any commercial site that lacks valid business name and address information to be bogus. Over 35% of Google AdWords advertisers fail that test. For advertisers whose ads appear on Myspace, the ratio is much higher.
Originally, we tried to get contact information from WHOIS data, but the data quality was so appallingly bad that we had to develop another approach. We have a system that looks for contact info the way a user would, looking at pages with names like "About", "Contact", and such, trying to find a user-readable street address. We also have some big databases of business addresses to check against. This turns out to work much better than looking at WHOIS data when the goal is to find the business behind the web site.
(You can see this info using our AdRater plug-in for Firefox. Download our plug-in to see the ratings for each Google advertiser as the ads go by. Unless you're already blocking all such ads, of course.)
This decision cites Bridgeman vs. Corel favorably. Four times. This is important.
The key decision on "originality" in US copyright law is Feist vs. Rural Telephone. The information in lists, like telephone directories, is not a creative work and is copyrightable. You can scan in the phone book, load it into a database, and make it available on the web. Feist was a U.S. Supreme Court decision, and it created the third-party phone book industry, then made possible much useful repurposing of existing data. The decision in Feist stems from the Constitutional definition of copyright: "To promote the progress of science and useful arts, by securing for limited times to authors and inventors the exclusive right to their respective writings and discoveries." The Supreme Court ruled that originality is required.
Based on Feist, a district court ruled, in Bridgeman vs. Corel, that photos of public domain paintings are not copyrightable. This opened the door to much free reuse of photos of old images, such as famous old artworks. There was much griping about Bridgeman from the museum community, one of the gripes being that it was "only" a district court decision. Well, now we have the Tenth Circuit Court of Appeals saying not only that Bridgeman is good law (see p.18 of the decision), but that the concept in Bridgeman extends to 3D models of existing objects. So that's settled in US law.
ISPs should never muck with a TCP stream. They're entitled to send ICMP messages. ICMP Destination Unreachable has codes for things like "(13) Communications Administratively Prohibited" and "(10) Destination host administratively prohibited". Then at least the user knows 1) that somebody along the route didn't like the packet, and 2) who to blame. There's a right way to do this, and sending an RST isn't it.
Client software may not pass all the ICMP info up to the user, but that could be fixed easily enough.