This is similar to what some companies have done with software that's reached its commercial end of life - they open-sourced it. This gets them out of the costs of stocking, distributing, and maintaining the product, while making them look good.
Back when you had to renew copyrights, that routinely happened to movies and music; the Internet Archive has an archive of about a hundred feature films and serials whose copyright wasn't renewed. Since the Sonny Bono Copyright Term Extension Act, we don't have that happening in the US any more. But distributors still do have some costs associated with keeping content in the catalog.
So now we're seeing a new way for content owners to get some last publicity benefit out of music that's reached its end of life. We might see more of this from the rap/hip hop business, where careers tend to be short and few artists have long-term hits.
Add stopping this to the list of "things to do after the Democrats take over Congress".
Don't forget to vote, everybody.
And remember, as one leading Democrat has said, if Democrats control either house, there's going to be "oversight, oversight, oversight". Look how much has come out with the Republicans in charge: everything from the plan to divide up northern Iraq amongst oil companies to the CIA's torture program. There has to be more stuff we haven't heard about. Look forward to people like the FBI Director testifying under oath before Congress. Coming soon to a C-SPAN channel near you.
You might also want to volunteer to be a poll watcher, especially if you're in a state with Diebold voting machines.
Voting machines should be at least as secure as slot machines. The state of Nevada has standards for those, as I wrote in a previous Slashdot article. Nevada is concerned with collecting taxes and not cheating customers when the machines are owned by very shady people. So they have technical standards with teeth.
Stuff like this:
... must resist forced illegal entry and must retain evidence of any entry until properly cleared or until a new play is initiated. A gaming device must have a protective cover over the circuit boards that contain programs and circuitry used in the random selection process and control of the gaming device, including any electrically alterable program storage media. The cover must be designed to permit installation of a security locking mechanism by the manufacturer or end user of the gaming device.
... must exhibit total immunity to human body electrostatic discharges on all player-exposed areas.... must exhibit a capacity to recover and complete an interrupted play without loss or corruption of any stored or displayed information and without component failure.... Gaming device power supply filtering must be sufficient to prevent disruption of the device by repeated switching on and off of the AC power.... must be impervious to influences from outside the device, including, but not limited to, electro-magnetic interference, electro-static interference, and radio frequency interference.
All gaming devices which have control programs residing in one or more Conventional ROM Devices must employ a mechanism approved by the chairman to verify control programs and data.... All gaming devices having control programs or data stored on memory devices other than Conventional ROM Devices must:
(a) Employ a mechanism approved by the chairman which verifies that all control program components, including data and graphic information, are authentic copies of the approved components. The chairman may require tests to verify that components used by Nevada licensees are approved components. The verification mechanism must have an error rate of less than 1 in 10 to the 38th power and must prevent the execution of any control program component if any component is determined to be invalid. Any program component of the verification or initialization mechanism must be stored on a Conventional ROM Device that must be capable of being authenticated using a method approved by the chairman.
(b) Employ a mechanism approved by the chairman which tests unused or unallocated areas of any alterable media for unintended programs or data and tests the structure of the storage media for integrity. The mechanism must prevent further play of the gaming device if unexpected data or structural inconsistencies are found.
(c) Provide a mechanism for keeping a record, in a form approved by the chairman, anytime a control program component is added, removed, or altered on any alterable media. The record must contain a minimum of the last 10 modifications to the media and each record must contain the date and time of the action, identification of the component affected, the reason for the modification and any pertinent validation information.
(d) Provide, as a minimum, a two-stage mechanism for validating all program components on demand via a communication port and protocol approved by the chairman. The first stage of this mechanism must verify all control components. The second stage must be capable of completely authenticating all program components, including graphics and data components in a maximum of 20 minutes. The mechanism for extracting the authentication information must be stored on a Conventional ROM Device that must be capable of being authenticated by a method approved by the chairman.
That's part of what's needed.
Those standards cover the possibility of an "alternate program" in a slot machine, and provide a way to check for it, with logs and an external program check capability.
Area, the hottest nightclub in NYC for part of the 1980s, did a complete redecoration and theme change every six weeks. That kept it a hot club for years.
But redesigning a web site doesn't have the same effect. Tribe just did that. (New! Web 2.0! Now you can rearrange your home page!) One of most active tribes is now "Tribe.net bug reports". Oops.
This time it's all "private money"
on
Dot-Com Bubble v2.0?
·
· Score: 4, Interesting
Last time, it was mostly companies going public. This time, it's companies heavily funded with venture capital, and the companies are then bought by other companies.
But it's definitely a bubble. Way too many companies are chasing the same pool of advertising money.
And, unlike Bubble 1.0, most of these new companies don't really do very much. Or even stuff that hasn't been done before.
As I wrote in another article, "social networking" sites have a life cycle. EZboard peaked mid 2003. Nerve peaked early 2002. Bondage.com peaked mid-2003. Tribe peaked early 2006. Xianz (the "Christian Myspace") peaked in spring 2006. Friendster peaked twice, once in late 2005 and again in mid-2006, but that's an unusual pattern. Usually, once they peak, it's downhill after that. Myspace has flattened and looks like it's about to peak. This works just like nightclubs; they become hot, they grow, they get too popular, they get overrun, they decline, they hang on, but nobody cares.
YouTube is terribly vunerable to the RIAA. Once somebody builds a tool to check audio on YouTube against RIAA licensed material, they're going to get notice-and-takedown orders by the ton.
symmetric peer-to-peer interfaces like that provided by Firewire.
Firewire actually has rather strong master/slave relationships; there's a tree, and a tree root, and a master node. But there's a negotiation process during hot-plugging which establishes the master/slave relationships.
One big problem with Firewire is that it doesn't have a notion of device ownership. You can plug two computers together with FireWire, and that will work if both machines support IP or Ethernet over FireWire. But plug a peripheral into the same bus, and there's no mechanism to allocate it to a unique host computer. You'll get a control clash.
Underneath, FireWire isn't really a "bus". It's actually a local area network, and its controllers work more like Ethernet controllers, with packets and buffer chains, than bus adapters.
The "bus" aspect is that there are defined packet formats for loading and storing 32-bit data items in a 64 bit address space. In practice, though, what usually happens is that at the host end, some code formats such a packet, saying "set bit 22 of register 0x2490 at node 3", and when that packet gets to node 3, some little CPU in the peripheral decodes the packet, acknowledges receipt of the packet, a switch statement decodes the "register" address, and code notes that bit 22 means "turn camera on". No status for this event comes back; the host has to send a packet to "read" some other device register to find out what happened.
Giving FireWire a "device register" model turned out, in the end, to be kind of silly. Something more like SCSI, with function codes and statuses, would have made more sense.
(And, in fact, there's SCSI over FireWire.)
You'd get back better status info, and devices which don't implement some functions would have a simple way to report that. This makes it easier to implement generic drivers, reducing the temptation to have to have a special driver for every manufacturer's device. And we all know where that leads.
So if you're designing something like this, don't go with a device register model. Anything smart enough to talk it will have a CPU, so use it.
Take a look at Alexa traffic rankings for "social networking" sites. Many, if not most, of them have already peaked.
EZboard peaked mid 2003. Nerve peaked early 2002. Bondage.com peaked mid-2003. Tribe peaked early 2006. Xianz (the "Christian Myspace") peaked in spring 2006. Friendster peaked twice, once in late 2005 and again in mid-2006, but that's an unusual pattern. Usually, once they peak, it's downhill after that. Myspace has flattened and looks like it's about to peak. This works just like nightclubs; they become hot, they grow, they get too popular, they get overrun, they decline, they hang on, but nobody cares.
If you try to "monetize" the users, they leave sooner.
The real winner in this space seems to be
AdultFriendFinder.com. 57th most popular site on the web, 35th in the US, steady traffic for two years, and it's a pay site. Run by Friendfinder, Inc., the notorious spammers. They seem to have figured out how to "monetize the user base". However, Friendfinder may be inflating their statistics.
There have been a few previous efforts in this direction.
Somebody, I think at UCLA, did some nice work in this area around 1990. They had a pair of small forklift-type machines which worked together to lift larger objects. One would get on each end of a couch, for example, and with very limited intercommunication but good force sensing, they'd move the couch together.
That seemed a very practical idea, but it wasn't followed up at the time. There are many industrial and construction applications where two coordinated machines of moderate size could do a job that would otherwise require a much bigger machine.
There are several bad provisions in that proposal.
The proposal does not require that, when collecting data, the collecting organization specifically identify itself. EU data privacy laws generally require that. California law requires that web sites give "the actual name and address of the business" before accepting credit cards, and that's a good standard. If you can't identify who collected the data, you can't effectively exert your rights against them. "xyz.com" isn't enough; you need "XYZ, Inc. 1234 Wilshire Blvd, Los Angeles, CA".
"Web sites: Visiting pages on a Web site implicitly means the customer consents to the site's privacy statement and terms of use." - that's very weak, and not supported by law.
For some things, even explicit consent is not enough. See the standards at StopBadware.org, which prohibit automatic updating which modifies other programs changes the functionality of the one being updated without user consent. (Think Tivo, where automatic updates took away commercial-skipping. That's badware.)
Personal data transfer to third parties and retention policies need not be specified. Not good. In particular, the owner of the data (the user) needs the right to know which third parties have the data. And the collector of the data must remain responsible for what "affiliates" do with it. This has been a serious problem, where the "good company" disclaims responsibility for what their "affiliate" did. Remember the "outsourced medical transcription" scandal.
The "privacy" document doesn't address the privacy issues associated with digital rights management (DRM). "Who knows what's on your ebook?"
For a more user-side view of privacy from a technical standpoint, the National Association of Theater Owners Digital Cinema Requirements document is valuable. Digital cinema at the movie theater level has DRM, and the theater owners have organized to tell (not ask) the studios exactly how intrusive the DRM can be. Stuff like
"The System shall not compromise the security of the theatre's in-house
network, including the security of digital cinema systems, point-of-sale
systems, and other data systems owned and/or operated by the exhibitor." (i.e. no Sony-type rootkits)
"The system shall be designed to push data to outside business entities per
the needs of the exhibitor, and shall not allow outside business entities to
pull data from the exhibitor's equipment or from the premises without the
express written permission of the exhibitor on a case-by-case basis. All such
communications shall be recorded and shall be auditable by the Exhibitor." (i.e. no spyware; the user has to explicitly send the log data, and can look at it first)
"System components (servers, projectors) shall be capable of being moved
from auditorium to auditorium within the same facility in any combination
without limitation and without requiring receipt of new decryption keys." (you can swap components around without DRM problems)
"Systems shall allow the movement and playback of shows among all
auditorium systems within a complex." (you can move the movie from one room to another without DRM problems)
"New Security Keys shall be delivered within 15
minutes of the time of request." (no long downtime because the DRM people screwed up)
"Systems shall employ the standard interchange method for security log
reports.... Systems shall
employ tools that allow the exhibitor to filter security log reports logs prior to
sharing." (it's all in XML, and you can see what the DRM owner sees.)
Some kind of first-pass search system to find rough matches between Flickr/Youtube/etc posts and copyrighted material will be a big win for the MPAA. There are ways to align and compare pictures, but they're computationally expensive and compare two images, they don't do a general search. This thing might be usable as a first search used to find possible matches, which then get a more detailed examination by the expensive algorithm.
Upload them to the Internet Archive and let them do the conversion. They'll generate streamable MPEG4 for you. Upload the best version you can and don't worry about the size; they'll keep the high-res archival version available for people who need it, and generate low-rez versions for viewing.
OK. One square meter of solar panel is typically good for 130 watts at peak, but only about 655 watt hours per day, or 27 watts averaged over 24 hours. In other words, the average power is about 20% of the peak. So, to get 1.6 megawatts average power, you need about 60,000 square meters of panel, or an area 245 meters square. This is about two football fields of area, or three Wal-Mart Supercenter roofs.
A typical price for a good solar panel today is about $1000 for 160 watts peak. So to get 1.6 * 5 = 8 megawatts peak power, you need 50,000 of those panels, or about $50 million worth of panels. Batteries, inverters, and installation extra. (I suspect that Google is talking about 1.6MW of peak capacity, but that's a phony number to compare to other energy sources that can run 24 hours a day.)
There are already data centers that draw 30 megawatts continuous. That would take about a billion dollars worth of solar panels to power.
And by power plant standards, 30MW is dinky. Commercial power plants today run around a gigawatt.
What's needed is for someone like NY Attorney General Elliot Spitzer to charge Microsoft with reckless endangerment for knowingly, willfully, and negligently distributing and continuing to distribute systems vulnerable to such attacks.
Meanwhile, we may need some brutal firewalls:
All incoming e-mail is reformatted. Attachments are converted to.odf or.png, as appropriate. Stuff that can't be converted is dropped. HTML is parsed, checked for syntax, and Javascript dropped.
All web browsing to non-secure sites is proxied. Javascript is removed. Flash is removed. Java is removed. All binary data is removed. Images are reformatted to.png format and the HTML adjusted to match. No more "Web 2.0"; those sites just stop working.
Web browsing to secure sites via SSL is only permitted if the site has a SSL cert that is a high-grade "we really know who this is" cert.
TCP port 80 is all you get outgoing. Incoming, forget it. UDP, forget it. If you want to message, use the phone.
You have a machine or two around that are outside the firewall for when you desperately need to do something else. Those machines have a canned read-only disk image that's refreshed on each reboot or logout, like Internet cafe machines.
We're probably going to see some companies going to a locked down firewall like that.
Tribe was bought by News Corp (Rupert Murdoch's company) a few months ago. He seems to have bought near the top. Many of the staff left. The recent site redesign (New! Web 2.0!) was something of a flop.
Currently, the most active tribe seems to be "Tribe.net bug reports". Alexa traffic rankings show that Tribe.net peaked around January 2006. It's been downhill since. The current traffic level is about half the peak.
These things work like fads. Remember Nerve.com? Peaked in early 2002 at 4x the present level. They're still around, but nobody cares much.
There's a death spiral to these things. When traffic drops off, so does revenue. Then there's a frantic attempt to boost revenue by making the ads more intrusive, usually accompanied by layoffs. This drives away users.
The work that you shoot down so smugly for the academics is the basis of what is going into the hobbyists.
Actually, I'm more from the academic side. The US academic world is great at theory but terrible at bending metal. In fields where you need a few technicians per engineer, US academia does not cope well. (Except, historically, in high-energy physics, which does have several technicians per engineer, and in the biological sciences, which inherit the tradition of several flunkies per doctor.) You don't get tenure for making nice metal parts.
There are ways around this, usually involving teaming with some industrial partner. But the US has almost no robotics industry. So what we have are academic one-off designs that aren't suitable for volume replication.
The important site to look at is Robots Dreams, which covers Japanese robotics work. The little humanoid robots at the $1000 level are getting quite good mechanically. The best ones now have maybe 70% of the hardware functionality of Asimo at under 1% of the cost. They're typically remote controlled,
but, because they have more degrees of freedom than a human can control with an R/C controller, preprogrammed movements were added. That wasn't good enough, so some hobbyists have added gyros and balance reflexes. Now it starts to get serious.
The hobbyists are doing some very good work. There are competitions and battles for these things. Obstacle courses which look like something from Army basic training. The battles aren't just banging away like Robot Wars; these machines can execute judo throws.
More to the point, the hobbyists are making progress much faster than the academic robotics people ever did. There are more of them, enough to drive a market for mass-produced parts. That makes it easier to build the things.
If you took the best kit humanoid available (which costs about $1200), added a 6DOF inertial unit (a few hundred dollars and getting cheaper every year), a stereo vision system (or even a SwissRanger minature LIDAR), better force sensors in the feet and hands, and a WiFi link, you'd have ASIMO-level capability for a few thousand dollars. We'll probably see that within two years, and probably at a low price point.
Then it's all software. And there's lots of theory out there just waiting to be used. This is going to be fun.
The reason this has been such a slow process is that SCO is the plaintiff, and they're stalling. Usually, the plaintiff, who initiated the case, is pushing the case forward, while the defendant tries to stall. This case is backwards.
But stalling only works for so long. SCO was able to drag out pretrial discovery for years. But now, discovery is over. No more surprises. No more "we'll disclose the evidence when the time comes" from SCO. That deadline has past. Now the pace picks up. Here's the final part of the case schedule, as set by the court:
17-Mar-06 Close of All Remaining Discovery (DONE)
19-May-06 Initial Expert Reports (DONE)
17-Jul-06 Opposing Expert Reports (DONE)
28-Aug-06 Rebuttal Expert Reports (DONE)
22-Sep-06 Final Deadline for Expert Discovery (DONE)
13-Oct-06 Responses to Requests for Admissions (DONE)
25-Oct-06 Oppositions to Dispositive Motions Summary Judgment Motions
24-Nov-06 Reply Briefs on Dispositive Motions (Reply Memoranda)
12-Jan-07 Rule 26(a)(3) Disclosures
19-Jan-07 Final Pretrial Order
22-Jan-07 Deadline for Exchanging Proposed Jury Instructions
26-Jan-07 Motions in Limine
30-Jan-07 Special Attorney Conference and Settlement Conference
05-Feb-07 Oppositions to Motions in Limine
09-Feb-07 Reply Briefs on Motions in Limine
26-Feb-07 5-week Jury Trial
Notice how the events come closer and closer together as the trial date approaches and the judge becomes more directly involved.
The next exciting moments will come in late November or early December, when the judge decides the summary judgement motions. SCO will then be worse off than they are now; the only question is how much worse off.
It's painful reading how that works. It's an achievement. "613 files changed." "It's the most complex kernel feature i ever worked on." But it's one of those things that, for legacy reasons, is much more complex and ugly than it should have been.
It's sad how much effort today goes into working around bad early design decisions. After writing drivers for QNX, where drivers are just user programs with a few extra privileges, it's painful to see the contortions people go through to do them in the more primitive operating systems. The basic problem is that the original UNIX driver model was a "top part", called from read and write calls, and a "bottom part", called from interrupt level. Today, Linux drivers tend to have some threads of their own, they're loadable, and the locking primitives are better, but the headaches of the legacy architecture remain.
The price of this is that drivers remain the biggest source of OS failure. OS developers pile hack on top of hack to try to fix this, the kernel gets bigger and bigger, and it still isn't airtight.
Xen and Minix3 are starting to get it right. Drivers, even hardware drivers, are user programs in those operating systems.
I know, it's not going to get fixed for another generation. QNX is going nowhere because the company that now owns it is in the car stereo business. Minix 3 is still a toy. The Hurd people totally blew it. Mach gave microkernels a bad name. But this actually can be done right, and it takes less code to do it right than the mountain of patches needed to do it the hard way.
Linux has made major progress in the real-time area. But it still doesn't have everything needed.
Many drivers are still doing too much work at interrupt level. There are drivers that have been made safe for real time at the millisecond level, but that's not universal. Load a driver with long interrupt lockouts and your system isn't "real time" any more. This is the biggest problem in practice. There are too many drivers still around with long interrupt lockouts.
The Linux CPU dispatcher is now more real time oriented. (Finally!)
Interprocess communication in Linux is still kind of lame by real-time OS standards. The tight interaction between CPU dispatching and messaging still isn't there, although it's getting better. Interestingly, it's there in Minix 3, and of course, that's been in QNX for years. For simple real-time apps, though, this may not be an issue. Generally, though, if you find the need to use shared memory between processes, it's because your OS's messaging lacks something.
While Linux has been getting down to millisecond level response, QNX has been moving towards microsecond level response. The goal moves. However, millisecond response is good enough for most applications. What really matters in real-time, though, is worst-case response, not average. Benchmarks for real time OSs put a load on the system and measure how fast it responds to a few million interrupt requests. The number people look at is the longest response time.
Despite this, Linux is probably now good enough for most real-time applications that can tolerate a big kernel.
Microsoft has this annoying policy of putting some kind of general purpose execution engine in every Office product, from Word to PowerPoint to IE. Documents don't have to be Turing-complete, people. In fact, they're more useful if they're purely declarative - you can repurpose the content.
(Postscript is the classic bad example. The Postscript model is explicitly an interpreter. As a result, it's difficult to do anything with a Postscript document other than print it in the specified format. Text extraction is tough. Reliable format conversion is very tough. Reliable conversion to a different screen size, which ought to be easy, is terribly hard. Everybody moved away from Postscript, even Adobe. Microsoft should have learned from this.)
The sender knows who initially got the e-mail; that's the addressee. The main article was about tracking to whom the mail was forwarded. Forwarded copies will have the same image links as the original. So if the original recipient and the recipient of a forwarded copy both have anonymous image browsing, the original sender will know only that the message is being read again, but won't know from where.
Their site is fine now. Their equipment, though...
They're a surplus machinery dealer, and much of their equipment has seen hard use followed by neglect. The neglect is worse than the hard use. This lathe is a good example. That's a good Monarch precision lathe, but the picture, taken in 2000, shows considerable rust. Most of their gear is like that; it looks like it came out of an abandoned factory. It's repairable; you can send the lathe back to Monarch for an overhaul. But it's not good for much in its current condition. If there's any rust in the bearings, the precision is lost.
For comparison, see this Monarch Lathe on eBay. Made in 1950, and still in good shape. Those things will last a century if cared for.
If you have machinery like that around that's not in use, you have to oil it, then wrap it in plastic with some dessicant inside.
This is an underlying design/usability problem with Mediawiki and not necessarily Wikipedia itself. Building a proper database framework to be more encompassing (if not all encompassing - damn close) is a Citizendium design goal.
For most of the categories mentioned, the obvious tool for the job is a relatively conventional forms-driven database. Most proper names belong to some well understood category (people, places, companies, books, movies, songs, audio recordings), and those should be handled by some form-based input mechanism which captures the appropriate information for the category. In some cases, it may be possible to obtain data sources to populate or check the database entries. Such entries might also have an associated wiki-type free comment area, but the finding and linking mechanism would be more structured than that of a general wiki. As with IMDB and Gracenote, it should be possible to ask questions like "what films was this actor in" and get a useful result.
From the reader perspective, the output could look much like Wikipedia with subject matter templates. But from the editor perspective, it would be form-based for common article types. This allows for much more input validation. Disambiguation and spelling problems can be caught and corrected during input validation, rather than after the fact by someone else.
With proper names handled separately, the main less-structured wiki space becomes focused on more general concepts. This should reduce clutter substantially.
I'd definitely encourage a division between proper names and other material as a basic organizing concept. It's an easy to understand distinction.
Slashdot Mirror
This is similar to what some companies have done with software that's reached its commercial end of life - they open-sourced it. This gets them out of the costs of stocking, distributing, and maintaining the product, while making them look good.
Back when you had to renew copyrights, that routinely happened to movies and music; the Internet Archive has an archive of about a hundred feature films and serials whose copyright wasn't renewed. Since the Sonny Bono Copyright Term Extension Act, we don't have that happening in the US any more. But distributors still do have some costs associated with keeping content in the catalog.
So now we're seeing a new way for content owners to get some last publicity benefit out of music that's reached its end of life. We might see more of this from the rap/hip hop business, where careers tend to be short and few artists have long-term hits.
Add stopping this to the list of "things to do after the Democrats take over Congress".
Don't forget to vote, everybody.
And remember, as one leading Democrat has said, if Democrats control either house, there's going to be "oversight, oversight, oversight". Look how much has come out with the Republicans in charge: everything from the plan to divide up northern Iraq amongst oil companies to the CIA's torture program. There has to be more stuff we haven't heard about. Look forward to people like the FBI Director testifying under oath before Congress. Coming soon to a C-SPAN channel near you.
You might also want to volunteer to be a poll watcher, especially if you're in a state with Diebold voting machines.
Voting machines should be at least as secure as slot machines. The state of Nevada has standards for those, as I wrote in a previous Slashdot article. Nevada is concerned with collecting taxes and not cheating customers when the machines are owned by very shady people. So they have technical standards with teeth. Stuff like this:
(a) Employ a mechanism approved by the chairman which verifies that all control program components, including data and graphic information, are authentic copies of the approved components. The chairman may require tests to verify that components used by Nevada licensees are approved components. The verification mechanism must have an error rate of less than 1 in 10 to the 38th power and must prevent the execution of any control program component if any component is determined to be invalid. Any program component of the verification or initialization mechanism must be stored on a Conventional ROM Device that must be capable of being authenticated using a method approved by the chairman.
(b) Employ a mechanism approved by the chairman which tests unused or unallocated areas of any alterable media for unintended programs or data and tests the structure of the storage media for integrity. The mechanism must prevent further play of the gaming device if unexpected data or structural inconsistencies are found.
(c) Provide a mechanism for keeping a record, in a form approved by the chairman, anytime a control program component is added, removed, or altered on any alterable media. The record must contain a minimum of the last 10 modifications to the media and each record must contain the date and time of the action, identification of the component affected, the reason for the modification and any pertinent validation information.
(d) Provide, as a minimum, a two-stage mechanism for validating all program components on demand via a communication port and protocol approved by the chairman. The first stage of this mechanism must verify all control components. The second stage must be capable of completely authenticating all program components, including graphics and data components in a maximum of 20 minutes. The mechanism for extracting the authentication information must be stored on a Conventional ROM Device that must be capable of being authenticated by a method approved by the chairman.
That's part of what's needed. Those standards cover the possibility of an "alternate program" in a slot machine, and provide a way to check for it, with logs and an external program check capability.
re-inventing them every so often.
Area, the hottest nightclub in NYC for part of the 1980s, did a complete redecoration and theme change every six weeks. That kept it a hot club for years.
But redesigning a web site doesn't have the same effect. Tribe just did that. (New! Web 2.0! Now you can rearrange your home page!) One of most active tribes is now "Tribe.net bug reports". Oops.
Last time, it was mostly companies going public. This time, it's companies heavily funded with venture capital, and the companies are then bought by other companies.
But it's definitely a bubble. Way too many companies are chasing the same pool of advertising money.
And, unlike Bubble 1.0, most of these new companies don't really do very much. Or even stuff that hasn't been done before.
As I wrote in another article, "social networking" sites have a life cycle. EZboard peaked mid 2003. Nerve peaked early 2002. Bondage.com peaked mid-2003. Tribe peaked early 2006. Xianz (the "Christian Myspace") peaked in spring 2006. Friendster peaked twice, once in late 2005 and again in mid-2006, but that's an unusual pattern. Usually, once they peak, it's downhill after that. Myspace has flattened and looks like it's about to peak. This works just like nightclubs; they become hot, they grow, they get too popular, they get overrun, they decline, they hang on, but nobody cares.
YouTube is terribly vunerable to the RIAA. Once somebody builds a tool to check audio on YouTube against RIAA licensed material, they're going to get notice-and-takedown orders by the ton.
symmetric peer-to-peer interfaces like that provided by Firewire.
Firewire actually has rather strong master/slave relationships; there's a tree, and a tree root, and a master node. But there's a negotiation process during hot-plugging which establishes the master/slave relationships.
One big problem with Firewire is that it doesn't have a notion of device ownership. You can plug two computers together with FireWire, and that will work if both machines support IP or Ethernet over FireWire. But plug a peripheral into the same bus, and there's no mechanism to allocate it to a unique host computer. You'll get a control clash.
Underneath, FireWire isn't really a "bus". It's actually a local area network, and its controllers work more like Ethernet controllers, with packets and buffer chains, than bus adapters.
The "bus" aspect is that there are defined packet formats for loading and storing 32-bit data items in a 64 bit address space. In practice, though, what usually happens is that at the host end, some code formats such a packet, saying "set bit 22 of register 0x2490 at node 3", and when that packet gets to node 3, some little CPU in the peripheral decodes the packet, acknowledges receipt of the packet, a switch statement decodes the "register" address, and code notes that bit 22 means "turn camera on". No status for this event comes back; the host has to send a packet to "read" some other device register to find out what happened.
Giving FireWire a "device register" model turned out, in the end, to be kind of silly. Something more like SCSI, with function codes and statuses, would have made more sense. (And, in fact, there's SCSI over FireWire.) You'd get back better status info, and devices which don't implement some functions would have a simple way to report that. This makes it easier to implement generic drivers, reducing the temptation to have to have a special driver for every manufacturer's device. And we all know where that leads.
So if you're designing something like this, don't go with a device register model. Anything smart enough to talk it will have a CPU, so use it.
Take a look at Alexa traffic rankings for "social networking" sites. Many, if not most, of them have already peaked.
EZboard peaked mid 2003. Nerve peaked early 2002. Bondage.com peaked mid-2003. Tribe peaked early 2006. Xianz (the "Christian Myspace") peaked in spring 2006. Friendster peaked twice, once in late 2005 and again in mid-2006, but that's an unusual pattern. Usually, once they peak, it's downhill after that. Myspace has flattened and looks like it's about to peak. This works just like nightclubs; they become hot, they grow, they get too popular, they get overrun, they decline, they hang on, but nobody cares.
If you try to "monetize" the users, they leave sooner.
The real winner in this space seems to be AdultFriendFinder.com. 57th most popular site on the web, 35th in the US, steady traffic for two years, and it's a pay site. Run by Friendfinder, Inc., the notorious spammers. They seem to have figured out how to "monetize the user base". However, Friendfinder may be inflating their statistics.
There have been a few previous efforts in this direction. Somebody, I think at UCLA, did some nice work in this area around 1990. They had a pair of small forklift-type machines which worked together to lift larger objects. One would get on each end of a couch, for example, and with very limited intercommunication but good force sensing, they'd move the couch together.
That seemed a very practical idea, but it wasn't followed up at the time. There are many industrial and construction applications where two coordinated machines of moderate size could do a job that would otherwise require a much bigger machine.
For a more user-side view of privacy from a technical standpoint, the National Association of Theater Owners Digital Cinema Requirements document is valuable. Digital cinema at the movie theater level has DRM, and the theater owners have organized to tell (not ask) the studios exactly how intrusive the DRM can be. Stuff like
- "The System shall not compromise the security of the theatre's in-house
network, including the security of digital cinema systems, point-of-sale
systems, and other data systems owned and/or operated by the exhibitor." (i.e. no Sony-type rootkits)
- "The system shall be designed to push data to outside business entities per
the needs of the exhibitor, and shall not allow outside business entities to
pull data from the exhibitor's equipment or from the premises without the
express written permission of the exhibitor on a case-by-case basis. All such
communications shall be recorded and shall be auditable by the Exhibitor." (i.e. no spyware; the user has to explicitly send the log data, and can look at it first)
- "System components (servers, projectors) shall be capable of being moved
from auditorium to auditorium within the same facility in any combination
without limitation and without requiring receipt of new decryption keys." (you can swap components around without DRM problems)
- "Systems shall allow the movement and playback of shows among all
auditorium systems within a complex." (you can move the movie from one room to another without DRM problems)
- "New Security Keys shall be delivered within 15
minutes of the time of request." (no long downtime because the DRM people screwed up)
-
"Systems shall employ the standard interchange method for security log
reports
.... Systems shall
employ tools that allow the exhibitor to filter security log reports logs prior to
sharing." (it's all in XML, and you can see what the DRM owner sees.)
Compare that with Windows Vista.Some kind of first-pass search system to find rough matches between Flickr/Youtube/etc posts and copyrighted material will be a big win for the MPAA. There are ways to align and compare pictures, but they're computationally expensive and compare two images, they don't do a general search. This thing might be usable as a first search used to find possible matches, which then get a more detailed examination by the expensive algorithm.
Upload them to the Internet Archive and let them do the conversion. They'll generate streamable MPEG4 for you. Upload the best version you can and don't worry about the size; they'll keep the high-res archival version available for people who need it, and generate low-rez versions for viewing.
OK. One square meter of solar panel is typically good for 130 watts at peak, but only about 655 watt hours per day, or 27 watts averaged over 24 hours. In other words, the average power is about 20% of the peak. So, to get 1.6 megawatts average power, you need about 60,000 square meters of panel, or an area 245 meters square. This is about two football fields of area, or three Wal-Mart Supercenter roofs.
A typical price for a good solar panel today is about $1000 for 160 watts peak. So to get 1.6 * 5 = 8 megawatts peak power, you need 50,000 of those panels, or about $50 million worth of panels. Batteries, inverters, and installation extra. (I suspect that Google is talking about 1.6MW of peak capacity, but that's a phony number to compare to other energy sources that can run 24 hours a day.)
There are already data centers that draw 30 megawatts continuous. That would take about a billion dollars worth of solar panels to power.
And by power plant standards, 30MW is dinky. Commercial power plants today run around a gigawatt.
It's going to hurt. It's going to be painful. But when you're losing a war, you have to take defensive steps that work.
What's needed is for someone like NY Attorney General Elliot Spitzer to charge Microsoft with reckless endangerment for knowingly, willfully, and negligently distributing and continuing to distribute systems vulnerable to such attacks.
Meanwhile, we may need some brutal firewalls:
We're probably going to see some companies going to a locked down firewall like that.
Tribe was bought by News Corp (Rupert Murdoch's company) a few months ago. He seems to have bought near the top. Many of the staff left. The recent site redesign (New! Web 2.0!) was something of a flop. Currently, the most active tribe seems to be "Tribe.net bug reports". Alexa traffic rankings show that Tribe.net peaked around January 2006. It's been downhill since. The current traffic level is about half the peak.
These things work like fads. Remember Nerve.com? Peaked in early 2002 at 4x the present level. They're still around, but nobody cares much.
There's a death spiral to these things. When traffic drops off, so does revenue. Then there's a frantic attempt to boost revenue by making the ads more intrusive, usually accompanied by layoffs. This drives away users.
Live by the click, die by the click.
The work that you shoot down so smugly for the academics is the basis of what is going into the hobbyists.
Actually, I'm more from the academic side. The US academic world is great at theory but terrible at bending metal. In fields where you need a few technicians per engineer, US academia does not cope well. (Except, historically, in high-energy physics, which does have several technicians per engineer, and in the biological sciences, which inherit the tradition of several flunkies per doctor.) You don't get tenure for making nice metal parts.
There are ways around this, usually involving teaming with some industrial partner. But the US has almost no robotics industry. So what we have are academic one-off designs that aren't suitable for volume replication.
The important site to look at is Robots Dreams, which covers Japanese robotics work. The little humanoid robots at the $1000 level are getting quite good mechanically. The best ones now have maybe 70% of the hardware functionality of Asimo at under 1% of the cost. They're typically remote controlled, but, because they have more degrees of freedom than a human can control with an R/C controller, preprogrammed movements were added. That wasn't good enough, so some hobbyists have added gyros and balance reflexes. Now it starts to get serious.
The hobbyists are doing some very good work. There are competitions and battles for these things. Obstacle courses which look like something from Army basic training. The battles aren't just banging away like Robot Wars; these machines can execute judo throws.
More to the point, the hobbyists are making progress much faster than the academic robotics people ever did. There are more of them, enough to drive a market for mass-produced parts. That makes it easier to build the things.
If you took the best kit humanoid available (which costs about $1200), added a 6DOF inertial unit (a few hundred dollars and getting cheaper every year), a stereo vision system (or even a SwissRanger minature LIDAR), better force sensors in the feet and hands, and a WiFi link, you'd have ASIMO-level capability for a few thousand dollars. We'll probably see that within two years, and probably at a low price point.
Then it's all software. And there's lots of theory out there just waiting to be used. This is going to be fun.
The reason this has been such a slow process is that SCO is the plaintiff, and they're stalling. Usually, the plaintiff, who initiated the case, is pushing the case forward, while the defendant tries to stall. This case is backwards.
But stalling only works for so long. SCO was able to drag out pretrial discovery for years. But now, discovery is over. No more surprises. No more "we'll disclose the evidence when the time comes" from SCO. That deadline has past. Now the pace picks up. Here's the final part of the case schedule, as set by the court:
Notice how the events come closer and closer together as the trial date approaches and the judge becomes more directly involved.
The next exciting moments will come in late November or early December, when the judge decides the summary judgement motions. SCO will then be worse off than they are now; the only question is how much worse off.
It's painful reading how that works. It's an achievement. "613 files changed." "It's the most complex kernel feature i ever worked on." But it's one of those things that, for legacy reasons, is much more complex and ugly than it should have been.
It's sad how much effort today goes into working around bad early design decisions. After writing drivers for QNX, where drivers are just user programs with a few extra privileges, it's painful to see the contortions people go through to do them in the more primitive operating systems. The basic problem is that the original UNIX driver model was a "top part", called from read and write calls, and a "bottom part", called from interrupt level. Today, Linux drivers tend to have some threads of their own, they're loadable, and the locking primitives are better, but the headaches of the legacy architecture remain.
The price of this is that drivers remain the biggest source of OS failure. OS developers pile hack on top of hack to try to fix this, the kernel gets bigger and bigger, and it still isn't airtight. Xen and Minix3 are starting to get it right. Drivers, even hardware drivers, are user programs in those operating systems.
I know, it's not going to get fixed for another generation. QNX is going nowhere because the company that now owns it is in the car stereo business. Minix 3 is still a toy. The Hurd people totally blew it. Mach gave microkernels a bad name. But this actually can be done right, and it takes less code to do it right than the mountain of patches needed to do it the hard way.
Linux has made major progress in the real-time area. But it still doesn't have everything needed.
Many drivers are still doing too much work at interrupt level. There are drivers that have been made safe for real time at the millisecond level, but that's not universal. Load a driver with long interrupt lockouts and your system isn't "real time" any more. This is the biggest problem in practice. There are too many drivers still around with long interrupt lockouts.
The Linux CPU dispatcher is now more real time oriented. (Finally!)
Interprocess communication in Linux is still kind of lame by real-time OS standards. The tight interaction between CPU dispatching and messaging still isn't there, although it's getting better. Interestingly, it's there in Minix 3, and of course, that's been in QNX for years. For simple real-time apps, though, this may not be an issue. Generally, though, if you find the need to use shared memory between processes, it's because your OS's messaging lacks something.
While Linux has been getting down to millisecond level response, QNX has been moving towards microsecond level response. The goal moves. However, millisecond response is good enough for most applications. What really matters in real-time, though, is worst-case response, not average. Benchmarks for real time OSs put a load on the system and measure how fast it responds to a few million interrupt requests. The number people look at is the longest response time.
Despite this, Linux is probably now good enough for most real-time applications that can tolerate a big kernel.
Microsoft has this annoying policy of putting some kind of general purpose execution engine in every Office product, from Word to PowerPoint to IE. Documents don't have to be Turing-complete, people. In fact, they're more useful if they're purely declarative - you can repurpose the content.
(Postscript is the classic bad example. The Postscript model is explicitly an interpreter. As a result, it's difficult to do anything with a Postscript document other than print it in the specified format. Text extraction is tough. Reliable format conversion is very tough. Reliable conversion to a different screen size, which ought to be easy, is terribly hard. Everybody moved away from Postscript, even Adobe. Microsoft should have learned from this.)
The sender knows who initially got the e-mail; that's the addressee. The main article was about tracking to whom the mail was forwarded. Forwarded copies will have the same image links as the original. So if the original recipient and the recipient of a forwarded copy both have anonymous image browsing, the original sender will know only that the message is being read again, but won't know from where.
Mail programs now need the option to retrieve images through an anonymizer.
Their site is fine now. Their equipment, though...
They're a surplus machinery dealer, and much of their equipment has seen hard use followed by neglect. The neglect is worse than the hard use. This lathe is a good example. That's a good Monarch precision lathe, but the picture, taken in 2000, shows considerable rust. Most of their gear is like that; it looks like it came out of an abandoned factory. It's repairable; you can send the lathe back to Monarch for an overhaul. But it's not good for much in its current condition. If there's any rust in the bearings, the precision is lost.
For comparison, see this Monarch Lathe on eBay. Made in 1950, and still in good shape. Those things will last a century if cared for.
If you have machinery like that around that's not in use, you have to oil it, then wrap it in plastic with some dessicant inside.
This is an underlying design/usability problem with Mediawiki and not necessarily Wikipedia itself. Building a proper database framework to be more encompassing (if not all encompassing - damn close) is a Citizendium design goal.
For most of the categories mentioned, the obvious tool for the job is a relatively conventional forms-driven database. Most proper names belong to some well understood category (people, places, companies, books, movies, songs, audio recordings), and those should be handled by some form-based input mechanism which captures the appropriate information for the category. In some cases, it may be possible to obtain data sources to populate or check the database entries. Such entries might also have an associated wiki-type free comment area, but the finding and linking mechanism would be more structured than that of a general wiki. As with IMDB and Gracenote, it should be possible to ask questions like "what films was this actor in" and get a useful result.
From the reader perspective, the output could look much like Wikipedia with subject matter templates. But from the editor perspective, it would be form-based for common article types. This allows for much more input validation. Disambiguation and spelling problems can be caught and corrected during input validation, rather than after the fact by someone else.
With proper names handled separately, the main less-structured wiki space becomes focused on more general concepts. This should reduce clutter substantially.
I'd definitely encourage a division between proper names and other material as a basic organizing concept. It's an easy to understand distinction.