Gah, why is BELL on the S key and not G where it belongs?
In Baudot code, BELL can be on either the S key or the J key; BELL on the G key is an ASCII thing. CCITT Alphabet No. 2 puts BELL on the J key, but this particular Teletype was built in 1944 and predates the CCITT standard. It also has the "£" symbol rather than "#". This was the American military standard during WWII.
Model 15 teletypes have a serious bell; it's almost 3 inches across, and gives a solid "gong" sound.
The trouble with charging through a USB connector is that it's also a USB port. Most phones aren't well-protected against attacks via the USB port. With a common charger interface, you're going to find charger outlets everywhere. Some of them will be hostile.
So now you need a cable that only passes power. But that may not be enough. Motorola RAZR phones, for example, won't charge on PCs unless the Motorola driver is present to do the handshake. By default,a USB port will deliver at least 100mA, but if asked, it may deliver up to 500mA. Laptops actively manage USB power; desktop systems often don't bother.
So you may need a data connection, which opens up a whole new range of attacks on phones. Which means you may sometimes need a "firewall", a device which does the USB handshake and requests 500mA, then delivers it over a cable with no data wires.
This has been possible for a while, but with standardization, we'll have outlet strips with USB ports all over the place, in cafes, on aircraft, in cars, etc.
only to find their page delivery delayed by slow-loading ads.
Well, duh. I've been complaining about this for the past year. Too much ad code is using "document.write()", often for no really good reason. Browsers can load content from multiple sites in parallel, and not wait for ad content, unless Javascript is used to prevent that.
All too often, Javascript is used in just that way. (As on, well, Slashdot. Earth to Slashdot: your Javascript is embarrassingly slow. Get someone with a clue.)
One of the more painful things I have to do for AdRater is to recognize dynamically loaded ad content. Google ads are loaded using at least five completely different code styles. So I actually have to look at other people's ad-serving code in some detail. It's not fun.
Fortunately, one generic mechanism handles most of the cases; I don't have to track their code changes in detail.
Most of this doesn't seem to be intended to get around ad-blocking software, and isn't successful at that. It's usually either tracking-related, concerned with displaying the ad in a different CSS context than that of the surrounding content, or just the result of ineptly cutting and pasting JavaScript from multiple sources.
You had backspace? I had to disconnect the carriage and slide it to the left.
Ah, yes, life before backspace erasure. Keypunches. Flexowriters. Baudot teletypes.
I have this Teletype Model 15 keyboard. (That exact keyboard; the picture in Wikipedia is of my machine. Yes, I need to machine a new space bar.) Each key has a travel of about half an inch, and produces not just an audible "click", but a "whir-chunk" as the keyboard encoder, which is a mechanical device with cams, does a parallel to serial conversion. There's a speed limit; once you've pressed a key, you can't press another one until the encoder is finished. There is no key rollover, but you can't push two keys at once because the encoding mechanism prevents it. There are 32 keys, since this is a five bit code and they're all used. There are two shifts, FIGS and LTRS. The keyboard just sends those; it itself has no notion of shifting.
There's one unused key, the "blank key", which sends the all ones character. My software for the machine uses that as backspace, typing a "/" followed by the letter just deleted. The machine itself has no backspace capability. So you can't backspace too much, or you hit the right margin, for which I delete the whole line.
This is 1930s technology. There were printing telegraphs and stock tickers back to 1870, so electrical keyboards do go back to the 19th century. Edison had a machine with a semicircular keyboard (not for ergonomics; the keys radiated out from the center of a round machine). Linotypes (which, amazingly, appeared in 1886) had entirely electrical keyboards, with separate keys for upper and lower case letters.
Teletypes loosely followed the Underwood typewriter layout because the Model 12 Teletype (the first one that worked well enough to deploy, from 1921) was a heavily modified Underwood typewriter. Computer keyboards since then have a direct line of descent from the original Morkrum Model 12, through decades of Baudot machines, and into the ASCII era.
Here's a typical bit of Open Source design suckage.
I just installed the latest version of Blender, over an existing installation. The installer can't find the exact version of Python it wants (which, incidentally, is not a currently supported version.) The program itself can, it's just the installer that's broken. Typical.
Now I want to draw a spiral spring. Naturally, that's not built-in; I'll need a third-party plug-in.
So I find the Blender Plug-In Repository using Google. That says "The main page for Blender python scripts is now:
here. That gets "If you are not redirected within 5 seconds, click here", which then redirects to a dead link.
OK, let's try Blender's main site and search for "plugins". That leads to documentation on how to code a plugin.Another search result returns "Plugin functionalities varies so much that it is not possible to describe them here. Differently than Texture Plugins Sequence Plugins do not have a Buttons in any Button Window, but their parameters are usually accessed via NKEY." Really.
OK, let's just try "blender spiral" in Google. This gets a script for drawing spirals.
That's nice. But it's a ".rar" file. That's not something Blender-specific. It's a proprietary Russian archiving format. The RAR site promotes something called "RegistryBooster", which is a strong indication of involvement with hostile code. So I probably don't want to buy the WinRAR product so I can decompress something which is a few lines of Python. This
The point of this is that the Government outlets and the PR outlets have no objection to being linked, copied, and redistributed. If the free press, such as it is, disappears from Google News, it will be all hype.
It's worth noting the rise of Government-sponsored news sources. Until a few years ago, few in the US paid any attention to what the Voice of America put out. Now, it's a widely aggregated news source, because it's free. Google News aggregates the BBC, Xinhua, and Al-Jazeera, all of which are Government-controlled. (The BBC and Al-Jazeera have some independence, but it's limited. Xinhua is the official output of the Chinese government.)
From the private sector, there's an endless supply of self-serving material, some of which gets picked up as "news". Google News sometimes thinks PR Newswire is a valid news source.
The independent sources remaining tend to be aimed at people with serious money. The Wall Street Journal, The Economist, and Bloomberg are still quite good, and are profitable. Mass market print journalism, though, is dying. The proud boasts in newspaper banners ring hollow today. The San Francisco Examiner still says "Monarch of the Dailies" at the top of page one, but that was a long, long time ago. San Francisco's mayor recently remarked that if the SF Chronicle stopped publishing its print edition, no one under 35 would notice.
Newspaper vending machines seem to be mostly empty now; it's not even worth filling them. Locally, I've seen some stickered with abandoned-car like notices from the city, which tell the newspaper "fill it with papers or we tow it away".
I met the inventor of NextBus some years ago at the Hacker's Conference. What they get from the bus is position, speed, and a few bits of data like the destination sign setting, "doors open" and "wheelchair lift deployed".
After much crunching on this data, info like "Next bus at this stop: 6 minutes" comes out. Over time, as more data comes in, the predictions get better. It's a good machine learning problem, because you have actuals; you can tell when the bus eventually gets to the stop, so you have hard data from which to validate the prediction algorithm. You don't even need a map.
The early business plan for NextBus had a little dedicated receiver they were going to sell to consumers. The idea was that you have one at home, and it tells you the number of minutes until the next bus gets to the stop near your house, so you know when to leave the house. That was before the World Wide Web, so that wasn't necessary.
Originally, Muni management hated the system, because it was too honest about their bad service. But after much political effort, eventually it was deployed on a few lines, where it was very popular. Then it was put in everywhere.
Muni probably owns the raw data, and NextBus probably owns the predictions. I'm not sure on that, though.
The big retailers won't stand for the slowdown at checkout this would cause. Various schemes like this have been proposed before, and Wal-Mart isn't interested.
If everybody who wants activation at checkout, from cell phones to gift cards to videos, gets together and standardizes on a system, maybe.
A dozen years ago I developed and demoed the first ragdoll physics system that worked. Among other things, I'm responsible for the "ragdoll falling downstairs" cliche; that started with a demo I did in 1997. I looked at ragdolls as a first step. I was expecting game development to go in the direction of physically-based characters driven by active control of character muscles. That hasn't happened.
The problem is partly technical and partly dramatic. The dramatic part I encountered in dealing with Hollywood types. What directors want is to specify the start and end conditions; the job of the system is to realistically get the character to the desired ending mark. In real-world stunt work, there are wires, guides, and rails that make things go the way the director wants, even when that's not physically realistic. When that's not enough, cuts are used to conceal the lack of realism.
Physics systems are inherently unidirectional - you keep working forward from the current state. This is fundamentally incompatible with directorial control. As a result, the
trend in character animation has been to get enough motion capture data to cover the things you want the character to do, and use a motion splicing engine to patch the pieces together. (This, incidentally, was first used in Godzilla, the movie, for the baby 'zillas). That's become more or less the standard approach for games.
Using a character control AI to drive the character's muscles realistically has been attempted, but with modest success. Motion Factory tried this in the 1990s; their system was only kinematic, and not too successful. Havok is trying it now. For this to work, you need computerized muscle control good enough to drive a real-world robot, like Big Dog. And then it has to look good from an aesthetic perspective. It's really a hard robotics problem, which is why I was interested in it in the first place.
From a gameplay perspective, if you take the physics seriously, you lose the "superhero" capabilities of game characters. Jump off a balcony, and don't expect to land on your feet.
Jumping up to a balcony? Forget it. Hand-to-hand combat works about as well as it does at the dojo. ("Your left foot was too far forward for that throw. Again!" "Yes, sensi.") Trying to control a physically realistic character via a joystick is nearly hopeless. You can't even drive a real car very well through a remote joystick, let alone a game pad. (I've actually done that; using a remote steering wheel is a huge improvement over a joystick.) In driving games for consoles, the physics is tweaked to make the car incredibly stable. (Lowering the center of gravity to below ground is a common trick.)
So what do we have? Ragdolls. "Infinitely destructible environments." Some skin deformation. Cloth. Plus rain, snow, water, and explosions that don't feed into the game play at all. (That's mostly what the "physics cards" do.)
When Google StreetView can get the street numbers right, this might actually work.
For now, it's just going to be another ad delivery system.
The cool app for this would be one that, when you enter a restaurant or store, sounds an alarm if the business has a problem, like a poor Yelp rating, a poor BBB rating, a poor health department rating, etc.
The problem is getting it out without dumping metal particles all over the place.
But they'll think of something, probably something that involves a cutting tool and a
suction system.
This is way too much like that dumb Bond movie. First, they get their own NASA airfield for their own private jet. Then they base a Zeppelin there, cruising over the Golden Gate Bridge, no less. Now, a geothermal drilling project? They're definitely on script.
After struggling through the site, it looks like a big mess that solves no useful problem. I can't find any screenshots, either. Here's the slide show from a conference. But it has exactly one graphic, and that's part of a discussion of how you can use arbitrary functions, like "sine", on the alpha channel. (Using "sine" on the alpha channel is basically the <BLINK> tag revisited.)
Worse, this is a toolkit for C applications. It's not for web use. It's not 3D enough for game development, and it's too much for business applications. Layout has to be done at the programmer level; there aren't GUI tools for layout. (Some games use Flash for 2D GUI elements, not because they run the Adobe/Macromedia Flash run-time engine, but because the tools for developing Flash are available and usable by artists.)
There's nothing inherently wrong with running a 2D GUI through OpenGL; we were doing that in 1997. Softimage|3D worked that way. But it's kind of dated.
More and more, sites are generating the message "A script on this page is running too slowly" from Firefox. Not because the site is hung; just because it's insanely slow. Slashdot is one of the worst offenders. The problem seems to be in ad code; Slashdot has some convoluted Javascript for loading Google text ads. Anyway, hitting "cancel" when Slashdot generates that message doesn't hurt anything that matters.
Facebook is even worse. Facebook's "send message" message composition box is so slow that CPU usage goes to 100% when typing in a message. Open a CPU monitor window and try it. I've been trying to figure out what's going on, but the Javascript loads more Javascript which loads more Javascript, and I don't want to spend the debugger time to figure it out.
Pre-1950 systems with configurable defaults.
on
On the Humble Default
·
· Score: 4, Informative
I'm trying to think of something prior to 1950 that had an overridable, configurable default. It's hard. Business telephone systems had some configurable defaults, but setting them up required physical wiring. The same was true of Plan 55-A Teletype message switching.
IBM plugboard-wired tabulators didn't really have defaults as we think of them today. Machine tools had adjustable speeds and feeds, but no real defaults. Jacquard looms didn't have defaults. Linotypes didn't have defaults. Chain-programmed embroidery machines - no.
The closest thing I can think of was General Railway Signal's NX signaling system for controlling railroad interlockings. This 1930s system may have been the first "user-friendly interface". An NX system controlled multiple switches and signals in an area (an "interlocking") preventing conflicts. Interlocked signal controls had been around for years, and they handled the safety issue, but before NX, it was the user's responsibility to figure out the desired path from A to B. With an NX system, you selected an "entry" point where a train was going to enter the interlocking, and all the reachable "exit" points would light up. The "reachable" logic took into account other trains that were in the interlocking area. When the operator selected an "exit", the NX system would pick a path between the entry and exit, routing around other trains or even track locked out of service.
A default "best" routing was hard-wired into the system, but the operator could override the default routing manually, by picking some intermediate point along the path as the "exit", then selecting that as an "entry" and picking the final "exit".
That's the oldest system I know of with a real "default" mechanism.
The US is currently sending out satellite TV news in Persian 24 hours a day. It's on Telstar 12; the eastern edge of coverage is near the Iran-Pakistan border, and the whole EU is covered. Someone please take a look and see what they're sending. The IBB doesn't seem to have the transponder number, symbol rate, or frequency on their site, which is lame.
The non-static pages on the site, which was outsourced to "mixedink.com", just produce an endless busy icon, with the word "thinking". OK, bad vendor choice.
The story of Adam's Block is instructive. Someone set up two good high-resolution cameras looking out at a high-crime area in San Francisco's Tenderloin, and put them on the Web. Viewers could comment in real time, and log interesting events for later interest.
There are at least four schemes for short-range wireless power transmission around. This needs to be standardized so it can be deployed.
The very short range ones, which couple a tabletop pad to a device on it, would be most useful. All the little stuff that needs recharging should be on the same system, with recharging pads in bedroom, office, hotel room, car, airline tray table, Starbucks, etc. Unless the players get together and agree on a standard, this is going nowhere.
Up-converting DVD players with HDMI output ($50 to $99 and dropping) fed digitally into a 1080p display (the default today) are a huge improvement over DVD to analog NTSC. The resolution improves, the full color gamut is supported, and the "widescreen" format adjustment takes place automatically, without any button pushing or display in the wrong aspect ratio. That was the big jump in quality.
The next step up, input from a true HD source, produces a much smaller improvement than the conversion to digital. There's a big improvement in audio quality, but unless you have unusually good speakers, all five channels, and a quiet listening environment, you won't notice. The video improvement isn't noticeable from across the room, unless you still-frame and zoom, or you have some screen bigger than 50 inches.
That's why Blu-Ray adoption is slow. Just be patient; once player cost drops below $99, all new players will be Blu-Ray.
I don't see downloaded video being the future. Downloaded content with DRM is good for only a few years before the distributor goes bust or the authorization system is discontinued. That's happened with WalMart music, Microsoft PlaysForSure, Circuit City's DIVX, and Major League Baseball. In fact, the mean life of DRM content seems to be less than five years. Physical media have a long life ahead of them.
Slashdot Mirror
Gah, why is BELL on the S key and not G where it belongs?
In Baudot code, BELL can be on either the S key or the J key; BELL on the G key is an ASCII thing. CCITT Alphabet No. 2 puts BELL on the J key, but this particular Teletype was built in 1944 and predates the CCITT standard. It also has the "£" symbol rather than "#". This was the American military standard during WWII.
Model 15 teletypes have a serious bell; it's almost 3 inches across, and gives a solid "gong" sound.
The trouble with charging through a USB connector is that it's also a USB port. Most phones aren't well-protected against attacks via the USB port. With a common charger interface, you're going to find charger outlets everywhere. Some of them will be hostile.
So now you need a cable that only passes power. But that may not be enough. Motorola RAZR phones, for example, won't charge on PCs unless the Motorola driver is present to do the handshake. By default,a USB port will deliver at least 100mA, but if asked, it may deliver up to 500mA. Laptops actively manage USB power; desktop systems often don't bother.
So you may need a data connection, which opens up a whole new range of attacks on phones. Which means you may sometimes need a "firewall", a device which does the USB handshake and requests 500mA, then delivers it over a cable with no data wires.
This has been possible for a while, but with standardization, we'll have outlet strips with USB ports all over the place, in cafes, on aircraft, in cars, etc.
only to find their page delivery delayed by slow-loading ads.
Well, duh. I've been complaining about this for the past year. Too much ad code is using "document.write()", often for no really good reason. Browsers can load content from multiple sites in parallel, and not wait for ad content, unless Javascript is used to prevent that. All too often, Javascript is used in just that way. (As on, well, Slashdot. Earth to Slashdot: your Javascript is embarrassingly slow. Get someone with a clue.)
One of the more painful things I have to do for AdRater is to recognize dynamically loaded ad content. Google ads are loaded using at least five completely different code styles. So I actually have to look at other people's ad-serving code in some detail. It's not fun. Fortunately, one generic mechanism handles most of the cases; I don't have to track their code changes in detail.
Most of this doesn't seem to be intended to get around ad-blocking software, and isn't successful at that. It's usually either tracking-related, concerned with displaying the ad in a different CSS context than that of the surrounding content, or just the result of ineptly cutting and pasting JavaScript from multiple sources.
You had backspace? I had to disconnect the carriage and slide it to the left.
Ah, yes, life before backspace erasure. Keypunches. Flexowriters. Baudot teletypes.
I have this Teletype Model 15 keyboard. (That exact keyboard; the picture in Wikipedia is of my machine. Yes, I need to machine a new space bar.) Each key has a travel of about half an inch, and produces not just an audible "click", but a "whir-chunk" as the keyboard encoder, which is a mechanical device with cams, does a parallel to serial conversion. There's a speed limit; once you've pressed a key, you can't press another one until the encoder is finished. There is no key rollover, but you can't push two keys at once because the encoding mechanism prevents it. There are 32 keys, since this is a five bit code and they're all used. There are two shifts, FIGS and LTRS. The keyboard just sends those; it itself has no notion of shifting.
There's one unused key, the "blank key", which sends the all ones character. My software for the machine uses that as backspace, typing a "/" followed by the letter just deleted. The machine itself has no backspace capability. So you can't backspace too much, or you hit the right margin, for which I delete the whole line.
This is 1930s technology. There were printing telegraphs and stock tickers back to 1870, so electrical keyboards do go back to the 19th century. Edison had a machine with a semicircular keyboard (not for ergonomics; the keys radiated out from the center of a round machine). Linotypes (which, amazingly, appeared in 1886) had entirely electrical keyboards, with separate keys for upper and lower case letters.
Teletypes loosely followed the Underwood typewriter layout because the Model 12 Teletype (the first one that worked well enough to deploy, from 1921) was a heavily modified Underwood typewriter. Computer keyboards since then have a direct line of descent from the original Morkrum Model 12, through decades of Baudot machines, and into the ASCII era.
I thought of him as just another has-been celebrity fuckup.
Here's a typical bit of Open Source design suckage.
I just installed the latest version of Blender, over an existing installation. The installer can't find the exact version of Python it wants (which, incidentally, is not a currently supported version.) The program itself can, it's just the installer that's broken. Typical.
Now I want to draw a spiral spring. Naturally, that's not built-in; I'll need a third-party plug-in. So I find the Blender Plug-In Repository using Google. That says "The main page for Blender python scripts is now: here. That gets "If you are not redirected within 5 seconds, click here", which then redirects to a dead link.
OK, let's try Blender's main site and search for "plugins". That leads to documentation on how to code a plugin. Another search result returns "Plugin functionalities varies so much that it is not possible to describe them here. Differently than Texture Plugins Sequence Plugins do not have a Buttons in any Button Window, but their parameters are usually accessed via NKEY." Really.
OK, let's just try "blender spiral" in Google. This gets a script for drawing spirals. That's nice. But it's a ".rar" file. That's not something Blender-specific. It's a proprietary Russian archiving format. The RAR site promotes something called "RegistryBooster", which is a strong indication of involvement with hostile code. So I probably don't want to buy the WinRAR product so I can decompress something which is a few lines of Python. This
Typical.
But the imagery isn't the real focus of the activity.
Yes, it is. The primary function of Apollo was to produce good television.
The point of this is that the Government outlets and the PR outlets have no objection to being linked, copied, and redistributed. If the free press, such as it is, disappears from Google News, it will be all hype.
It's worth noting the rise of Government-sponsored news sources. Until a few years ago, few in the US paid any attention to what the Voice of America put out. Now, it's a widely aggregated news source, because it's free. Google News aggregates the BBC, Xinhua, and Al-Jazeera, all of which are Government-controlled. (The BBC and Al-Jazeera have some independence, but it's limited. Xinhua is the official output of the Chinese government.)
From the private sector, there's an endless supply of self-serving material, some of which gets picked up as "news". Google News sometimes thinks PR Newswire is a valid news source.
The independent sources remaining tend to be aimed at people with serious money. The Wall Street Journal, The Economist, and Bloomberg are still quite good, and are profitable. Mass market print journalism, though, is dying. The proud boasts in newspaper banners ring hollow today. The San Francisco Examiner still says "Monarch of the Dailies" at the top of page one, but that was a long, long time ago. San Francisco's mayor recently remarked that if the SF Chronicle stopped publishing its print edition, no one under 35 would notice.
Newspaper vending machines seem to be mostly empty now; it's not even worth filling them. Locally, I've seen some stickered with abandoned-car like notices from the city, which tell the newspaper "fill it with papers or we tow it away".
I met the inventor of NextBus some years ago at the Hacker's Conference. What they get from the bus is position, speed, and a few bits of data like the destination sign setting, "doors open" and "wheelchair lift deployed". After much crunching on this data, info like "Next bus at this stop: 6 minutes" comes out. Over time, as more data comes in, the predictions get better. It's a good machine learning problem, because you have actuals; you can tell when the bus eventually gets to the stop, so you have hard data from which to validate the prediction algorithm. You don't even need a map.
The early business plan for NextBus had a little dedicated receiver they were going to sell to consumers. The idea was that you have one at home, and it tells you the number of minutes until the next bus gets to the stop near your house, so you know when to leave the house. That was before the World Wide Web, so that wasn't necessary.
Originally, Muni management hated the system, because it was too honest about their bad service. But after much political effort, eventually it was deployed on a few lines, where it was very popular. Then it was put in everywhere.
Muni probably owns the raw data, and NextBus probably owns the predictions. I'm not sure on that, though.
The big retailers won't stand for the slowdown at checkout this would cause. Various schemes like this have been proposed before, and Wal-Mart isn't interested.
If everybody who wants activation at checkout, from cell phones to gift cards to videos, gets together and standardizes on a system, maybe.
A dozen years ago I developed and demoed the first ragdoll physics system that worked. Among other things, I'm responsible for the "ragdoll falling downstairs" cliche; that started with a demo I did in 1997. I looked at ragdolls as a first step. I was expecting game development to go in the direction of physically-based characters driven by active control of character muscles. That hasn't happened.
The problem is partly technical and partly dramatic. The dramatic part I encountered in dealing with Hollywood types. What directors want is to specify the start and end conditions; the job of the system is to realistically get the character to the desired ending mark. In real-world stunt work, there are wires, guides, and rails that make things go the way the director wants, even when that's not physically realistic. When that's not enough, cuts are used to conceal the lack of realism.
Physics systems are inherently unidirectional - you keep working forward from the current state. This is fundamentally incompatible with directorial control. As a result, the trend in character animation has been to get enough motion capture data to cover the things you want the character to do, and use a motion splicing engine to patch the pieces together. (This, incidentally, was first used in Godzilla, the movie, for the baby 'zillas). That's become more or less the standard approach for games.
Using a character control AI to drive the character's muscles realistically has been attempted, but with modest success. Motion Factory tried this in the 1990s; their system was only kinematic, and not too successful. Havok is trying it now. For this to work, you need computerized muscle control good enough to drive a real-world robot, like Big Dog. And then it has to look good from an aesthetic perspective. It's really a hard robotics problem, which is why I was interested in it in the first place.
From a gameplay perspective, if you take the physics seriously, you lose the "superhero" capabilities of game characters. Jump off a balcony, and don't expect to land on your feet. Jumping up to a balcony? Forget it. Hand-to-hand combat works about as well as it does at the dojo. ("Your left foot was too far forward for that throw. Again!" "Yes, sensi.") Trying to control a physically realistic character via a joystick is nearly hopeless. You can't even drive a real car very well through a remote joystick, let alone a game pad. (I've actually done that; using a remote steering wheel is a huge improvement over a joystick.) In driving games for consoles, the physics is tweaked to make the car incredibly stable. (Lowering the center of gravity to below ground is a common trick.)
So what do we have? Ragdolls. "Infinitely destructible environments." Some skin deformation. Cloth. Plus rain, snow, water, and explosions that don't feed into the game play at all. (That's mostly what the "physics cards" do.)
When Google StreetView can get the street numbers right, this might actually work.
For now, it's just going to be another ad delivery system.
The cool app for this would be one that, when you enter a restaurant or store, sounds an alarm if the business has a problem, like a poor Yelp rating, a poor BBB rating, a poor health department rating, etc.
The problem is getting it out without dumping metal particles all over the place. But they'll think of something, probably something that involves a cutting tool and a suction system.
This is way too much like that dumb Bond movie. First, they get their own NASA airfield for their own private jet. Then they base a Zeppelin there, cruising over the Golden Gate Bridge, no less. Now, a geothermal drilling project? They're definitely on script.
Who plays Grace Jones?
For business apps, clutter probably won't really be used directly by developers at all. Instead it will be used by the widget toolkits.
OK, so we have a widget toolkit on top of a Clutter scene graph on top of OpenGL. Is there a reason for the extra layers?
After struggling through the site, it looks like a big mess that solves no useful problem. I can't find any screenshots, either. Here's the slide show from a conference. But it has exactly one graphic, and that's part of a discussion of how you can use arbitrary functions, like "sine", on the alpha channel. (Using "sine" on the alpha channel is basically the <BLINK> tag revisited.)
Worse, this is a toolkit for C applications. It's not for web use. It's not 3D enough for game development, and it's too much for business applications. Layout has to be done at the programmer level; there aren't GUI tools for layout. (Some games use Flash for 2D GUI elements, not because they run the Adobe/Macromedia Flash run-time engine, but because the tools for developing Flash are available and usable by artists.)
There's nothing inherently wrong with running a 2D GUI through OpenGL; we were doing that in 1997. Softimage|3D worked that way. But it's kind of dated.
The publisher should have used TurnItIn.
More and more, sites are generating the message "A script on this page is running too slowly" from Firefox. Not because the site is hung; just because it's insanely slow. Slashdot is one of the worst offenders. The problem seems to be in ad code; Slashdot has some convoluted Javascript for loading Google text ads. Anyway, hitting "cancel" when Slashdot generates that message doesn't hurt anything that matters.
Facebook is even worse. Facebook's "send message" message composition box is so slow that CPU usage goes to 100% when typing in a message. Open a CPU monitor window and try it. I've been trying to figure out what's going on, but the Javascript loads more Javascript which loads more Javascript, and I don't want to spend the debugger time to figure it out.
I'm trying to think of something prior to 1950 that had an overridable, configurable default. It's hard. Business telephone systems had some configurable defaults, but setting them up required physical wiring. The same was true of Plan 55-A Teletype message switching. IBM plugboard-wired tabulators didn't really have defaults as we think of them today. Machine tools had adjustable speeds and feeds, but no real defaults. Jacquard looms didn't have defaults. Linotypes didn't have defaults. Chain-programmed embroidery machines - no.
The closest thing I can think of was General Railway Signal's NX signaling system for controlling railroad interlockings. This 1930s system may have been the first "user-friendly interface". An NX system controlled multiple switches and signals in an area (an "interlocking") preventing conflicts. Interlocked signal controls had been around for years, and they handled the safety issue, but before NX, it was the user's responsibility to figure out the desired path from A to B. With an NX system, you selected an "entry" point where a train was going to enter the interlocking, and all the reachable "exit" points would light up. The "reachable" logic took into account other trains that were in the interlocking area. When the operator selected an "exit", the NX system would pick a path between the entry and exit, routing around other trains or even track locked out of service.
A default "best" routing was hard-wired into the system, but the operator could override the default routing manually, by picking some intermediate point along the path as the "exit", then selecting that as an "entry" and picking the final "exit".
That's the oldest system I know of with a real "default" mechanism.
The US is currently sending out satellite TV news in Persian 24 hours a day. It's on Telstar 12; the eastern edge of coverage is near the Iran-Pakistan border, and the whole EU is covered. Someone please take a look and see what they're sending. The IBB doesn't seem to have the transponder number, symbol rate, or frequency on their site, which is lame.
The non-static pages on the site, which was outsourced to "mixedink.com", just produce an endless busy icon, with the word "thinking". OK, bad vendor choice.
The story of Adam's Block is instructive. Someone set up two good high-resolution cameras looking out at a high-crime area in San Francisco's Tenderloin, and put them on the Web. Viewers could comment in real time, and log interesting events for later interest.
The drug dealers were angry. There were death threats. The camera owner finally had to take the cameras down and move.
There are at least four schemes for short-range wireless power transmission around. This needs to be standardized so it can be deployed.
The very short range ones, which couple a tabletop pad to a device on it, would be most useful. All the little stuff that needs recharging should be on the same system, with recharging pads in bedroom, office, hotel room, car, airline tray table, Starbucks, etc. Unless the players get together and agree on a standard, this is going nowhere.
Up-converting DVD players with HDMI output ($50 to $99 and dropping) fed digitally into a 1080p display (the default today) are a huge improvement over DVD to analog NTSC. The resolution improves, the full color gamut is supported, and the "widescreen" format adjustment takes place automatically, without any button pushing or display in the wrong aspect ratio. That was the big jump in quality.
The next step up, input from a true HD source, produces a much smaller improvement than the conversion to digital. There's a big improvement in audio quality, but unless you have unusually good speakers, all five channels, and a quiet listening environment, you won't notice. The video improvement isn't noticeable from across the room, unless you still-frame and zoom, or you have some screen bigger than 50 inches.
That's why Blu-Ray adoption is slow. Just be patient; once player cost drops below $99, all new players will be Blu-Ray.
I don't see downloaded video being the future. Downloaded content with DRM is good for only a few years before the distributor goes bust or the authorization system is discontinued. That's happened with WalMart music, Microsoft PlaysForSure, Circuit City's DIVX, and Major League Baseball. In fact, the mean life of DRM content seems to be less than five years. Physical media have a long life ahead of them.