I machined the body out of 1-inch aluminum hex bar stock.
He actually machined out the center of hex bar stock.
Boring a large-diameter hole lengthwise through bar stock is a slow job, and 80% of the metal ends up as chips. You don't do that in a production product. (Well, Apple once did it for one model of laptop, but that didn't catch on.) The outside machining doesn't look all that tough. It's lathe work, either manual or CNC. There's a lot of excess metal there, though, which runs the weight up.
If you want a good flashlight, get one of the MagLite models. They have LED models now, and even offer a blink option and "intelligent battery management". They're also waterproof, shock-resistant, easy to grip, and the standard flashlight for military and first responder use. They're machined out of aluminum tube, not stamped or extruded.
The problem with flashlights isn't features. It's corrosion and wiring failures. Adding all that complexity means a lot more internal connections to fail. If you're going to make something like this, it needs to go through the military ruggedness tests.
Most of the whining I read about patents is from people who don't do much original work.
The MPEG issue isn't a patent validity issue, anyway. It's an antitrust issue. Narrow patents are easy to get but only useful in areas where there's a de-facto standard. Classics in this area were the Hayes modem escape sequence patent (wait, send "+++", wait), the GIF compression patent, and the DOS file system long name patent. Each was quite narrow, and there were other ways to do something equivalent. But because the dominant company in the industry was able to establish a de-facto standard in that area, with which others had to be compatible, it was hard to work around the patents.
Note the phrase "dominant company in the industry". That's a phrase from antitrust law. Only a company with a monopoly, or a trust (which MPEG-LA is) can exploit a narrow patent in that way. If the US DOJ had an antitrust operation that was as aggressive as it was from 1940 to 1970, we wouldn't have this problem.
NASA needs a big cut in their PR budget. They're still promoting stuff vaguely related to their mission, while the actual business of launching stuff is being outsourced.
The original Linux EEE PCs ran the most god-awful distro imaginable.
It had to fit in 2GB of file space, and still have something left for users. But I agree that it sucks. I have several EeePC 2G Surf machines, obtained cheaply from a failed startup company. I use them to run some embedded system demos, where all that runs is one Python application. The biggest problem is that the WiFi driver is flaky. The second biggest problem is that the "union" file system, which makes one read-only file system and one read-write file system appear to be a single pathname space, leaks inodes, and has to be flushed out occasionally.
The problem with Asus is that they can't be trusted as a Linux vendor. They've had on again, off again Linux support for years.
Over a decade ago, there was a really good voice-controlled phone system called Wildfire (audio demo). It took a lot of computer power for the time, it was an expensive service to provide (racks of machines in the central office) and originally cost about $5 to $10 a day. It let you juggle multiple calls and callers through a very fast-responding voice interface.
Orange, the European mobile provider, offered Wildfire as an extra-cost service from 2000 to 2005, then discontinued it over customer objections.
Then Microsoft bought the company behind Wildfire, did nothing with the technology, and closed it.
Today, it should be possible to put Wildfire capability in a phone. So what Woz is proposing is really 1998 technology.
This is nothing to do with the App store being open, this is more to do with Android App devs no doubt learning to code on a PC and not really getting to grips with coding for a mobile environment how Android multitasks in a unique way. In desktop development power consumption is rarely even thought about.
That's amusing. Google has re-invented Go Computer's PenPoint. That's how they ran multiple semi-persistent applications on their tablet in the late 1980s.
I heard the same thing a dozen years ago from another major director. He'd produced several successful films which had live actors and CGI characters interacting, but the cost was high and the staff was too large. He spent most of his time managing the huge animation staff rather than directing.
He liked "Reboot", the TV show, which was produced on a weekly basis by a staff of about 30. That was the first completely computer-animated TV series.
His hope was that the production quality you could get operating on that scale would improve to the level needed for a feature film. He wanted technology that would get the cost of a major feature film down to $20 million or so. He'd have more artistic freedom then. The $100 million pictures are so preplanned that, by the end of preproduction, all the creative work is done. Then it's just a manufacturing job.
So far, nobody has had a breakthrough on costs. "Sky Captain and the World of Tomorrow" tried, but that came in around $70 million. In "Sky Captain", if nobody touches it, it's CGI. That didn't cut costs as much as expected. CGI seems to have replaced the old army of set carpenters, painters, and modelmakers with an army of CGI set designers, texture artists, and animators.
At the low end, there's been progress. See New Media Animation, out of Taiwan. Fastest animation house in the world - finished animations in an hour and 30 minutes. For Slashdot readers, I recommend NMA's version of the Steve Jobs Reality Distortion Field.
Google revenue for 2010 was $29 billion. Facebook revenue was $1.86 billion. If Google was as successful in "social" as Facebook, it would barely affect their bottom line. "Social" just isn't that big a business.
There are bigger businesses where Google missed out - in telephony, music sales, and movie sales. The ones where Apple is making money. Apple revenue for 2010 was $63.5 billion. That's where Schmidt failed.
Google is trying to figure out how to monetize Android, but so far, not with great success. Apple has been very successful in using the iPhone to create a direct connection between the user's wallet and Apple's bank accounts. Google tries to do that, but not as profitably.
Meanwhile, while ordering their people to focus on "social", Google is having problems in their core business - search. Back in Q3 2010, they merged Google Places results into web search, not realizing how easily Places could be spammed. That backfired and got them some bad press. Then there was the Demand Media content farm problem and the J.C. Penny link farm embarrassment. The press then caught onto the fact that Google isn't very good at stopping web spam, "black-hat" SEO started to go mainstream, and Blekko, with their strong anti-spam policies, started to gain traction.
Now the FDA and the Justice Department are investigating Google for knowingly running ads for sleazy offshore pharmacy operations. Google may have to pay $500 million in fines.
That's a classic big-company mistake - failing to run the cash cow properly, while management is distracted with the shiny new stuff.
(Funny how this keeps being modded down. It was at +3 earlier. There's a general pattern with criticisms of Apple - they get high ratings when first posted, then, after about two hours, the rating drops. Hmm.)
That's because you're looking at really good pilots, in really good shape, flying under near ideal conditions, being very careful. Even with that, one test pilot has had six knee injuries. Just walking downstairs with 170 pounds on your back is tough.
The basic trouble with jetpacks is that knees are terrible landing gear. You have to land vertically with a huge mass to stop, and you can't do a controlled fall like a parachute landing. Achieving altitude is not the problem. Landing is the problem.
This thing, like the Solotrek, has landing skids, which take the landing shock. But then it's not really a jetpack. It's more like the Williams X-Jet Flying Platform from the 1980s, probably the best flying machine in this category.
DeconGel is a useful material, typically used for little lab-sized spill cleanup jobs. They're going to need tank truck loads of this stuff.
This material concentrates contamination, rather than spreading it across wipes, water, and other cleaning agents. The blue gel can even be incinerated in special high-temperature hazardous-waste incinerators; the radioactives end up in the ash, not the gases. So you end up with a modest number of drums of low-level radioactive dirt.
Perhaps with the need for large quantities of this stuff, the price will come down. If it were cheap, this would be a useful material for routine tough cleaning jobs. It can clean grouted tile, for example. People who have to clean foreclosed houses might find this useful.
What's needed is an indictment with language like this:
"vendor knowingly and with intent to defraud remotely accessed customer's telephone without the explicit permission of customer and installed programs which accessed vendor's network, accumulating charges which accrued to vendor and were charged to customer."
The actual BEA report, which should be read before commenting, does not assign blame. That will come later.
At one point, the left side airspeed display showed 215 knots, far above stall speed. The backup airspeed indicator showed 185 knots, also above stalling speed. The right side airspeed display value isn't logged. Then all speeds showed as invalid. Given that conflicting information, at night in a thunderstorm over water with no outside visual cues, it's not totally unreasonable that the pilots, finding themselves losing altitude but thinking they had more airspeed than they did, tried to pull up.
The basic problem with parallel programming is that, in most widely used languages, all data is by default shared by all threads. C, C++, and Python all work that way. The usual bug is race conditions.
There have been many languages for parallel programming which don't have default sharing, but they've never taken over outside some narrow niches. Partly because most of them weren't that useful outside their niche.
The other classic problem is that in most shared-data languages with locks, the language doesn't know what the lock is protecting. So you can still code race conditions by accident.
What they're doing with search APIs is instructive.
Google closed down their SOAP search API years ago. They've deprecated their "AJAX search API" as well; that has two years of life left. There's still a search API for searching your own site: "Google Custom Search". But there's no API for searching other sites.
Translation is getting the same treatment. Translation will be available for your own site, but there will be no API for using it generally.
You can see where this is going. Any Google API which offers a generally useful service that's not tied to an ad-supported Google property will probably go away.
Here's the actual trademark image. from the USPTO. "The mark consists of a representation of an actual building interior, namely, a securities exchange trading floor."
Here's the image from the article. It's not an overview of the NYSE trading floor. It''s a single trading post on some exchange. (Of course, at this point, the NYSE is about the only exchange that still has a trading floor. Most of the trading actually happens in the racks of a colocation facility in New Jersey anyway.) If anybody has a right to complain, it's Barclays Capital, because their trading post is being shown in conjunction with a story about fraud, and the story doesn't mention Barclays Capital.
File revisions Many early operating systems could keep several versions of a file. This was in UNIVAC EXEC-8 (now OS-2200 and still in use) in 1967. Creating a new empty file and then writing it did not make the file visible to other processes until the file was closed and committed. The new file then became the latest version, the old file became the previous version, and if a retention limit was specified and had been reached, the oldest version was deleted. UNIX/Linux/DOS/Windows pathname-based systems don't do that, and so atomic file replacement tends to be difficult, non-portable, and often not done.
Rings of protection
MULTICS had better security than anything currently mainstream. The hardware supported protection rings and the OS used them usefully. Things we think of today as "middleware" and "DLLs" ran in inner security rings, not high enough to penetrate the core OS but protected from tampering by applications. Hardware support for calls to a inner ring made this fast. Most OSs today still don't do "big objects" well, things which are used by multiple processes and have state of their own, like databases and printer queues. "Big objects" tend to either have too many privileges or too few.
Safe, fast languages
There's a mind-set today that a language can be either fast or safe, but not both. This is a legacy of some bad design decisions in C that were carried forward into C++. We used to have variants of Pascal suitable for systems programming. Most original Macintosh software was written in Pascal. Modula, by the time of Modula III, was powerful enough to write a whole OS. But it died when Compaq brought DEC and closed down research there.
Capability machines Another casualty of the UNIX/Linux vanilla approach to hardware. The IBM System/38 had security features which allowed fine-grained security within programs. But it was too different from everything else to become mainstream.
Ultimately, what you want to do is to hide the whole call-with-continuation pattern that is the fundamental building block of async under a thick layer of syntactic sugar in the language, such that your async code looks almost exactly the same as the corresponding synchronous version,
There's a theoretical argument (presented by a speaker in EE380 at Stanford last spring, but I don't have the ref handy), that the call-with-continuation model is a superior way to deal with concurrent transactions compared to the lock-and-block model. With the call and continuation model, most of the programmer-confusing headaches of real concurrency go away. The amount of state per transaction is low, since you only save what you need. This reduces memory consumption.
There's something to be said for this. I've written hard real-time code and OS internals code where timing really mattered and concurrency was crucial. But the typical web developer doesn't do anything that tough. Nor should they. They need an environment which doesn't have potential race conditions.
(Misery is writing for a callback environment without continuations, like background code for the original MacOS. With continuations, it works much better.)
Slashdot Mirror
I machined the body out of 1-inch aluminum hex bar stock.
He actually machined out the center of hex bar stock. Boring a large-diameter hole lengthwise through bar stock is a slow job, and 80% of the metal ends up as chips. You don't do that in a production product. (Well, Apple once did it for one model of laptop, but that didn't catch on.) The outside machining doesn't look all that tough. It's lathe work, either manual or CNC. There's a lot of excess metal there, though, which runs the weight up.
If you want a good flashlight, get one of the MagLite models. They have LED models now, and even offer a blink option and "intelligent battery management". They're also waterproof, shock-resistant, easy to grip, and the standard flashlight for military and first responder use. They're machined out of aluminum tube, not stamped or extruded.
The problem with flashlights isn't features. It's corrosion and wiring failures. Adding all that complexity means a lot more internal connections to fail. If you're going to make something like this, it needs to go through the military ruggedness tests.
Most of the whining I read about patents is from people who don't do much original work.
The MPEG issue isn't a patent validity issue, anyway. It's an antitrust issue. Narrow patents are easy to get but only useful in areas where there's a de-facto standard. Classics in this area were the Hayes modem escape sequence patent (wait, send "+++", wait), the GIF compression patent, and the DOS file system long name patent. Each was quite narrow, and there were other ways to do something equivalent. But because the dominant company in the industry was able to establish a de-facto standard in that area, with which others had to be compatible, it was hard to work around the patents.
Note the phrase "dominant company in the industry". That's a phrase from antitrust law. Only a company with a monopoly, or a trust (which MPEG-LA is) can exploit a narrow patent in that way. If the US DOJ had an antitrust operation that was as aggressive as it was from 1940 to 1970, we wouldn't have this problem.
NASA needs a big cut in their PR budget. They're still promoting stuff vaguely related to their mission, while the actual business of launching stuff is being outsourced.
The original Linux EEE PCs ran the most god-awful distro imaginable.
It had to fit in 2GB of file space, and still have something left for users. But I agree that it sucks. I have several EeePC 2G Surf machines, obtained cheaply from a failed startup company. I use them to run some embedded system demos, where all that runs is one Python application. The biggest problem is that the WiFi driver is flaky. The second biggest problem is that the "union" file system, which makes one read-only file system and one read-write file system appear to be a single pathname space, leaks inodes, and has to be flushed out occasionally.
The problem with Asus is that they can't be trusted as a Linux vendor. They've had on again, off again Linux support for years.
Over a decade ago, there was a really good voice-controlled phone system called Wildfire (audio demo). It took a lot of computer power for the time, it was an expensive service to provide (racks of machines in the central office) and originally cost about $5 to $10 a day. It let you juggle multiple calls and callers through a very fast-responding voice interface.
Orange, the European mobile provider, offered Wildfire as an extra-cost service from 2000 to 2005, then discontinued it over customer objections. Then Microsoft bought the company behind Wildfire, did nothing with the technology, and closed it.
Today, it should be possible to put Wildfire capability in a phone. So what Woz is proposing is really 1998 technology.
This is nothing to do with the App store being open, this is more to do with Android App devs no doubt learning to code on a PC and not really getting to grips with coding for a mobile environment how Android multitasks in a unique way. In desktop development power consumption is rarely even thought about.
That's amusing. Google has re-invented Go Computer's PenPoint. That's how they ran multiple semi-persistent applications on their tablet in the late 1980s.
I heard the same thing a dozen years ago from another major director. He'd produced several successful films which had live actors and CGI characters interacting, but the cost was high and the staff was too large. He spent most of his time managing the huge animation staff rather than directing.
He liked "Reboot", the TV show, which was produced on a weekly basis by a staff of about 30. That was the first completely computer-animated TV series. His hope was that the production quality you could get operating on that scale would improve to the level needed for a feature film. He wanted technology that would get the cost of a major feature film down to $20 million or so. He'd have more artistic freedom then. The $100 million pictures are so preplanned that, by the end of preproduction, all the creative work is done. Then it's just a manufacturing job.
So far, nobody has had a breakthrough on costs. "Sky Captain and the World of Tomorrow" tried, but that came in around $70 million. In "Sky Captain", if nobody touches it, it's CGI. That didn't cut costs as much as expected. CGI seems to have replaced the old army of set carpenters, painters, and modelmakers with an army of CGI set designers, texture artists, and animators.
At the low end, there's been progress. See New Media Animation, out of Taiwan. Fastest animation house in the world - finished animations in an hour and 30 minutes. For Slashdot readers, I recommend NMA's version of the Steve Jobs Reality Distortion Field.
There are still comic books? Actual paper comic books?
If they fail to monetize Android, but still pigeon hole the iPhone into a niche market, well that's a defensive win for Google.
That's the argument for Google Docs, Google Spreadsheets, Gmail, etc. - Google's "defensive wins" against Microsoft.
"Social" isn't Google's problem. Mobile is.
Google revenue for 2010 was $29 billion. Facebook revenue was $1.86 billion. If Google was as successful in "social" as Facebook, it would barely affect their bottom line. "Social" just isn't that big a business.
There are bigger businesses where Google missed out - in telephony, music sales, and movie sales. The ones where Apple is making money. Apple revenue for 2010 was $63.5 billion. That's where Schmidt failed.
Google is trying to figure out how to monetize Android, but so far, not with great success. Apple has been very successful in using the iPhone to create a direct connection between the user's wallet and Apple's bank accounts. Google tries to do that, but not as profitably.
Meanwhile, while ordering their people to focus on "social", Google is having problems in their core business - search. Back in Q3 2010, they merged Google Places results into web search, not realizing how easily Places could be spammed. That backfired and got them some bad press. Then there was the Demand Media content farm problem and the J.C. Penny link farm embarrassment. The press then caught onto the fact that Google isn't very good at stopping web spam, "black-hat" SEO started to go mainstream, and Blekko, with their strong anti-spam policies, started to gain traction. Now the FDA and the Justice Department are investigating Google for knowingly running ads for sleazy offshore pharmacy operations. Google may have to pay $500 million in fines.
That's a classic big-company mistake - failing to run the cash cow properly, while management is distracted with the shiny new stuff.
(Funny how this keeps being modded down. It was at +3 earlier. There's a general pattern with criticisms of Apple - they get high ratings when first posted, then, after about two hours, the rating drops. Hmm.)
Given Apple's track record, the terms for their "cloud" will probably be something like this:
Yes, you! Bend lower, please!
There's a Kinect app for that.
Every landing I've seen was like feather.
That's because you're looking at really good pilots, in really good shape, flying under near ideal conditions, being very careful. Even with that, one test pilot has had six knee injuries. Just walking downstairs with 170 pounds on your back is tough.
The basic trouble with jetpacks is that knees are terrible landing gear. You have to land vertically with a huge mass to stop, and you can't do a controlled fall like a parachute landing. Achieving altitude is not the problem. Landing is the problem.
This thing, like the Solotrek, has landing skids, which take the landing shock. But then it's not really a jetpack. It's more like the Williams X-Jet Flying Platform from the 1980s, probably the best flying machine in this category.
DeconGel is a useful material, typically used for little lab-sized spill cleanup jobs. They're going to need tank truck loads of this stuff.
This material concentrates contamination, rather than spreading it across wipes, water, and other cleaning agents. The blue gel can even be incinerated in special high-temperature hazardous-waste incinerators; the radioactives end up in the ash, not the gases. So you end up with a modest number of drums of low-level radioactive dirt.
Perhaps with the need for large quantities of this stuff, the price will come down. If it were cheap, this would be a useful material for routine tough cleaning jobs. It can clean grouted tile, for example. People who have to clean foreclosed houses might find this useful.
This isn't about the technology. It's about Google hiring a PayPal marketing guy who had contacts with the retailers PayPal was going to sign up.
What's needed is an indictment with language like this: "vendor knowingly and with intent to defraud remotely accessed customer's telephone without the explicit permission of customer and installed programs which accessed vendor's network, accumulating charges which accrued to vendor and were charged to customer."
The actual BEA report, which should be read before commenting, does not assign blame. That will come later.
At one point, the left side airspeed display showed 215 knots, far above stall speed. The backup airspeed indicator showed 185 knots, also above stalling speed. The right side airspeed display value isn't logged. Then all speeds showed as invalid. Given that conflicting information, at night in a thunderstorm over water with no outside visual cues, it's not totally unreasonable that the pilots, finding themselves losing altitude but thinking they had more airspeed than they did, tried to pull up.
The basic problem with parallel programming is that, in most widely used languages, all data is by default shared by all threads. C, C++, and Python all work that way. The usual bug is race conditions.
There have been many languages for parallel programming which don't have default sharing, but they've never taken over outside some narrow niches. Partly because most of them weren't that useful outside their niche.
The other classic problem is that in most shared-data languages with locks, the language doesn't know what the lock is protecting. So you can still code race conditions by accident.
What they're doing with search APIs is instructive. Google closed down their SOAP search API years ago. They've deprecated their "AJAX search API" as well; that has two years of life left. There's still a search API for searching your own site: "Google Custom Search". But there's no API for searching other sites.
Translation is getting the same treatment. Translation will be available for your own site, but there will be no API for using it generally.
You can see where this is going. Any Google API which offers a generally useful service that's not tied to an ad-supported Google property will probably go away.
Here's the actual trademark image. from the USPTO. "The mark consists of a representation of an actual building interior, namely, a securities exchange trading floor."
Here's the image from the article. It's not an overview of the NYSE trading floor. It''s a single trading post on some exchange. (Of course, at this point, the NYSE is about the only exchange that still has a trading floor. Most of the trading actually happens in the racks of a colocation facility in New Jersey anyway.) If anybody has a right to complain, it's Barclays Capital, because their trading post is being shown in conjunction with a story about fraud, and the story doesn't mention Barclays Capital.
I've been there, but went on a weekday. The tour guide that day was more into the uninspired architecture of the manor house than the crypto gear.
Many early operating systems could keep several versions of a file. This was in UNIVAC EXEC-8 (now OS-2200 and still in use) in 1967. Creating a new empty file and then writing it did not make the file visible to other processes until the file was closed and committed. The new file then became the latest version, the old file became the previous version, and if a retention limit was specified and had been reached, the oldest version was deleted. UNIX/Linux/DOS/Windows pathname-based systems don't do that, and so atomic file replacement tends to be difficult, non-portable, and often not done.
MULTICS had better security than anything currently mainstream. The hardware supported protection rings and the OS used them usefully. Things we think of today as "middleware" and "DLLs" ran in inner security rings, not high enough to penetrate the core OS but protected from tampering by applications. Hardware support for calls to a inner ring made this fast. Most OSs today still don't do "big objects" well, things which are used by multiple processes and have state of their own, like databases and printer queues. "Big objects" tend to either have too many privileges or too few.
There's a mind-set today that a language can be either fast or safe, but not both. This is a legacy of some bad design decisions in C that were carried forward into C++. We used to have variants of Pascal suitable for systems programming. Most original Macintosh software was written in Pascal. Modula, by the time of Modula III, was powerful enough to write a whole OS. But it died when Compaq brought DEC and closed down research there.
Another casualty of the UNIX/Linux vanilla approach to hardware. The IBM System/38 had security features which allowed fine-grained security within programs. But it was too different from everything else to become mainstream.
Ultimately, what you want to do is to hide the whole call-with-continuation pattern that is the fundamental building block of async under a thick layer of syntactic sugar in the language, such that your async code looks almost exactly the same as the corresponding synchronous version,
There's a theoretical argument (presented by a speaker in EE380 at Stanford last spring, but I don't have the ref handy), that the call-with-continuation model is a superior way to deal with concurrent transactions compared to the lock-and-block model. With the call and continuation model, most of the programmer-confusing headaches of real concurrency go away. The amount of state per transaction is low, since you only save what you need. This reduces memory consumption.
There's something to be said for this. I've written hard real-time code and OS internals code where timing really mattered and concurrency was crucial. But the typical web developer doesn't do anything that tough. Nor should they. They need an environment which doesn't have potential race conditions.
(Misery is writing for a callback environment without continuations, like background code for the original MacOS. With continuations, it works much better.)