QNX, the real-time operating system, does not page to disk. (Not for most processes, anyway. Read on.) The GUI has a bar in the lower right hand corner which shows how much memory is in use; if memory fills up, processes have requests for more memory rejected.
The big advantage of this is consistent performance. Hard real time works. There are no pauses waiting for the disk. This is what you want for entertainment applications, like video players, audio players, and games.
It's possible to set up paging for specific programs, though. GCC has paging, so that huge programs can be compiled, somewhat slowly, on smaller systems. By default, though, paging is not used. Provided that applications aren't bloatware, this works quite well.
It's something to think about for Linux. Should programs be paged by default? Maybe that era is over.
This is an iffy idea for data that actually matters. The "torrent" type systems sort of work because they're willing to accept very poor data integrity in exchange for free music and video. Even that's going downhill, as more content shows up with logos, ads, and other various dreck tacked on.
When it doesn't work, or something gets lost, who do you blame?
Security is supposed to be through "signing".
Who's signing what? Does everybody sign their own check-in, do servers sign collections of files, or what? How do you prevent the insertion of hostile code?
The problem with "web of trust" systems is that it's too easy to create phony identities on line, who then pretend to trust each other. Like link farms for search engine spamming.
About ten years ago, Stanford used to have a small fenced yard on Stock Farm Road which contained some large stainless steel items, mostly large-diameter plumbing left over from physics experiments. A small radioactive trefoil was posted on the fence, and it had its own street light, but other than that, it wasn't protected.
I bicycled by this every day on my way to the Stanford barn (I kept a horse on campus at the time). One day I noticed that the fence had been cut and much of the metal was missing. So I stopped by Stanford's toxic waste incinerator ("environmental safety facility") nearby to report this, and was sent to the radiation safety officer.
He immediately made some calls.
Stanford had to have people check all the scrapyards for miles around, but nothing seriously radioactive turned up. The steel had been there for years, and was down to about twice background, so it wasn't a serious hazard. It was from experiments at the old linear accelerator (not SLAC, the little one at Hansen Labs), and had picked up some induced radioactivity. You can't really make stainless all that radioactive.
Stanford shipped out the remaining metal to some remote disposal site for burial.
Ever notice how the Enterprise in Enterprise looked way more advanced that the Enterprise in Star Trek.
It got to be embarrassing. The original Star Trek bridge now looks like an outdated comm center for mall security.
The original Battlestar Galactica bridge from the 1970s was powered by Tektronix, and many of the controls actually did something visible. This was a real problem for the actors, who had to learn how to operate the systems.
"2001" was more futuristic. An AI took care of the details, and the crew just chatted with the AI.
SCO still has to get out of bankruptcy. Unless they find an outside investor, that's hopeless. In this market, they're unlikely to find an outside investor. They'll have trouble getting financing in any form. I expect Chapter 7 liquidation by spring.
Anybody who buys SCO for the litigation rights gets stuck with the potential liability in the IBM lawsuit. That's a big liability, IBM has good lawyers, and IBM was winning when the bankruptcy put that suit on hold. IBM made $11 billion in profits last year on revenue of $105 billion, so they can continue to afford Cravath lawyers.
Most of the issues mentioned don't affect servers much, which is why Linux does well on servers but remains a pain on the desktop.
Yes, there are too many kernel-level APIs. I'd prefer a microkernel. As something of a QNX fan, it's been amusing to see, over time, Linux add most of the features of QNX, such as the ability to run drivers and file systems in user space. Unfortunately, the Linux kernel people don't take out the old stuff. Hence the kernel bloat. Probably unfixable.
Linux still has mediocre interprocess communication, by the way.
X11 sucked in the 1990s, and it still sucks, but less than it used to.
Configuration via text files really is obsolete. But the Windows registry, which is just a tree of tuples, isn't the right answer either. The right answer is SQL databases. With a database, the data is always in the correct format; if you screw up the syntax, it's caught at insertion time. There's locking; you don't need kludges like "vipw". Changes on the fly are handled properly. The database can enforce consistency rules, always a headache with text files. Databases can be accessed with command line tools, GUI tools, automated tools, or even PHP scripts. Tiny implementations of SQL databases are available; they usually update slowly, but update traffic is rarely a bottleneck for configuration. In the early days of Linux, nobody knew what to do about databases, but now that almost every web site has one, everybody is familiar with how to drive an SQL-based system.
Why, at this late date, is anyone still using Sendmail? There are far better alternatives, including QMail and Postfix.
What this guy seems to be complaining about is that Wikipedia doesn't have enough coverage of the parts of computer science he's interested in. His field seems to be probabilistic algorithms. This is a relatively new field. The general idea is that there are problems for which an algorithm with some randomness is much faster than a deterministic algorithm, at least for the worst case. Classic examples are the simplex method in linear algebra and the traveling salesman problem.
In the last twenty years, there's been a fair amount of work on generalizing this concept to a wider class of problems and putting a theoretical basis under it. Wikipedia has some articles on this. See BPP. I'm not up on this stuff (my CS degree is too old), but at least there's some coverage.
Because this is an area where there aren't many useful results yet, it's hard to write encyclopedia articles. It may be too early to tell what's useful and what's a dead end.
I'd be surprised if, say, Encarta even mentions this subject.
"Space travel is utter bilge" - Richard van der Riet Wolley, Astronomer Royal, 1955.
He was right. Back in 1955, he crunched the numbers, and realized that you couldn't build a rocket that lifted itself into orbit while carrying much of a payload.
Only by excessive weight reduction and throwing away big chunks of the launch vehicle does space travel work at all.
Space travel on chemical fuels will never work much better than it does now. It's an inherent limitation of chemical fuels. After fifty years of trying, it's still only possible to just barely get stuff into orbit, using huge rockets to lift dinky payloads.
The vehicles are so weight-reduced that they're too fragile to reuse without a major overhaul after each flight. We'll never get to something with the robustness of a commercial airliner, or even a jet fighter.
We should resign ourselves to launching small satellites and planetary probes. Manned spaceflight is just an expensive ego trip for nations. The ISS turned out to be pointless; people go there, but nothing much gets done there. It's not useful for astronomy, earth observation, scientific research, manufacturing, or even for military purposes.
If we ever get a better power source, like fusion or a nuclear rocket that doesn't make a big mess, this could change. But on chemical fuels, space travel is a dud. It's time to admit that and give it up.
"Foundation" would be a joke today. "We can predict the future. With math. In detail. By hand!" People are less impressed with mathematical prediction now; enough of it has been done to make it clear what's possible and what isn't.
Wall Street has had sizable efforts in that direction. You can at best do a little bit better than noise, some of the time. Which was enough to create hedge fund billionaires.
The "Hydrogen Economy" was partly the result of a stupid book by Jeremy Rifkin. Read it and note how little it says about where the hydrogen comes from.
It was promoted by the Bush/Cheney crowd as a means for diverting attention from electric cars.
Using electricity to break water into hydrogen and oxygen, then liquefying the hydrogen, storing it as a liquid, then recombining it in a car (either in an engine or a fuel cell) is incredibly inefficient. The only advantage over batteries is that it looked like it might provide more range. Battery energy density has improved in the last decade, though.
Battery cost is still a problem. But none of the hydrogen cars are cheap. Nor do they really have that much range. Arnold's hydrogen-powered Hummer only has a 60-mile range.
BMW actually built about 100 "hydrogen powered" cars. But they mostly run on gasoline; although they can optionally run on hydrogen, that's mostly for PR purposes. The liquid hydrogen tank has a "use it or lose it feature"; the BMW vehicle will evaporate all its hydrogen in about 10-12 days.
Cross-compiling Java into Javascript seems undesirable. You'll get bloated Javascript as Java constructs are decomposed into Javascript primitives. Then you get to debug the emitted code, which is not going to be fun. Writing Javascript is a pain, but there are libraries. Look for libraries that aren't too big, can't be changed remotely by some vendor, and don't try to be "frameworks".
Most browsers can run Java applets, after all. If you really want to use Java on the client, you can use Java on the client. It will execute faster than Java compiled into Javascript. You can even hide that stupid Sun ad that appears as the JVM loads.
The big jump in quality comes when the channel is end-to-end digital. That's a huge
improvement over NTSC. But 1080p from a DVD player with upscaling and HDMI output
is hard to distinguish from "broadcast-quality" HDTV.
Pixar's pixel-clean digital animation on Blu-Ray looks great, because all the detail really is there, the compression isn't too harsh, and Pixar makes their Blu-Ray disks from the digital data, not a photographic film intermediate. If there's photographic film in the middle, the image is degraded, and a sizable chunk of the bandwidth goes into trying to represent film grain.
There's still too much compression,. Look at football in HDTV. While the camera pans, there's blurring, and shortly after, but not immediately after, the camera stops moving, the blades of grass suddenly get sharp edges as the data stream catches up. ESPN insists on a minimum bandwidth allocation from cable companies to try to keep the compression artifacts down to a tolerable level, but it's still marginal.
It's almost better to have lower resolution rather than annoying compression artifacts.
Most major sites with slow-loading pages suffer from "Web 2.0 overload". Page loads usually hang not because the requested URL isn't being served fast enough, but because some additional file is needed and isn't being served fast enough. When Slashdot pages are loading slowly, for example, you'll usually see "Waiting for pagead2.googlesyndication.com", "Waiting for ad.greenmarquee.net", "Waiting for ad.doubleclick.net", "Waiting for ad.yieldmanager.com", or "Waiting for m1.2mdn.net". That's where the load delays come from. Cacheing doesn't help, because those services want to serve a different ad every time.
Then there's CSS. The business about CSS speeding up page loading was crap. We're seeing pages that load ten or fifteen CSS files, often from sites that don't load all that fast. Handheld devices don't have the cache capacity of desktops, so the odds that something big, like Google Widgets, will have to be reloaded is reasonably high.
Then there's "onload", where, after the base page is loaded, an XMHHttpRequest is made to get more info. Now you have serial delays; the browser can't parallelize the loads. A good example is RushmoreDrive, the "black search engine" Ask is trying as a niche product. Slowest loading home search page in the industry. Look at the HTML and you'll see why.
If Apple wants faster load times, they should put ad blocking in the iPhone's browser. That would cut page load times way down on ad-heavy sites.
Way too many years ago, in 1971, I did something like this for a UNIVAC 1108 mainframe. We had a big CRT hanging from the ceiling of a glass-walled computer room, showing some basic information like current job status, memory utilization bar chart, backlog, and console messages. Every four seconds, the display changed to a new screen.
People would actually come up to the glass wall to watch. For the first time, there was some indication of what the mainframe was doing. The mainframe's console was a teletype, and
the operator could make some status inquiries, but at 110 baud, you couldn't get mucn insight into
what was going on. (That operating system viewed the operator as a peripheral;
most of what appeared on the console consisted of orders for the operator to mount tapes, change
paper in printers, and such.)
Today you need more entertainment value. If you want something really cool, you might try outsourcing the job to a Flash developer. Provide some way for Flash to get the needed data, and do all the eye candy in Flash.
The initial cause of the incident was probably a bad weld in a busbar joint. But they'll never know; the entire busbar was vaporized when it lost superconductivity under load.
The quench protection system wasn't designed to properly handle a failure of the superconducting busbar between two magnets. There's an elaborate system to dump the energy from a magnet that's starting to lose superconductivity into a big resistor bank. They expected occasional problems within the magnet windings, but this failure wasn't in a winding. The quench system is being redesigned.
The cryogenic system needs many more pressure relief valves. In this event, 6 tons of liquid helium was vaporized, which is 30,000 cubic meters at 1 atmosphere. That much helium couldn't get out of the existing relief valves fast enough, sizable parts of the plumbing were damaged, and magnets were pushed off their mounts. Now that was just bad pressure-vessel design. They should have had enough relief valves or rupture discs for the worst-case scenario. That would have localized the problem. Given the huge amount of energy in the magnets, in close proximity to liquid helium, in an experimental machine, this could not be a totally unexpected possibility.
More relief valves are going in, which means the whole ring has to be brought up to room temperature and atmospheric pressure for plumbing work.
Then the whole commissioning process has to be repeated, which takes months.
The tunnels are empty of people when power is on, because if all that helium vents, the air is unbreathable. But this event was big enough that it could have affected people in experiment halls at tunnel level. If this had happened during actual use, people could have been killed.
A magnet quench isn't supposed to be a big deal. Early design specs said that restarting after a magnet quench should only take a few hours. Oops.
You are receiving spam not nuclear weapons, you idiot. It's not terrorism.
Tens of millions of American computers are under the direct control of hostile foreign interests.
At any moment, they can be ordered to do anything by those interests, including erasing files, sending financial information, or attacking infrastructure sites. That's a much bigger threat than some guys mouthing off in a bar in Miami about blowing up some building, which got the FBI's full attention.
So where are the US antiterrorism people? This is an attack on US assets by foreign nationals. We have a whole Department of Homeland Security. They had a good computer security guy in charge of dealing with such attacks, Amit Yoran, and he quit in 2004, fed up because DHS didn't really want to deal with real problems. His replacement was a career lobbyist. Really. "He served as Director of 3Com Corporation's Government Relations Office in Washington, DC where he was responsible for all aspects of the company's strategic public policy formulation and advocacy." That's America's first line of defense against cyberterrorism.
FBI testimony before Congress, 2001: "The FBI believes cyber-terrorism, the use of cyber-tools to shut down, degrade, or deny critical national infrastructures, such as energy, transportation, communications, or government services, for the purpose of coercing or intimidating a government or civilian population, is clearly an emerging threat for which its must develop prevention, deterrence, and response capabilities."
FBI testimony before Congress, 2004: "
In the event of a cyberterrorist attack, the FBI will conduct an intense post-incident investigation to determine the source including the motive and purpose of the attack."
So where's the action?
Heads need to roll at DHS and the FBI.
Take a look at rural electrical cooperatives
on
Houses With Tails
·
· Score: 1
This is a commercial proposal from that guy from Israel who runs BetterPlace. First he was going to wire Israel with charging stations. Then it was Hawaii. Now it's the SF Bay Area.
I'd be more impressed if he actually deployed something before announcing the next vaporware deal.
They haven't even demoed a working prototype of the automated battery-exchange station.
There's a an animated video, but it's just conceptual.
The first two locations made more sense. On a small island, electric cars could work - you just
can't take a long trip. Since Israel doesn't get along with most of its neighbors, there's not much cross-border car traffic, and the country is small. But the SF Bay Area is a big step up from there.
The whole battery-exchange idea seems too complex mechanically.
It requires a big standardized battery pack across a range of vehicles.
It's interesting to think about how one might make the battery-exchange system work. You need a very rugged connector suitable for heavy current, blind mating, and bad weather. Such devices are rare, but the New York City Transit Authority has had them on subway cars since 1914. Subway cars can be coupled and uncoupled without anyone going near a coupler, and the couplers connect air and electrical lines. So there's a mechanism that can do the job.
This article is a bad rehash of a 2004 Gamasutra article. It doesn't improve much on that article, although it should. There are some significant issues to explore here.
A good starting issue is the relationship between graphical viewpoint and literary viewpoint. In some games, the player has exactly the viewpoint of the character they're controlling. In others, the player is a step back from the character graphically. Tomb Raider is an example. Note that in Tomb Raider, you're controlling Lara Croft, but you're not her, as her commentary makes clear.
Looking out from the character's viewpoint creates the problem that the player sometimes needs a bigger field of view than the screen provides. There have been a few attempts to fix this problem with VR-type hardware, but those are rare, and if you've ever played a game in full gloves-and-goggles VR gear, you know why. Providing view-direction controls is usually painful for gameplay. That's what drives game designers towards a remote viewpoint.
This is completely independent of the literary viewpoint. There are games where the user is the character, there are games where the user drives the character, and there are games like the Sims where the user can only influence the character. These are literary conventions, independent of the graphical viewpoint. There seems to be a convention that if your viewpoint is from the character's eye position, you are the character.
Once the viewpoint takes a step back, the possibility of some disassociation from the character is opened up.
Now consider shared virtual worlds with avatars. In Second Life, your avatar is you - no question. Most MMORPGs are like that. Why? Because you're held responsible for the acts of your avatar. If you're a jerk in Second Life, it has consequences. Life in Everquest has duties; when your guild is raiding, you're expected to be there fighting with them.
All this is well known in the game design community. The article doesn't really capture the subtle issues.
If you want to see addiction, visit a golf course.
It's a real problem. Successful executives have been lost to golf addiction. Forbes Magazine once commented that more executives have been lost to golf than alcohol. There are people who skip work to play golf. It's not a joke.
Our AdRater plug-in has similar privacy issues. It's a plug-in that "phones home" to get information about the advertisers whose ads appear on a site. Here's what we tell users:
AdRater "phones home", but tells us as little as possible. AdRater sends the domain name associated with each advertisement you see to SiteTruth. Thus, we can tell what advertisers have reached you, but cannot tell what web pages you have been viewing. We can't tell if you click on an ad. AdRater does not use "cookies" or any other user identifiable information other than your current IP address.
If we change any of this, the changes will not take effect until you download and install a new version of AdRater.
AdRater does not rate ads on secure pages, so no information about a secure page is ever sent to our servers.
Now that wasn't hard, was it?
For really technical users, we publish the API AdRater uses, so you can check to see that we're telling the truth about what data goes back and forth.
Slashdot Mirror
QNX, the real-time operating system, does not page to disk. (Not for most processes, anyway. Read on.) The GUI has a bar in the lower right hand corner which shows how much memory is in use; if memory fills up, processes have requests for more memory rejected.
The big advantage of this is consistent performance. Hard real time works. There are no pauses waiting for the disk. This is what you want for entertainment applications, like video players, audio players, and games.
It's possible to set up paging for specific programs, though. GCC has paging, so that huge programs can be compiled, somewhat slowly, on smaller systems. By default, though, paging is not used. Provided that applications aren't bloatware, this works quite well.
It's something to think about for Linux. Should programs be paged by default? Maybe that era is over.
This is an iffy idea for data that actually matters. The "torrent" type systems sort of work because they're willing to accept very poor data integrity in exchange for free music and video. Even that's going downhill, as more content shows up with logos, ads, and other various dreck tacked on.
When it doesn't work, or something gets lost, who do you blame?
Security is supposed to be through "signing". Who's signing what? Does everybody sign their own check-in, do servers sign collections of files, or what? How do you prevent the insertion of hostile code?
The problem with "web of trust" systems is that it's too easy to create phony identities on line, who then pretend to trust each other. Like link farms for search engine spamming.
About ten years ago, Stanford used to have a small fenced yard on Stock Farm Road which contained some large stainless steel items, mostly large-diameter plumbing left over from physics experiments. A small radioactive trefoil was posted on the fence, and it had its own street light, but other than that, it wasn't protected.
I bicycled by this every day on my way to the Stanford barn (I kept a horse on campus at the time). One day I noticed that the fence had been cut and much of the metal was missing. So I stopped by Stanford's toxic waste incinerator ("environmental safety facility") nearby to report this, and was sent to the radiation safety officer. He immediately made some calls.
Stanford had to have people check all the scrapyards for miles around, but nothing seriously radioactive turned up. The steel had been there for years, and was down to about twice background, so it wasn't a serious hazard. It was from experiments at the old linear accelerator (not SLAC, the little one at Hansen Labs), and had picked up some induced radioactivity. You can't really make stainless all that radioactive. Stanford shipped out the remaining metal to some remote disposal site for burial.
Given that the purported usage of .tel is for non-mail applications, all mail from ".tel" should be blocked. Don't even accept a SMTP connection.
Ever notice how the Enterprise in Enterprise looked way more advanced that the Enterprise in Star Trek.
It got to be embarrassing. The original Star Trek bridge now looks like an outdated comm center for mall security.
The original Battlestar Galactica bridge from the 1970s was powered by Tektronix, and many of the controls actually did something visible. This was a real problem for the actors, who had to learn how to operate the systems.
"2001" was more futuristic. An AI took care of the details, and the crew just chatted with the AI.
SCO still has to get out of bankruptcy. Unless they find an outside investor, that's hopeless. In this market, they're unlikely to find an outside investor. They'll have trouble getting financing in any form. I expect Chapter 7 liquidation by spring.
Anybody who buys SCO for the litigation rights gets stuck with the potential liability in the IBM lawsuit. That's a big liability, IBM has good lawyers, and IBM was winning when the bankruptcy put that suit on hold. IBM made $11 billion in profits last year on revenue of $105 billion, so they can continue to afford Cravath lawyers.
Most of the issues mentioned don't affect servers much, which is why Linux does well on servers but remains a pain on the desktop.
Yes, there are too many kernel-level APIs. I'd prefer a microkernel. As something of a QNX fan, it's been amusing to see, over time, Linux add most of the features of QNX, such as the ability to run drivers and file systems in user space. Unfortunately, the Linux kernel people don't take out the old stuff. Hence the kernel bloat. Probably unfixable. Linux still has mediocre interprocess communication, by the way.
X11 sucked in the 1990s, and it still sucks, but less than it used to.
Configuration via text files really is obsolete. But the Windows registry, which is just a tree of tuples, isn't the right answer either. The right answer is SQL databases. With a database, the data is always in the correct format; if you screw up the syntax, it's caught at insertion time. There's locking; you don't need kludges like "vipw". Changes on the fly are handled properly. The database can enforce consistency rules, always a headache with text files. Databases can be accessed with command line tools, GUI tools, automated tools, or even PHP scripts. Tiny implementations of SQL databases are available; they usually update slowly, but update traffic is rarely a bottleneck for configuration. In the early days of Linux, nobody knew what to do about databases, but now that almost every web site has one, everybody is familiar with how to drive an SQL-based system.
Why, at this late date, is anyone still using Sendmail? There are far better alternatives, including QMail and Postfix.
You can download the entire data set, which has had some data removed.
It's mostly cellular phone transactions. Your cellphone provider and NSA already have this data.
That's a lot of cash for a startup. I doubt they're good for the money. So, no bailout.
What this guy seems to be complaining about is that Wikipedia doesn't have enough coverage of the parts of computer science he's interested in. His field seems to be probabilistic algorithms. This is a relatively new field. The general idea is that there are problems for which an algorithm with some randomness is much faster than a deterministic algorithm, at least for the worst case. Classic examples are the simplex method in linear algebra and the traveling salesman problem.
In the last twenty years, there's been a fair amount of work on generalizing this concept to a wider class of problems and putting a theoretical basis under it. Wikipedia has some articles on this. See BPP. I'm not up on this stuff (my CS degree is too old), but at least there's some coverage.
Because this is an area where there aren't many useful results yet, it's hard to write encyclopedia articles. It may be too early to tell what's useful and what's a dead end.
I'd be surprised if, say, Encarta even mentions this subject.
"Space travel is utter bilge" - Richard van der Riet Wolley, Astronomer Royal, 1955.
He was right. Back in 1955, he crunched the numbers, and realized that you couldn't build a rocket that lifted itself into orbit while carrying much of a payload.
Only by excessive weight reduction and throwing away big chunks of the launch vehicle does space travel work at all. Space travel on chemical fuels will never work much better than it does now. It's an inherent limitation of chemical fuels. After fifty years of trying, it's still only possible to just barely get stuff into orbit, using huge rockets to lift dinky payloads. The vehicles are so weight-reduced that they're too fragile to reuse without a major overhaul after each flight. We'll never get to something with the robustness of a commercial airliner, or even a jet fighter.
We should resign ourselves to launching small satellites and planetary probes. Manned spaceflight is just an expensive ego trip for nations. The ISS turned out to be pointless; people go there, but nothing much gets done there. It's not useful for astronomy, earth observation, scientific research, manufacturing, or even for military purposes.
If we ever get a better power source, like fusion or a nuclear rocket that doesn't make a big mess, this could change. But on chemical fuels, space travel is a dud. It's time to admit that and give it up.
"Foundation" would be a joke today. "We can predict the future. With math. In detail. By hand!" People are less impressed with mathematical prediction now; enough of it has been done to make it clear what's possible and what isn't.
Wall Street has had sizable efforts in that direction. You can at best do a little bit better than noise, some of the time. Which was enough to create hedge fund billionaires.
The "Hydrogen Economy" was partly the result of a stupid book by Jeremy Rifkin. Read it and note how little it says about where the hydrogen comes from. It was promoted by the Bush/Cheney crowd as a means for diverting attention from electric cars.
Using electricity to break water into hydrogen and oxygen, then liquefying the hydrogen, storing it as a liquid, then recombining it in a car (either in an engine or a fuel cell) is incredibly inefficient. The only advantage over batteries is that it looked like it might provide more range. Battery energy density has improved in the last decade, though. Battery cost is still a problem. But none of the hydrogen cars are cheap. Nor do they really have that much range. Arnold's hydrogen-powered Hummer only has a 60-mile range.
BMW actually built about 100 "hydrogen powered" cars. But they mostly run on gasoline; although they can optionally run on hydrogen, that's mostly for PR purposes. The liquid hydrogen tank has a "use it or lose it feature"; the BMW vehicle will evaporate all its hydrogen in about 10-12 days.
It looks like an idea whose time has passed.
Cross-compiling Java into Javascript seems undesirable. You'll get bloated Javascript as Java constructs are decomposed into Javascript primitives. Then you get to debug the emitted code, which is not going to be fun. Writing Javascript is a pain, but there are libraries. Look for libraries that aren't too big, can't be changed remotely by some vendor, and don't try to be "frameworks".
Most browsers can run Java applets, after all. If you really want to use Java on the client, you can use Java on the client. It will execute faster than Java compiled into Javascript. You can even hide that stupid Sun ad that appears as the JVM loads.
The big jump in quality comes when the channel is end-to-end digital. That's a huge improvement over NTSC. But 1080p from a DVD player with upscaling and HDMI output is hard to distinguish from "broadcast-quality" HDTV. Pixar's pixel-clean digital animation on Blu-Ray looks great, because all the detail really is there, the compression isn't too harsh, and Pixar makes their Blu-Ray disks from the digital data, not a photographic film intermediate. If there's photographic film in the middle, the image is degraded, and a sizable chunk of the bandwidth goes into trying to represent film grain.
There's still too much compression,. Look at football in HDTV. While the camera pans, there's blurring, and shortly after, but not immediately after, the camera stops moving, the blades of grass suddenly get sharp edges as the data stream catches up. ESPN insists on a minimum bandwidth allocation from cable companies to try to keep the compression artifacts down to a tolerable level, but it's still marginal.
It's almost better to have lower resolution rather than annoying compression artifacts.
Most major sites with slow-loading pages suffer from "Web 2.0 overload". Page loads usually hang not because the requested URL isn't being served fast enough, but because some additional file is needed and isn't being served fast enough. When Slashdot pages are loading slowly, for example, you'll usually see "Waiting for pagead2.googlesyndication.com", "Waiting for ad.greenmarquee.net", "Waiting for ad.doubleclick.net", "Waiting for ad.yieldmanager.com", or "Waiting for m1.2mdn.net". That's where the load delays come from. Cacheing doesn't help, because those services want to serve a different ad every time.
Then there's CSS. The business about CSS speeding up page loading was crap. We're seeing pages that load ten or fifteen CSS files, often from sites that don't load all that fast. Handheld devices don't have the cache capacity of desktops, so the odds that something big, like Google Widgets, will have to be reloaded is reasonably high.
Then there's "onload", where, after the base page is loaded, an XMHHttpRequest is made to get more info. Now you have serial delays; the browser can't parallelize the loads. A good example is RushmoreDrive, the "black search engine" Ask is trying as a niche product. Slowest loading home search page in the industry. Look at the HTML and you'll see why.
If Apple wants faster load times, they should put ad blocking in the iPhone's browser. That would cut page load times way down on ad-heavy sites.
Way too many years ago, in 1971, I did something like this for a UNIVAC 1108 mainframe. We had a big CRT hanging from the ceiling of a glass-walled computer room, showing some basic information like current job status, memory utilization bar chart, backlog, and console messages. Every four seconds, the display changed to a new screen.
People would actually come up to the glass wall to watch. For the first time, there was some indication of what the mainframe was doing. The mainframe's console was a teletype, and the operator could make some status inquiries, but at 110 baud, you couldn't get mucn insight into what was going on. (That operating system viewed the operator as a peripheral; most of what appeared on the console consisted of orders for the operator to mount tapes, change paper in printers, and such.)
Today you need more entertainment value. If you want something really cool, you might try outsourcing the job to a Flash developer. Provide some way for Flash to get the needed data, and do all the eye candy in Flash.
The initial cause of the incident was probably a bad weld in a busbar joint. But they'll never know; the entire busbar was vaporized when it lost superconductivity under load.
The quench protection system wasn't designed to properly handle a failure of the superconducting busbar between two magnets. There's an elaborate system to dump the energy from a magnet that's starting to lose superconductivity into a big resistor bank. They expected occasional problems within the magnet windings, but this failure wasn't in a winding. The quench system is being redesigned.
The cryogenic system needs many more pressure relief valves. In this event, 6 tons of liquid helium was vaporized, which is 30,000 cubic meters at 1 atmosphere. That much helium couldn't get out of the existing relief valves fast enough, sizable parts of the plumbing were damaged, and magnets were pushed off their mounts. Now that was just bad pressure-vessel design. They should have had enough relief valves or rupture discs for the worst-case scenario. That would have localized the problem. Given the huge amount of energy in the magnets, in close proximity to liquid helium, in an experimental machine, this could not be a totally unexpected possibility.
More relief valves are going in, which means the whole ring has to be brought up to room temperature and atmospheric pressure for plumbing work. Then the whole commissioning process has to be repeated, which takes months.
The tunnels are empty of people when power is on, because if all that helium vents, the air is unbreathable. But this event was big enough that it could have affected people in experiment halls at tunnel level. If this had happened during actual use, people could have been killed.
A magnet quench isn't supposed to be a big deal. Early design specs said that restarting after a magnet quench should only take a few hours. Oops.
Tens of millions of American computers are under the direct control of hostile foreign interests. At any moment, they can be ordered to do anything by those interests, including erasing files, sending financial information, or attacking infrastructure sites. That's a much bigger threat than some guys mouthing off in a bar in Miami about blowing up some building, which got the FBI's full attention.
So where are the US antiterrorism people? This is an attack on US assets by foreign nationals. We have a whole Department of Homeland Security. They had a good computer security guy in charge of dealing with such attacks, Amit Yoran, and he quit in 2004, fed up because DHS didn't really want to deal with real problems. His replacement was a career lobbyist. Really. "He served as Director of 3Com Corporation's Government Relations Office in Washington, DC where he was responsible for all aspects of the company's strategic public policy formulation and advocacy." That's America's first line of defense against cyberterrorism.
The FBI has an antiterrorism operation. What are they doing? What they say they're doing is working to "strengthen and support our top operational priorities: counterterrorism, counterintelligence, cyber, and major criminal programs." What they're actually doing is flying around the FBI director in the private jet purchased with antiterrorism funds.
FBI testimony before Congress, 2001: "The FBI believes cyber-terrorism, the use of cyber-tools to shut down, degrade, or deny critical national infrastructures, such as energy, transportation, communications, or government services, for the purpose of coercing or intimidating a government or civilian population, is clearly an emerging threat for which its must develop prevention, deterrence, and response capabilities."
FBI testimony before Congress, 2004: " In the event of a cyberterrorist attack, the FBI will conduct an intense post-incident investigation to determine the source including the motive and purpose of the attack."
So where's the action?
Heads need to roll at DHS and the FBI.
Rural electrical cooperatives do much the same thing for electrical power.
This is a commercial proposal from that guy from Israel who runs BetterPlace. First he was going to wire Israel with charging stations. Then it was Hawaii. Now it's the SF Bay Area.
I'd be more impressed if he actually deployed something before announcing the next vaporware deal. They haven't even demoed a working prototype of the automated battery-exchange station. There's a an animated video, but it's just conceptual.
The first two locations made more sense. On a small island, electric cars could work - you just can't take a long trip. Since Israel doesn't get along with most of its neighbors, there's not much cross-border car traffic, and the country is small. But the SF Bay Area is a big step up from there.
The whole battery-exchange idea seems too complex mechanically. It requires a big standardized battery pack across a range of vehicles.
It's interesting to think about how one might make the battery-exchange system work. You need a very rugged connector suitable for heavy current, blind mating, and bad weather. Such devices are rare, but the New York City Transit Authority has had them on subway cars since 1914. Subway cars can be coupled and uncoupled without anyone going near a coupler, and the couplers connect air and electrical lines. So there's a mechanism that can do the job.
This article is a bad rehash of a 2004 Gamasutra article. It doesn't improve much on that article, although it should. There are some significant issues to explore here.
A good starting issue is the relationship between graphical viewpoint and literary viewpoint. In some games, the player has exactly the viewpoint of the character they're controlling. In others, the player is a step back from the character graphically. Tomb Raider is an example. Note that in Tomb Raider, you're controlling Lara Croft, but you're not her, as her commentary makes clear.
Looking out from the character's viewpoint creates the problem that the player sometimes needs a bigger field of view than the screen provides. There have been a few attempts to fix this problem with VR-type hardware, but those are rare, and if you've ever played a game in full gloves-and-goggles VR gear, you know why. Providing view-direction controls is usually painful for gameplay. That's what drives game designers towards a remote viewpoint.
This is completely independent of the literary viewpoint. There are games where the user is the character, there are games where the user drives the character, and there are games like the Sims where the user can only influence the character. These are literary conventions, independent of the graphical viewpoint. There seems to be a convention that if your viewpoint is from the character's eye position, you are the character. Once the viewpoint takes a step back, the possibility of some disassociation from the character is opened up.
Now consider shared virtual worlds with avatars. In Second Life, your avatar is you - no question. Most MMORPGs are like that. Why? Because you're held responsible for the acts of your avatar. If you're a jerk in Second Life, it has consequences. Life in Everquest has duties; when your guild is raiding, you're expected to be there fighting with them.
All this is well known in the game design community. The article doesn't really capture the subtle issues.
If you want to see addiction, visit a golf course.
It's a real problem. Successful executives have been lost to golf addiction. Forbes Magazine once commented that more executives have been lost to golf than alcohol. There are people who skip work to play golf. It's not a joke.
Our AdRater plug-in has similar privacy issues. It's a plug-in that "phones home" to get information about the advertisers whose ads appear on a site. Here's what we tell users:
AdRater "phones home", but tells us as little as possible. AdRater sends the domain name associated with each advertisement you see to SiteTruth. Thus, we can tell what advertisers have reached you, but cannot tell what web pages you have been viewing. We can't tell if you click on an ad. AdRater does not use "cookies" or any other user identifiable information other than your current IP address.
If we change any of this, the changes will not take effect until you download and install a new version of AdRater.
AdRater does not rate ads on secure pages, so no information about a secure page is ever sent to our servers.
Now that wasn't hard, was it?
For really technical users, we publish the API AdRater uses, so you can check to see that we're telling the truth about what data goes back and forth.