This is a very bad thing. A "security" product should not allow downloading of software. This is even worse. It allows hidden downloading of software not visible to the user.
Supposedly it's delivered "turned off"? But how do you know it's turned off at startup? How do you know it wasn't turned on during operating system loading, or wasn't turned on by any of the preloaded crap that the "major PC manufacturers" preload? How do you know there isn't some way to turn it on remotely?
No computer with this software in ROM should be used for proprietary material, legal documents, medical records regulated by the HIPPA, financial records regulated by the SEC, or anything else that might attract an opponent. If you just play WoW, go ahead.
All they need are the usual restrictions for movie theaters. Tell students that carrying a cell phone is fine, but ringing has to be off while in class, and texting in class is a no-no.
That's enough to keep cell phones from interfering with the school's educational mission. Beyond that, as a Government body, the school has no business interfering.
There's something to be said for focusing on low-level survival issues, but one can do more than pontificate about it. As someone who's worked on legged locomotion control, I've made the point that a big part of life is about not falling down and not bumping into stuff. Unless you've got that working, not much else is going to work. Once you've got that working well, the higher level stuff can be added on gradually. This is bottom-up AI, as opposed to top-down AI.
Bottom-up AI is now mainstream, but it was once a radical concept. I went through Stanford at the height of the expert systems boom in the mid-1980s, when abstraction was king and the logicians were running the AI programs.
The "AI Winter" followed after they failed.
Rod Brooks made bottom-up AI semi-respectable, but he went off onto a purely reactive AI tangent, with little insect robots. That works, but it doesn't lead to more than insect-level AI. My comment on this was that it was a matter of the planning horizon for movement planning. Purely reactive systems have a planning horizon of zero. That works for insects, because they are small and light, and can just bang feelers into obstacles without harm.
As creatures get bigger and faster, they need a longer planning horizon. The minimum planning horizon for survival is your stopping distance. (This is explicit in autonomous vehicle work.)
Bigger and faster animals need better motion planners. This is probably what drove the evolution of the cerebellum, which is most of the brain in the mammals below the primates.
I've had horses for many years; I was on horseback an hour ago. Horses are interesting in this respect because they're big, fast, have very good short-term motion planning, but do little long-term planning. Horse brains have a big cerebellum and a small cortex, which is consistent with horse behavior. This gives a sense of what to aim for in bottom-up AI; good motion control, good vision, defer work on the higher level stuff until we have the low-level stuff nailed.
That's happening.
The DARPA Grand Challenge, especially the 2006 season with driving in traffic, forced some work on the beginnings of short term situational awareness. BigDog has some of the low-level motion control working really well, but BigDog isn't yet very good at picking footholds. They're just getting started on situational awareness. There's some good stuff going on in the game community, especially in programs that can play decent football. This problem is starting to crack.
Short-term planning in these areas revolves around making predictions about what's going to happen next. The ability to ask "what-if" questions about movement before trying them improves survival enormously. This kind of planning isn't combinatoric, like traditional AI planning systems. It's more like inverting a simulation to run it as a planner.
I have no idea how we get to "consciousness", but if we can get to horse-level AI, we're well into the mammal range. I encourage people to work on that problem. There's enough compute power to do this stuff now without beating head against wall on CPU time issues. There wasn't in the 1990s when I worked on this.
Google can't solve this problem because their business model requires web spam.
Google is in the advertising business, not the search business. Search is a traffic builder for the ads. Google's customers are their advertisers, not their search users. They have to maximize ad revenue. The problem is that more than a third of Google's advertisers are web spammers, broadly defined. All those "landing pages", typosquatters, spam blogs, and similar junk full of Google ads are revenue generators for Google. Every time someone clicks on an AdWords ad, Google makes money, no matter what slimeball is running the ad. Google can't crack down too hard, or their revenue will drop substantially. Google does have some standards, but they're low.
Google went over to the dark side around 2006. In 2004 and 2005, Google sponsored the Web Spam Summit, devoted to killing off web spammers. From 2006, Google sponsored the Search Engine Strategies conference, where the "search engine optimization" people meet. That was a big switch in direction, and a sad one.
As we demonstrate with SiteTruth, it's not that hard to get rid of most web spam if you're willing to be a hardass about requiring a legit business behind each commercial web site. Google can't afford to do that. It would hurt their bottom line.
However, cleaning up web search results with browser plug-ins is a viable option. Stay tuned.
I'm surprised that the TTY subsystem is still in the kernel. By now, it ought to be in
user space. It's rare today that a serial port is attached to an actual terminal
(let alone a real Teletype), and separating the serial port driver from all the
backspacing and line handling stuff would make both parts simpler. Most of the time,
the TTY stuff in the kernel just gets in the way of other uses of serial ports.
They've been separated in QNX for a decade, for example.
The fundamental property of spam is that it involves many similar messages going to a large number of destinations. That's what to look for. Google can do that, because they manage a very large number of mailboxes with a single system. SpamCop used to do that, but they had to be in the mail-forwarding business to do it and that was too expensive.
Trying to detect spam by looking only at the mail for a single account is inherently a form of guessing. The existing technologies are reasonably good, but not good enough that the spammers give up.
University Avenue in Palo Alto used to have a rather nice tea cafe, Neotte, with power outlets at every table and free WiFi. The place was packed with people with laptops. Several Web 2.0 startups were hatched there. But the customers didn't order much. A friend of mine worked there, and she was usually behind the counter reading a book. Even with the place full of customers, there weren't many orders for tea. The business concept was a flop.
The place converted to a coffee bar. Unfortunately, they were directly across the street from a Starbucks, so that didn't work. Now it's a Red Mango yogurt place, where people tend to buy and leave, not hang out.
Ordinary vacuum tubes do not remove electrons from inner orbitals. They just knock the valence electrons off. This process removes inner electrons without disturbing the outer ones.
Good point. That is a strange state in which to put an atom. If it was stable, that would be a major result. For 40 femtoseconds, no. What happens after that? Do the outer electrons migrate to the inner orbitals, or what?
short pulse from the FLASH laser 'knocked out' a core electron from every aluminum atom in a sample without disrupting the metal's crystalline structure. This turned the aluminum nearly invisible to extreme ultraviolet radiation. ..."Whilst the invisible effect lasted for only an extremely brief period - an estimated 40 femtoseconds..."
OK. so they took a really powerful soft X-ray pulse source and hammered an electron out of most of the atoms in a sample of aluminum. In 40 femtoseconds (!) the electrons were replaced, but for a brief period,
the material would pass "extreme ultraviolet radiation". This isn't a "new material"; it's an old material in a very transient state. They were able to do this without blasting the aluminum apart, which is the new result. On the other hand, metals can be forced into electron-deprived states without too much trouble. Ordinary vacuum tubes do this.
The terminology here is puzzling. "Extreme ultraviolet radiation" and "soft X-rays" are in the same part of the spectrum. Does this mean that after being zapped with the giant X-ray pulse, some of the soft X-rays made it through? Or did they have two different illumination sources?
That has a cert from DOD "CA-21"? I'd only been able to find certs for CA-5 through CA-18. How many CAs does DOD have? And how many does Firefox know about?
There's so much certificate misuse. A typical mistake is getting a cert for, say, "*.slashdot.org", and then serving it for "slashdot.org". That will cause a reject. Then there are U.S. Government certificate authorities, too many of them. Try, for example, USMC Doctrine Division. The CA is "DOD CA-13".
DoD alone has root CAs "CA-5", through "CA-18", and not all browsers know all of them.
This is a headache for SiteTruth, which uses certificates as a indication of web site validity and a source of business names and addresses. Only certs that are valid, using the Firefox cert file as authority, are accepted. There are more rejects than there should be.
The near term threat is not that robots will take over. It's that computers will take over most desk jobs.
The "singularity" in that area will come when organizations where the computers talk to each other work better than organizations where the people talk to each other. Computers network better than humans, and bureaucracies are dumber than their members.
We're already at the point where, in many offices, everything important comes in and goes out over a wire and passes through a few computers. The humans are just slowing down the processing. That's going to continue, and that's where AI will be applied to handle more and more of the hard cases.
Humans will be relegated to more productive tasks in the lower levels. Plumbing, HVAC repair, roofing. Stuff like that.
San Francisco used to have a Microsoft Store at the Metreon, an "urban entertainment destination", back when Sony ran the building. It seemed to be aimed at "road warrior" types, which, since the San Francisco Convention Center is next door, made sense. Machines were set up for playing some of
Microsoft's PC games like "Train Simulator". Microsoft boxed software products were sold. A group training room was used for corporate training and presentations. Not very exciting, but modestly useful.
Sony kicked them out when Microsoft introduced the XBox and became a Sony competitor.
The building has a Sony Style store and a Playstation store, so having an XBox store in the same building was too much for Sony.
The Metreon has been going steadily downscale for years. The Sony Style store seems out of place, as well as being cluttered with older high-end Sony TV products that cost 3x current prices. The Microsoft store was replaced by a store that sold miscellaneous electronics for travelers, including a vending machine for iPods. That went bust, and after a long vacancy was replaced with an arcade of crane games. Not a video arcade; just crane games, about twenty of them in one room. The cute exhibits, like The Way Things Work and Where the Wild Things Are, are long gone. The original video game arcade, the Airtight Garage, with custom-designed games and exotic decor, is gone. What remains is a dying mall with movie theaters, run by some low-rent mall operator and badly maintained.
and with current funding, most AI research is what can be done by a graduate student in his 3 years to get a thesis. Thats leads to a lot of small projects, done just well enough and very little reuse. Until researchers and programmers start working in mass to construct AI machines, Artificial Intelligence is going progress very slowly.
Yes. That's the way it was for decades in robotics. Projects were a professor and 3-5 grad students. Projects took forever, and produced more theses than hardware.Then came Dr. Tony Tether at DARPA.
Tether decided that robotics needed a serious butt-kick. So he came up with the DARPA Grand Challenge. Originally, AI researchers didn't take the Grand Challenge seriously; for the first eight months after the announcement, none of the usual DARPA-funded research institutions entered. The word was then passed around quietly that if outside entrants did better than the universities DARPA had been funding for decades, DARPA was going to pull the plug on the unsuccessful university groups. Suddenly there were teams from CMU, Stanford, Caltech, MIT, etc. Big teams. CMU had over 50 people. Ohio State had over 100. Teams were heavily funded with industrial support. CMU was supported by Caterpillar; Stanford was supported by Volkswagen, with serious technical support. Underperforming faculty members at the big schools were pushed out of the way to get results.
At last, there was enough support to get hardware and components built and working fast, at the speeds normally seen in industrial product development. It worked; in four years, multiple robot vehicles were driving in traffic. Along the way, components became much better. In 2002, a high-precision GPS/INS/odometery/compass navigation unit needed 4U of rack space and air conditioning. By 2005, it was the size of a large book. Much better LIDAR scanners were developed. Computer vision for driving took a big step forward. The mechanics of controlling a full-sized vehicle went from a tough problem to a routine one.
DARPA is continuing in that mode. BigDog has cost $23 million to date, and it works well enough to be used on field trials at Army and Marine bases. Robotics is now far enough along that throwing money at it and insisting on results works.
The trouble with this approach is that as soon as the money stops, so does progress. Nobody has done much interesting with autonomous vehicles since 2006, when the last Grand Challenge ended. No one has yet found a profitable autonomous vehicle application.
What worries me is a truck-mounted EMP generator deployed in the Wall Street area.
In today's financial markets, if Wall Street went down for a week, when it came back up, New York would no longer be the center of the financial universe.
Scheme is a good first language for MIT students. All incoming MIT freshmen already have mathematical thinking down cold, or they were filtered out by Admissions early on. So Scheme makes sense to that crowd.
For high school students, I'd start with Python. Python has most of the good ideas in modern programming, it has reasonable aesthetics, and you can do a wide range of things, although somewhat slowly. Perl is too ugly and is bad for young minds. C/C++ forces you to deal too much with memory allocation. Java is OK. The more exotic languages are for later.
There are a few schools that teach Forth, because you get to see the whole range from high level programming down to the hardware level. But it's too limiting, and dated.
Rushmoredrive.com Niche search engine for black people. Ceased operations a few weeks ago.
So you can see where Diller is coming from. His ad-based businesses have been disasters, while his transaction-charge businesses have done well. (Lending Tree had some bad years because they speculated in mortgages, instead of just brokering them.)
I've been wondering about "image ATMs", which accept checks for deposit, imaging them. I've had one correctly accept a check with the amount handwritten in cursive. I suspect that at least the hard cases are being referred to humans for recognition.
There are books on this stuff. "Patent It Yourself", by David Pressman, has long sections on how to tell if your idea is worth pursuing.
The two big questions are 1) has it been done, and 2) is there demand for it.
Even if it's been done before, it may be worth doing again, but you should find out how things went last time.
There are different kinds of ideas. There are solutions to known problems; areas where others have tried and failed to develop a solution. Those are typically hard to do, but easy to sell if your solution works. There are "new cool things", which are more of a marketing issue than an implementation issue. (Apple didn't sell the first MP3 player.) There are new kinds of businesses; FedEx and NetJets are successful examples. Webvan is an unsuccessful example. (WebVan wasn't a bad idea; their problem was that they botched the growth strategy. They needed 30% market penetration in 3 markets to get economies of distribution; they got 3% market penetration in 30 markets.)
Some years ago, the C++ committee went off into template la-la land. Most of the work there focuses on template features that will be used by few, and used correctly by fewer.
Templates are useful, but "generic programming", doing arbitrary computation at compile time with templates, was a terrible idea. Templates can be abused as a recursive term-rewriting system, and through some clever and obscure tricks, recursive computations can be run at compile time. As a programming language, this trick is awful; awful from a syntax point of view, awful from an understandability point of view, and awful from a debugging point of view. If you need to do work at compile time, there have been much better approaches. LISP "macros" were standard LISP, not a second language. And even they created such a mess that Scheme had to be invented to clean out the language.
Orignally, templates were conceived as a saner way to do what C programmers did with macros, providing a way to have some type independence at compile time. But the template crowd got out of control.
The obsession with templates has led to a neglect of things C++ really needed, like better memory safety (C++ still has buffer overflows, and most of the security holes today stem from this), and better approaches to concurrency (the compiler has no idea what locks what, and it needs to know). Anything that wasn't template-related tended to be ignored by the committee.
The result of this failure has been C++ spinoffs - Java, C#, etc. Even Objective C has made a comeback in the Apple world. C++ has never even been able to displace C, twenty years on.
I've written a lot of C++, and I'm disgusted with this mess.
It probably is within reach to build a hardware equivalent of a human brain. We don't know how to architect it, but building enough custom ICs and interconnecting them is probably within reach. The right architecture for simulating neurons probably involves some huge number of fast processors with limited memory, like a graphics board.
I'm encouraged that this guy is trying to model a mouse brain. About twenty years ago, I was at a seminar by Rod Brooks. He was talking about trying to jump from insect-level AI, where he'd made some progress, to human-level AI. I asked him why he was trying to make such a big jump; a mouse brain might be within reach. He said "Because I don't want to go down in history as the person who created the world's greatest robot mouse". So instead, Brooks did Cog, a stationary robot with head and arms which tries to fake acting human and didn't really lead anywhere. Taking a smaller step might work better.
Reaching for mouse-level AI is promising. Mice and humans have about 85% DNA commonality. All the mammals seem to have have roughly similar brain components, although the size ratios of the different sections vary widely. Humans have about 1000x the brain mass of a mouse. So if we can get a solid simulation of a mouse brain, it may be mostly a scaleup from there.
The classic mistake in AI is that someone comes up with a reasonable idea, and then thinks they're one step from human-level AI. That's approaching the problem as if it were easy. Fifty years in, we can now conclude it is hard. So taking smaller bites is indicated.
When we build an artificial brain, it will be rack-mounted in 19 inch racks.
I'll believe this when I see more sites that start dropping unnecessary ads and tracking when under heavy load. (Slashdot does some of that; under heavy load, most users get a canned home page. When the system is less busy, the "customization" machinery is used.)
The real killer is overdoing "customization". Customization makes serving pages far more expensive. Consider Google's problems with "Michael Jackson" searches. Google used to answer the most common queries from a cache in the first server to which the client connected, without actually going to the big search engine in back. That makes it
very cheap to answer huge numbers of similar queries. But "customization" breaks that; now every search has to pull up the user's profile and rework the output.
Slashdot Mirror
The lead author is on the faculty at USC. By the same author:
There's much more like this. The papers are competent but mediocre.
This is a very bad thing. A "security" product should not allow downloading of software. This is even worse. It allows hidden downloading of software not visible to the user.
Supposedly it's delivered "turned off"? But how do you know it's turned off at startup? How do you know it wasn't turned on during operating system loading, or wasn't turned on by any of the preloaded crap that the "major PC manufacturers" preload? How do you know there isn't some way to turn it on remotely?
No computer with this software in ROM should be used for proprietary material, legal documents, medical records regulated by the HIPPA, financial records regulated by the SEC, or anything else that might attract an opponent. If you just play WoW, go ahead.
All they need are the usual restrictions for movie theaters. Tell students that carrying a cell phone is fine, but ringing has to be off while in class, and texting in class is a no-no. That's enough to keep cell phones from interfering with the school's educational mission. Beyond that, as a Government body, the school has no business interfering.
There's something to be said for focusing on low-level survival issues, but one can do more than pontificate about it. As someone who's worked on legged locomotion control, I've made the point that a big part of life is about not falling down and not bumping into stuff. Unless you've got that working, not much else is going to work. Once you've got that working well, the higher level stuff can be added on gradually. This is bottom-up AI, as opposed to top-down AI.
Bottom-up AI is now mainstream, but it was once a radical concept. I went through Stanford at the height of the expert systems boom in the mid-1980s, when abstraction was king and the logicians were running the AI programs. The "AI Winter" followed after they failed.
Rod Brooks made bottom-up AI semi-respectable, but he went off onto a purely reactive AI tangent, with little insect robots. That works, but it doesn't lead to more than insect-level AI. My comment on this was that it was a matter of the planning horizon for movement planning. Purely reactive systems have a planning horizon of zero. That works for insects, because they are small and light, and can just bang feelers into obstacles without harm.
As creatures get bigger and faster, they need a longer planning horizon. The minimum planning horizon for survival is your stopping distance. (This is explicit in autonomous vehicle work.) Bigger and faster animals need better motion planners. This is probably what drove the evolution of the cerebellum, which is most of the brain in the mammals below the primates.
I've had horses for many years; I was on horseback an hour ago. Horses are interesting in this respect because they're big, fast, have very good short-term motion planning, but do little long-term planning. Horse brains have a big cerebellum and a small cortex, which is consistent with horse behavior. This gives a sense of what to aim for in bottom-up AI; good motion control, good vision, defer work on the higher level stuff until we have the low-level stuff nailed.
That's happening. The DARPA Grand Challenge, especially the 2006 season with driving in traffic, forced some work on the beginnings of short term situational awareness. BigDog has some of the low-level motion control working really well, but BigDog isn't yet very good at picking footholds. They're just getting started on situational awareness. There's some good stuff going on in the game community, especially in programs that can play decent football. This problem is starting to crack.
Short-term planning in these areas revolves around making predictions about what's going to happen next. The ability to ask "what-if" questions about movement before trying them improves survival enormously. This kind of planning isn't combinatoric, like traditional AI planning systems. It's more like inverting a simulation to run it as a planner.
I have no idea how we get to "consciousness", but if we can get to horse-level AI, we're well into the mammal range. I encourage people to work on that problem. There's enough compute power to do this stuff now without beating head against wall on CPU time issues. There wasn't in the 1990s when I worked on this.
Google can't solve this problem because their business model requires web spam.
Google is in the advertising business, not the search business. Search is a traffic builder for the ads. Google's customers are their advertisers, not their search users. They have to maximize ad revenue. The problem is that more than a third of Google's advertisers are web spammers, broadly defined. All those "landing pages", typosquatters, spam blogs, and similar junk full of Google ads are revenue generators for Google. Every time someone clicks on an AdWords ad, Google makes money, no matter what slimeball is running the ad. Google can't crack down too hard, or their revenue will drop substantially. Google does have some standards, but they're low.
Google went over to the dark side around 2006. In 2004 and 2005, Google sponsored the Web Spam Summit, devoted to killing off web spammers. From 2006, Google sponsored the Search Engine Strategies conference, where the "search engine optimization" people meet. That was a big switch in direction, and a sad one.
As we demonstrate with SiteTruth, it's not that hard to get rid of most web spam if you're willing to be a hardass about requiring a legit business behind each commercial web site. Google can't afford to do that. It would hurt their bottom line.
However, cleaning up web search results with browser plug-ins is a viable option. Stay tuned.
I'm surprised that the TTY subsystem is still in the kernel. By now, it ought to be in user space. It's rare today that a serial port is attached to an actual terminal (let alone a real Teletype), and separating the serial port driver from all the backspacing and line handling stuff would make both parts simpler. Most of the time, the TTY stuff in the kernel just gets in the way of other uses of serial ports.
They've been separated in QNX for a decade, for example.
The fundamental property of spam is that it involves many similar messages going to a large number of destinations. That's what to look for. Google can do that, because they manage a very large number of mailboxes with a single system. SpamCop used to do that, but they had to be in the mail-forwarding business to do it and that was too expensive.
Trying to detect spam by looking only at the mail for a single account is inherently a form of guessing. The existing technologies are reasonably good, but not good enough that the spammers give up.
University Avenue in Palo Alto used to have a rather nice tea cafe, Neotte, with power outlets at every table and free WiFi. The place was packed with people with laptops. Several Web 2.0 startups were hatched there. But the customers didn't order much. A friend of mine worked there, and she was usually behind the counter reading a book. Even with the place full of customers, there weren't many orders for tea. The business concept was a flop.
The place converted to a coffee bar. Unfortunately, they were directly across the street from a Starbucks, so that didn't work. Now it's a Red Mango yogurt place, where people tend to buy and leave, not hang out.
Ordinary vacuum tubes do not remove electrons from inner orbitals. They just knock the valence electrons off. This process removes inner electrons without disturbing the outer ones.
Good point. That is a strange state in which to put an atom. If it was stable, that would be a major result. For 40 femtoseconds, no. What happens after that? Do the outer electrons migrate to the inner orbitals, or what?
short pulse from the FLASH laser 'knocked out' a core electron from every aluminum atom in a sample without disrupting the metal's crystalline structure. This turned the aluminum nearly invisible to extreme ultraviolet radiation.
..."Whilst the invisible effect lasted for only an extremely brief period - an estimated 40 femtoseconds..."
OK. so they took a really powerful soft X-ray pulse source and hammered an electron out of most of the atoms in a sample of aluminum. In 40 femtoseconds (!) the electrons were replaced, but for a brief period, the material would pass "extreme ultraviolet radiation". This isn't a "new material"; it's an old material in a very transient state. They were able to do this without blasting the aluminum apart, which is the new result. On the other hand, metals can be forced into electron-deprived states without too much trouble. Ordinary vacuum tubes do this.
The terminology here is puzzling. "Extreme ultraviolet radiation" and "soft X-rays" are in the same part of the spectrum. Does this mean that after being zapped with the giant X-ray pulse, some of the soft X-rays made it through? Or did they have two different illumination sources?
Also see "Extreme Ultraviolet Radiation Transport in Laser-Irradiated High-Z Metal Foils", from 1981, where someone seems to have come close to the same phenomenon.
FlashBlock stops Flash from running after a second or two. Some of the remote code still runs. This may be enough time for an attack to get through.
Here: https://www.dmdc.osd.mil/scra/owa/home
That has a cert from DOD "CA-21"? I'd only been able to find certs for CA-5 through CA-18. How many CAs does DOD have? And how many does Firefox know about?
There's so much certificate misuse. A typical mistake is getting a cert for, say, "*.slashdot.org", and then serving it for "slashdot.org". That will cause a reject. Then there are U.S. Government certificate authorities, too many of them. Try, for example, USMC Doctrine Division. The CA is "DOD CA-13". DoD alone has root CAs "CA-5", through "CA-18", and not all browsers know all of them.
This is a headache for SiteTruth, which uses certificates as a indication of web site validity and a source of business names and addresses. Only certs that are valid, using the Firefox cert file as authority, are accepted. There are more rejects than there should be.
The near term threat is not that robots will take over. It's that computers will take over most desk jobs. The "singularity" in that area will come when organizations where the computers talk to each other work better than organizations where the people talk to each other. Computers network better than humans, and bureaucracies are dumber than their members.
We're already at the point where, in many offices, everything important comes in and goes out over a wire and passes through a few computers. The humans are just slowing down the processing. That's going to continue, and that's where AI will be applied to handle more and more of the hard cases.
Humans will be relegated to more productive tasks in the lower levels. Plumbing, HVAC repair, roofing. Stuff like that.
L0pht Heavy Industries went corporate in 2000, and became "@Stake", which was acquired by Symantec in 2004, and disappeared into the Symantec empire.
L0pht, founded in 1992, was itself a descendant of the Cult of the Dead Cow, founded in 1984 and still around, more or less.
There have been various spinoffs and buybacks along the way, but it's been a while since cutting edge work came from that crowd.
San Francisco used to have a Microsoft Store at the Metreon, an "urban entertainment destination", back when Sony ran the building. It seemed to be aimed at "road warrior" types, which, since the San Francisco Convention Center is next door, made sense. Machines were set up for playing some of Microsoft's PC games like "Train Simulator". Microsoft boxed software products were sold. A group training room was used for corporate training and presentations. Not very exciting, but modestly useful.
Sony kicked them out when Microsoft introduced the XBox and became a Sony competitor. The building has a Sony Style store and a Playstation store, so having an XBox store in the same building was too much for Sony.
The Metreon has been going steadily downscale for years. The Sony Style store seems out of place, as well as being cluttered with older high-end Sony TV products that cost 3x current prices. The Microsoft store was replaced by a store that sold miscellaneous electronics for travelers, including a vending machine for iPods. That went bust, and after a long vacancy was replaced with an arcade of crane games. Not a video arcade; just crane games, about twenty of them in one room. The cute exhibits, like The Way Things Work and Where the Wild Things Are, are long gone. The original video game arcade, the Airtight Garage, with custom-designed games and exotic decor, is gone. What remains is a dying mall with movie theaters, run by some low-rent mall operator and badly maintained.
and with current funding, most AI research is what can be done by a graduate student in his 3 years to get a thesis. Thats leads to a lot of small projects, done just well enough and very little reuse. Until researchers and programmers start working in mass to construct AI machines, Artificial Intelligence is going progress very slowly.
Yes. That's the way it was for decades in robotics. Projects were a professor and 3-5 grad students. Projects took forever, and produced more theses than hardware.Then came Dr. Tony Tether at DARPA.
Tether decided that robotics needed a serious butt-kick. So he came up with the DARPA Grand Challenge. Originally, AI researchers didn't take the Grand Challenge seriously; for the first eight months after the announcement, none of the usual DARPA-funded research institutions entered. The word was then passed around quietly that if outside entrants did better than the universities DARPA had been funding for decades, DARPA was going to pull the plug on the unsuccessful university groups. Suddenly there were teams from CMU, Stanford, Caltech, MIT, etc. Big teams. CMU had over 50 people. Ohio State had over 100. Teams were heavily funded with industrial support. CMU was supported by Caterpillar; Stanford was supported by Volkswagen, with serious technical support. Underperforming faculty members at the big schools were pushed out of the way to get results.
At last, there was enough support to get hardware and components built and working fast, at the speeds normally seen in industrial product development. It worked; in four years, multiple robot vehicles were driving in traffic. Along the way, components became much better. In 2002, a high-precision GPS/INS/odometery/compass navigation unit needed 4U of rack space and air conditioning. By 2005, it was the size of a large book. Much better LIDAR scanners were developed. Computer vision for driving took a big step forward. The mechanics of controlling a full-sized vehicle went from a tough problem to a routine one.
DARPA is continuing in that mode. BigDog has cost $23 million to date, and it works well enough to be used on field trials at Army and Marine bases. Robotics is now far enough along that throwing money at it and insisting on results works.
The trouble with this approach is that as soon as the money stops, so does progress. Nobody has done much interesting with autonomous vehicles since 2006, when the last Grand Challenge ended. No one has yet found a profitable autonomous vehicle application.
What worries me is a truck-mounted EMP generator deployed in the Wall Street area.
In today's financial markets, if Wall Street went down for a week, when it came back up, New York would no longer be the center of the financial universe.
(Of course, that's going to happen anyway; a debtor nation can't control the world financial system for long. China is shortening the maturity on its 2.1 trillion in Treasury paper and starting to buy real assets, mostly natural resources.)
Scheme is a good first language for MIT students. All incoming MIT freshmen already have mathematical thinking down cold, or they were filtered out by Admissions early on. So Scheme makes sense to that crowd.
For high school students, I'd start with Python. Python has most of the good ideas in modern programming, it has reasonable aesthetics, and you can do a wide range of things, although somewhat slowly. Perl is too ugly and is bad for young minds. C/C++ forces you to deal too much with memory allocation. Java is OK. The more exotic languages are for later.
There are a few schools that teach Forth, because you get to see the whole range from high level programming down to the hardware level. But it's too limiting, and dated.
Let's look at the record of Barry Diller companies.
So you can see where Diller is coming from. His ad-based businesses have been disasters, while his transaction-charge businesses have done well. (Lending Tree had some bad years because they speculated in mortgages, instead of just brokering them.)
I've been wondering about "image ATMs", which accept checks for deposit, imaging them. I've had one correctly accept a check with the amount handwritten in cursive. I suspect that at least the hard cases are being referred to humans for recognition.
There are books on this stuff. "Patent It Yourself", by David Pressman, has long sections on how to tell if your idea is worth pursuing.
The two big questions are 1) has it been done, and 2) is there demand for it. Even if it's been done before, it may be worth doing again, but you should find out how things went last time.
There are different kinds of ideas. There are solutions to known problems; areas where others have tried and failed to develop a solution. Those are typically hard to do, but easy to sell if your solution works. There are "new cool things", which are more of a marketing issue than an implementation issue. (Apple didn't sell the first MP3 player.) There are new kinds of businesses; FedEx and NetJets are successful examples. Webvan is an unsuccessful example. (WebVan wasn't a bad idea; their problem was that they botched the growth strategy. They needed 30% market penetration in 3 markets to get economies of distribution; they got 3% market penetration in 30 markets.)
Which kind of idea is yours?
Some years ago, the C++ committee went off into template la-la land. Most of the work there focuses on template features that will be used by few, and used correctly by fewer.
Templates are useful, but "generic programming", doing arbitrary computation at compile time with templates, was a terrible idea. Templates can be abused as a recursive term-rewriting system, and through some clever and obscure tricks, recursive computations can be run at compile time. As a programming language, this trick is awful; awful from a syntax point of view, awful from an understandability point of view, and awful from a debugging point of view. If you need to do work at compile time, there have been much better approaches. LISP "macros" were standard LISP, not a second language. And even they created such a mess that Scheme had to be invented to clean out the language.
Orignally, templates were conceived as a saner way to do what C programmers did with macros, providing a way to have some type independence at compile time. But the template crowd got out of control.
The obsession with templates has led to a neglect of things C++ really needed, like better memory safety (C++ still has buffer overflows, and most of the security holes today stem from this), and better approaches to concurrency (the compiler has no idea what locks what, and it needs to know). Anything that wasn't template-related tended to be ignored by the committee.
The result of this failure has been C++ spinoffs - Java, C#, etc. Even Objective C has made a comeback in the Apple world. C++ has never even been able to displace C, twenty years on.
I've written a lot of C++, and I'm disgusted with this mess.
It probably is within reach to build a hardware equivalent of a human brain. We don't know how to architect it, but building enough custom ICs and interconnecting them is probably within reach. The right architecture for simulating neurons probably involves some huge number of fast processors with limited memory, like a graphics board.
I'm encouraged that this guy is trying to model a mouse brain. About twenty years ago, I was at a seminar by Rod Brooks. He was talking about trying to jump from insect-level AI, where he'd made some progress, to human-level AI. I asked him why he was trying to make such a big jump; a mouse brain might be within reach. He said "Because I don't want to go down in history as the person who created the world's greatest robot mouse". So instead, Brooks did Cog, a stationary robot with head and arms which tries to fake acting human and didn't really lead anywhere. Taking a smaller step might work better.
Reaching for mouse-level AI is promising. Mice and humans have about 85% DNA commonality. All the mammals seem to have have roughly similar brain components, although the size ratios of the different sections vary widely. Humans have about 1000x the brain mass of a mouse. So if we can get a solid simulation of a mouse brain, it may be mostly a scaleup from there.
The classic mistake in AI is that someone comes up with a reasonable idea, and then thinks they're one step from human-level AI. That's approaching the problem as if it were easy. Fifty years in, we can now conclude it is hard. So taking smaller bites is indicated.
When we build an artificial brain, it will be rack-mounted in 19 inch racks.
I'll believe this when I see more sites that start dropping unnecessary ads and tracking when under heavy load. (Slashdot does some of that; under heavy load, most users get a canned home page. When the system is less busy, the "customization" machinery is used.)
The real killer is overdoing "customization". Customization makes serving pages far more expensive. Consider Google's problems with "Michael Jackson" searches. Google used to answer the most common queries from a cache in the first server to which the client connected, without actually going to the big search engine in back. That makes it very cheap to answer huge numbers of similar queries. But "customization" breaks that; now every search has to pull up the user's profile and rework the output.