The last nail in the coffin came, of all places, from Apple. Thanks to OS X, Apple has come back from the dead in a way that is extremely rare in technology. Their victory is so complete that I'm now surprised when I come across a computer running Windows.
Uh, Apple desktop market share is still somewhere well under 10%. Has this guy been drug tested lately?
Actually, the big threat to Microsoft is OpenOffice. Office is where Microsoft makes its money. Putting Linux on a computer doesn't hurt Microsoft; they've already been paid by the computer maker. Installing OpenOffice instead of Microsoft Office comes directly out of Microsoft's profits. The web stuff gets all the press attention, but that's not where the money is.
"Protected processes" are a reasonable idea. They're certainly better than putting video and audio processing in the kernel as part of the DRM system. But apparently Microsoft botched the implementation.
Microsoft has for some years allowed processes to do too much to other processes. Things like "injecting" a DLL or thread into a running process from the outside, or "hooking" system calls, are inherently security problems. In the Windows world, normal processes can do that to each other. This tends to be overdone, with too much "hooking" of system calls and such, a tradition from the DOS era. The UNIX/Linux world doesn't have that tradition. Fortunately.
If we have to have DRM, protected processes aren't a bad idea. But what you want is for them to be compartmented, not privileged. They should be running in a compartment which prevents other processes from attaching to them, but they don't need the privilege of attaching to other processes. So the video decoder can be protected, but doesn't have enough privileges to act as an aimbot for some game. The security system for a game should be able to lock the game processes into a compartment which other processes cannot enter, preventing cheats. Enforce separation, not privilege.
This won't be the first US commercial spaceport.
Mojave Spaceport has been active for several years now. SpaceShip One launched from there.
Rotary Rocket was supposed to launch their SSTO vehicle from Mojave, and built a vertical assembly building and a prototype at Mojave. But they had a weight growth problem and never got beyond low-altitude testing.
It's in response to a Microsoft move.
on
1-800-Google Launches
·
· Score: 5, Informative
It's their answer to Microsoft's acquisition of TellMe. (1-800-555-TELL). Presumably, like TellMe, after a while they will add ads.
As usual, we have dig past all the blogodreck to get to the source material. And, as is typical of third-rate bloggers, there's no link to the original source.
The "100 year vision" policy document they're quoting is speech by Wen Jiabao, addressed to the Communist Party of China, which he heads. The blog article attaches importance to the line "China is at the primary stage of socialism, and will remain so for a long time to come." That's a quote from the Chinese constitution. That line was changed back in 1993, which reflected some economic liberalization. Jiabao is making the point that there's no policy change. Overall, it's a "stay the course" speech; the current course is working.
As an old programmer, I'm not too impressed with that advice.
It's important today for a programmer to understand how top management thinks. Read the Wall Street Journal and the Economist. After about a year, both will start to make sense, as it takes about that long for all the major subjects to come around once or twice. Eventually, you'll probably want to move into management.
I'm not sure how much low-level knowledge really matters today. I understand what's going on down to the level of what happens in the wafer fab, but that's more because I'm in Silicon Valley. Understanding programming at the C level, definitely. At the machine code level, that may be too much detail to learn. A general notion of modern CPU architecture is useful; you should understand what caches do, why cache misses kill performance, and the implications of this at the program level. Detail beyond that level probably won't help you much. Understanding how an adder works is irrelevant to programming today.
It's probably more important to understand networking in some detail. Understanding Ethernet, DNS, WiFi, TCP, PPPoE, etc. is necessary, because they all can give trouble and you may have to diagnose that trouble.
I have to agree about the long-term value of UNIX knowledge vs. Microsoft-related knowledge. I first used UNIX in 1978, and programming on it has changed surprisingly little since then. We still have "make", we still have source control with check-in and check-out, and we still have a command line. And it doesn't go away. Since first using UNIX, I've used a half dozen other systems, most of them now defunct. Some were better. I keep getting forced back to UNIX, because it's still there after the others go away.
Asking for code samples from job applicants doesn't seem to work. A few years ago, I was asking for "a thousand lines of C++ code you're proud of." Few programmers could come up with much. Reading the code was sometimes painful. I sent one back with the note: "Your first buffer overflow is on line 22. Thank you for your interest."
Learning new programming languages isn't that hard, once you've learned a few different ones. What takes a long time is learning the quirks of a library. Today, each programming language comes with an library API with a few thousand objects and calls, some of which work reasonably. Finding out about the ones that don't is the most time-consuming part of learning a new environment today. This has led to a "ritual/taboo" style of programming, where huge books give sequences of code ("incantations") known to work, rather than development from first principles. This is the main source of career lock-in today. Be aware of that.
All those buzzwords. Apparently somebody has a system that can characterize and match images and video. That's reasonable enough, it's been done before, and the question is how good the new one is. The article gives zero help in that direction.
From the same source: "Nanogenerator provides continuous power by harvesting energy from the environment". It's a variation on the piezoelectric generator concept, like a piezo fire starter.
This article is yet another "we have a new chemistry and it's gonna be really cheap real soon now" article. Here's the real deal in solar power.
Yesterday, Mark Pinto from Applied Materials gave a talk in EE380 at Stanford on where they're going. Applied Materials is the biggest maker of semiconductor fab equipment, and they've branched out into making fab equipment for display panels and then solar cells.
To get costs down for big flat panel displays is a manufacturing technology problem. Applied Materials went at it in typical semiconductor-fab fashion - scaling up the fab size. They're now making panels of about 5 square meters in area. These are then cut up into 50-inch TV sets.
Once they got that working, they adapted the huge machinery involved to making solar panels. This turned out to work quite well. Since they're adapting a process that produces higher-quality product than a solar cell, they don't have significant quality problems. The solar-cell only makers tend to have spotty quality; he pointed out that with some solar panels, not all the cells are exactly the same color, which indicates trouble in the coating process.
With size and quality working, the next step is volume. They're about to build the first "40 megawatt fab", one that produces in a year enough solar panels to generate 40 megawatts. These are big panels, 2.2m x 2.6m. The price of the electricity produced should be just about even with peak-hour energy costs in Spain, where this is going.
Energy payback (when you get more energy out than was required to make the panel) is about two years. That plant comes on line in 2008.
The next step is the "gigawatt fab", a scale-up of that plant. This is part of Applied Materials' "Solar Strategy". Their position is that the technology is here; it's just necessary to get it into volume production, real volume production. Which is what Applied Materials is good at.
Now we're talking about serious production volume. Three or four such plants could build enough solar cells to cover Southern California's air conditioning energy load in five years.
Meanwhile, they have investments in some other technologies, including a "roll to roll" flexible solar cell technology, and some exotic ideas like tinted glass windows that also generate power. But they don't need a breakthrough. The current technology is good enough to be profitable, so they can start making product and shipping it in volume, while research proceeds on lowering the cost further. Pinto pointed out that about half the cost of solar power is now installation, and that needs to move beyond "a guy with a pickup truck".
So that's what's really happening. Big machines in big factories built by big companies cranking out big solar panels in big volume. Which is how you solve big problems.
The site they're writing about, found by searching with Google for phrases in the article, isn't quite what the article says it is.
It's really yet another slimy "affiliate" program. "We give our code to your and you need to setup it to your websites. We pay for installs and for trusted webmasters for traffic if they want that." They're not selling malware with support. They're buying traffic to install their malware via drive-by installs. That's not exactly new. CometCursor, BonzaiBuddy, and Zango come to mind.
From the original article, someone else may be selling "fully managed exploit engines", but it's not these guys.
because most of the things around his office were protected by copyright.
You can't copyright a functional mechanical part. That's why there's a third-party auto parts industry. The author of the original article (free link) apparently has a desk full of promotional items, some of which might be copyrighted designs. That's the only reason he has copyright problems.
The article is really just a product review of a low-end 3D scanner. Not a very good one. Sounds worse than the low-end Roland scanners.
3D prototyping is still an expensive way to make mediocre parts. Most of the people enthused about it don't really have a clue about how manufactured goods are made. Making homogeneous solid objects in quantity is an incredibly cheap operation.
The real breakthrough with this technology is making objects with internal structure. The gecko robots from Stanford are made by loading up a stereolithography machine with several materials of different properties (flexible, stiff, conductive, insulating...) and building something that's almost organic in nature.
The Apple Lisa was a very nice machine, with a multitasking operating system, 1MB of protected-mode memory, a hard disk, and some decent applications. You could get work done on a Lisa. It just cost too much.
The original Macintosh, with 128K of RAM, one floppy, no hard drive, no memory protection, and a single-tasking operating system, was really an expensive toy. I've actually used one, and it wasn't fun. Most of the time you either waited for the machine or were swapping diskettes.
Not until the Macintosh was built up to Lisa levels of hardware was it useful. Once it got 512K, a hard drive, and the LaserWriter, it was a useful machine for designers.
But that was several years later. The state of the art in hardware just wasn't up to a useful GUI machine at an affordable price until about 1985-1986.
(Bear in mind that, well before the Mac launched, you could buy a Sun UNIX workstation with a 19-inch display and networking for about $20K. And Sun wasn't even the first; Apollo shipped even earlier. The problem was getting the cost down.)
The Segway has to have been one of the most overhyped products of all time. When it was finally revealed on some TV show, the host said "That's it?".
It's a beautiful piece of technology. The last piece of consumer mechanical engineering with that much originality was the Polaroid SX-70.
But it's a demonstration that if you throw enough money at the wrong problem, you can solve it.
The x86 instruction set is a surprisingly good way to build a computer. The reasons aren't obvious.
First, the original x86 was a huge pain, with that stupid segmented memory arrangement. But IA-32 was better and cleaner; at last there was a flat 32-bit address space. (Yes, there's a segmented 48-bit mode, and Linux even supports it, but at least apps see a flat address space.) AMD-64 is even more regular; the segmented memory stuff is completely gone in 64 bit mode. So there is progress.
RISC architectures could yield simple machines that could execute one simple fixed-width instruction per clock cycle. The early DEC Alphas, the MIPS machines, and early IBM Power chips are examples of straightforward RISC machines. This looked like a big win. The ALU was simple, design teams were small (one midrange MIPS CPU was designed by about six people), and debugging wasn't hard.
RISC looked like the future around 1990.
What really changed everything was advanced superscalar architecture. The Pentium Pro, which could execute significantly more than one instruction per clock, changed everything. The complexity was appallingly high, far beyond that of supercomputers. The design teams required were huge; Intel peaked somewhere around 3000 people on that project. But it worked. All the clever stuff, like the "retirement unit" actually worked. Even the horrible cases, like code that stored into instructions just ahead of execution, worked. It was possible to beat the RISC machines without changing the software.
The Pentium Pro was a bit ahead of the available fab technology. It required a multi-chip module, and was expensive to make. But soon fab caught up with architecture, and the result was the Pentium II and III, which delivered this technology to the masses. Then AMD figured out how to do superscalar x86, too, using
different approaches than Intel had taken.
The RISC CPUs went superscalar too. But they lost simplicity when they did. One of the big RISC ideas was to have many, many programmer-visible registers and do as much as possible register-to-register. But superscalar technology used register renaming, where the CPU has more internal registers than the programmer sees. The effect is that references to locations near the top of the stack are as efficient as register references. Once the CPU has that capability, all those programmer-visible registers don't help performance.
Making all the instructions the same size, as in most RISC machines, leads to code bloat. Look at RISC code in hex, and you'll see that the middle third of most instructions is zero. Not only does this eat up RAM, it eats up memory and cache bandwidth, which is today's scarce resource. Fixed size instructions simplify instruction decode, but that doesn't really affect performance all that much. So x86, which is a rather compact code representation, actually turns out to be useful.
The KVH TracVision 7 antenna for DirecTV reception is much more advanced. The device mentioned in the article has to be aimed at the satellite by hand. The TracVision units aim automatically. Two axes of mechanical positioning, plus a phased array antenna, are used. Rate gyros, a GPS receiver, and an excessive amount of computer power aim the thing. They even use slip rings, so that if you make too many turns in the same direction, you don't lose signal while the antenna cable unwinds. Only 5" thick, so there's no giant dome on top of the car. Rugged enough to go through a car wash.
Yes, now at last, full TV reception for Hummers, larger SUVs, and motor homes, even while moving. For about $3000.
This unit has a new and obnoxious form of DRM. If you subscribe to feeds of "local channels" via DirecTV, you can only get them within the "local area". GPS data and a database of boundaries enforces this. Go outside the "service area", and the signal turns off.
This is an impressive piece of technology. It seems wasted, given that all it does is let people watch broadcast television.
The problem with the X-prize was that all the money was in first place. When Space Ship One won it, there was no financial incentive for the others to keep going.
The classic example of that was the Kremer Prize for human-powered flight, won in 1977. Once that was done, interest in human-powered flight
declined substantially. That effort didn't usher in an era of recreational pedal-powered flying.
The problem is that the PS3 had the same problems the PS2 had in terms of difficulty to develop for.
Actually, no. On the PS2 and its predecessors, the wierd hardware was mostly devoted to graphics. On the PS3, the graphics hardware is relatively conventional; there's an NVidia GPU inside.
It's the non-graphics part of the machine that's non-conventional. This is new in consoles.
Worse, the wierd hardware didn't make it cheaper. Which is the killer. Always before, the
wierd hardware on game consoles has been there because you couldn't get equivalent price/performance with conventional hardware.
This wasn't Sony's intent.
The original plan for the PS3 was that the Cell processors would do the graphics work. If you see IBM demos of the Cell processor, they actually show it doing graphics. But it didn't really work out. Without enough memory per Cell CPU for a frame buffer, let alone texture maps, the graphics pipeline mapped badly to the Cell architecture. So Sony had to add in an NVidia GPU, which pushed costs up and slipped the schedule.
The Cell concept isn't all that bad, but it needs maybe 16MB per CPU to get programmers out of the streaming straitjacket.
Early in the Cell life-cycle, I went to a talk at Stanford given by IBM's architect for the thing. There was kind of a "build it and they will come" attitude - he didn't know how to use the thing effectively, but that was someone else's problem. That's always a bad sign. Years ago, I went to a talk by a lead Itanium guy, and he said much the same thing - it requires a near-omniscient compiler to get the scheduling right, and they hadn't been able to develop one yet, but he was confident someone would.
Both the Cell and the Itanium share the property that they make it easier to design the chip by pushing work onto the compiler people. That's usually not a good sign. On the other hand, if you let programmers design the CPU, you get something like a VAX, which has a clean, easy-to-program instruction set that could never be made to run fast.
Amazingly, x86 is actually a good compromise.
This is just retailing. Something local to do on a boring afternoon. Like gun shows, boat shows, car shows, flea markets, etc.
"Dolaher said the press conferences, keynote addresses, and big announcements that have marked previous E3s won't be present at E For All." The options on their web site are "I'm a a gamer" and "I'm an exhibitor". There's no option for people in the industry. And no reason to go there from further away than Long Beach.
Remember, porting to the PS3 is a huge pain, because of the weird Cell architecture, with very limited memory per CPU. As the tools get better, the costs of porting decline. From a developer perspective, it makes sense to wait.
XML is so last week. What's really wrong.
on
Web 2.0 Under Siege
·
· Score: 5, Informative
XML is now so last week. Really l33t web apps use JSON, which is yet another way to write S-expressions like those of LISP, but now in Javascript brackets.
There are several security problems with JSON. First, some web apps parse JSON notation by feeding it into JavaScript's "eval". Now that was dumb. Some JSON support code "filters" the incoming data before the EVAL, but the most popular implementation missed filtering something and left a hole.
Second, there's an attack similar to the ones involving redefining XMLHttpRequest: redefining the Array constructor. (Caution, page contains proof of concept exploit.)
The real problem is JavaScript's excessive dynamism. Because you can redefine objects in one script and have that affect another script from a different source, the language is fundamentally vulnerable. It's not clear how to allow "mashups" and prevent this. The last attempt to fix this problem involved adding restrictions to XMLHttpRequest, but that only plugged some of the holes.
As a minimum, it's probably desirable to insist in the browser that, on secure pages, all Javascript and data must come from the main page of the domain. No "mashups" with secure pages.
The stuff on google is often 5+ years old for some parts of the county (the copyright date gets updated, but the images do not)
I've noticed that. That's a violation of copyright law, by the way.
The question is who is setting those dates. Maybe Google's data providers are advancing the copyright date improperly, causing Google's image aggregation system to replace images with ones that are actually older.
About 44% of US adults say, when polled, that they go to church once a week. About 20% actually show up.
People thus self-report much higher levels of religion than they actually practice. Polled numbers should be derated according.
The 2001 National Survey of Religious Identification, the largest study on this in the last decade (113,000 respondents) came up with the following self-identified stats, for religions with 0.1% or more market share:
Christianity: 76.5%
Nonreligious/Secular: 13.2%
Judaism: 1.3%
Islam: 0.5%
Buddhism: 0.5%
Agnostic: 0.5%
Atheist: 0.4%
Hinduism: 0.4%
Unitarian Universalist: 0.3%
Wiccan/Pagan/Druid: 0.1%
Major trends are that "Secular", "Islam", "Buddism" and "Hinduism" were all up over 100% since 1990.
Slashdot Mirror
The last nail in the coffin came, of all places, from Apple. Thanks to OS X, Apple has come back from the dead in a way that is extremely rare in technology. Their victory is so complete that I'm now surprised when I come across a computer running Windows.
Uh, Apple desktop market share is still somewhere well under 10%. Has this guy been drug tested lately?
Actually, the big threat to Microsoft is OpenOffice. Office is where Microsoft makes its money. Putting Linux on a computer doesn't hurt Microsoft; they've already been paid by the computer maker. Installing OpenOffice instead of Microsoft Office comes directly out of Microsoft's profits. The web stuff gets all the press attention, but that's not where the money is.
"Protected processes" are a reasonable idea. They're certainly better than putting video and audio processing in the kernel as part of the DRM system. But apparently Microsoft botched the implementation.
Microsoft has for some years allowed processes to do too much to other processes. Things like "injecting" a DLL or thread into a running process from the outside, or "hooking" system calls, are inherently security problems. In the Windows world, normal processes can do that to each other. This tends to be overdone, with too much "hooking" of system calls and such, a tradition from the DOS era. The UNIX/Linux world doesn't have that tradition. Fortunately.
In the Linux world, the things you can't do to a Microsoft "protected process" are roughly equivalent to the functions of the PTRACE call. In SElinux, the mandatory security system controls which processes can use PTRACE on which other processes. So SELinux already has "protected processes", but with a better security model.
If we have to have DRM, protected processes aren't a bad idea. But what you want is for them to be compartmented, not privileged. They should be running in a compartment which prevents other processes from attaching to them, but they don't need the privilege of attaching to other processes. So the video decoder can be protected, but doesn't have enough privileges to act as an aimbot for some game. The security system for a game should be able to lock the game processes into a compartment which other processes cannot enter, preventing cheats. Enforce separation, not privilege.
This won't be the first US commercial spaceport. Mojave Spaceport has been active for several years now. SpaceShip One launched from there.
Rotary Rocket was supposed to launch their SSTO vehicle from Mojave, and built a vertical assembly building and a prototype at Mojave. But they had a weight growth problem and never got beyond low-altitude testing.
It's their answer to Microsoft's acquisition of TellMe. (1-800-555-TELL). Presumably, like TellMe, after a while they will add ads.
As usual, we have dig past all the blogodreck to get to the source material. And, as is typical of third-rate bloggers, there's no link to the original source. The "100 year vision" policy document they're quoting is speech by Wen Jiabao, addressed to the Communist Party of China, which he heads. The blog article attaches importance to the line "China is at the primary stage of socialism, and will remain so for a long time to come." That's a quote from the Chinese constitution. That line was changed back in 1993, which reflected some economic liberalization. Jiabao is making the point that there's no policy change. Overall, it's a "stay the course" speech; the current course is working.
The more specific technology plans are from a draft plan for medium and long term development, with the main site for the projects here.
As an old programmer, I'm not too impressed with that advice.
It's important today for a programmer to understand how top management thinks. Read the Wall Street Journal and the Economist. After about a year, both will start to make sense, as it takes about that long for all the major subjects to come around once or twice. Eventually, you'll probably want to move into management.
I'm not sure how much low-level knowledge really matters today. I understand what's going on down to the level of what happens in the wafer fab, but that's more because I'm in Silicon Valley. Understanding programming at the C level, definitely. At the machine code level, that may be too much detail to learn. A general notion of modern CPU architecture is useful; you should understand what caches do, why cache misses kill performance, and the implications of this at the program level. Detail beyond that level probably won't help you much. Understanding how an adder works is irrelevant to programming today.
It's probably more important to understand networking in some detail. Understanding Ethernet, DNS, WiFi, TCP, PPPoE, etc. is necessary, because they all can give trouble and you may have to diagnose that trouble.
I have to agree about the long-term value of UNIX knowledge vs. Microsoft-related knowledge. I first used UNIX in 1978, and programming on it has changed surprisingly little since then. We still have "make", we still have source control with check-in and check-out, and we still have a command line. And it doesn't go away. Since first using UNIX, I've used a half dozen other systems, most of them now defunct. Some were better. I keep getting forced back to UNIX, because it's still there after the others go away.
Asking for code samples from job applicants doesn't seem to work. A few years ago, I was asking for "a thousand lines of C++ code you're proud of." Few programmers could come up with much. Reading the code was sometimes painful. I sent one back with the note: "Your first buffer overflow is on line 22. Thank you for your interest."
Learning new programming languages isn't that hard, once you've learned a few different ones. What takes a long time is learning the quirks of a library. Today, each programming language comes with an library API with a few thousand objects and calls, some of which work reasonably. Finding out about the ones that don't is the most time-consuming part of learning a new environment today. This has led to a "ritual/taboo" style of programming, where huge books give sequences of code ("incantations") known to work, rather than development from first principles. This is the main source of career lock-in today. Be aware of that.
Yes, that's the obvious solution. And if Nextel doesn't have it working within four years, somebody is goofing off.
Wildfire, the voice controlled phone system which Microsoft bought and killed, was making real progress in that direction.
Manufacturer announces slightly different model of thing at lower price. How did this get in? Slow news day?
All those buzzwords. Apparently somebody has a system that can characterize and match images and video. That's reasonable enough, it's been done before, and the question is how good the new one is. The article gives zero help in that direction.
From the same source: "Nanogenerator provides continuous power by harvesting energy from the environment". It's a variation on the piezoelectric generator concept, like a piezo fire starter.
This article is yet another "we have a new chemistry and it's gonna be really cheap real soon now" article. Here's the real deal in solar power.
Yesterday, Mark Pinto from Applied Materials gave a talk in EE380 at Stanford on where they're going. Applied Materials is the biggest maker of semiconductor fab equipment, and they've branched out into making fab equipment for display panels and then solar cells.
To get costs down for big flat panel displays is a manufacturing technology problem. Applied Materials went at it in typical semiconductor-fab fashion - scaling up the fab size. They're now making panels of about 5 square meters in area. These are then cut up into 50-inch TV sets.
Once they got that working, they adapted the huge machinery involved to making solar panels. This turned out to work quite well. Since they're adapting a process that produces higher-quality product than a solar cell, they don't have significant quality problems. The solar-cell only makers tend to have spotty quality; he pointed out that with some solar panels, not all the cells are exactly the same color, which indicates trouble in the coating process.
With size and quality working, the next step is volume. They're about to build the first "40 megawatt fab", one that produces in a year enough solar panels to generate 40 megawatts. These are big panels, 2.2m x 2.6m. The price of the electricity produced should be just about even with peak-hour energy costs in Spain, where this is going. Energy payback (when you get more energy out than was required to make the panel) is about two years. That plant comes on line in 2008.
The next step is the "gigawatt fab", a scale-up of that plant. This is part of Applied Materials' "Solar Strategy". Their position is that the technology is here; it's just necessary to get it into volume production, real volume production. Which is what Applied Materials is good at.
Now we're talking about serious production volume. Three or four such plants could build enough solar cells to cover Southern California's air conditioning energy load in five years.
Meanwhile, they have investments in some other technologies, including a "roll to roll" flexible solar cell technology, and some exotic ideas like tinted glass windows that also generate power. But they don't need a breakthrough. The current technology is good enough to be profitable, so they can start making product and shipping it in volume, while research proceeds on lowering the cost further. Pinto pointed out that about half the cost of solar power is now installation, and that needs to move beyond "a guy with a pickup truck".
So that's what's really happening. Big machines in big factories built by big companies cranking out big solar panels in big volume. Which is how you solve big problems.
The site they're writing about, found by searching with Google for phrases in the article, isn't quite what the article says it is.
It's really yet another slimy "affiliate" program. "We give our code to your and you need to setup it to your websites. We pay for installs and for trusted webmasters for traffic if they want that." They're not selling malware with support. They're buying traffic to install their malware via drive-by installs. That's not exactly new. CometCursor, BonzaiBuddy, and Zango come to mind.
From the original article, someone else may be selling "fully managed exploit engines", but it's not these guys.
because most of the things around his office were protected by copyright.
You can't copyright a functional mechanical part. That's why there's a third-party auto parts industry. The author of the original article (free link) apparently has a desk full of promotional items, some of which might be copyrighted designs. That's the only reason he has copyright problems.
The article is really just a product review of a low-end 3D scanner. Not a very good one. Sounds worse than the low-end Roland scanners.
3D prototyping is still an expensive way to make mediocre parts. Most of the people enthused about it don't really have a clue about how manufactured goods are made. Making homogeneous solid objects in quantity is an incredibly cheap operation.
The real breakthrough with this technology is making objects with internal structure. The gecko robots from Stanford are made by loading up a stereolithography machine with several materials of different properties (flexible, stiff, conductive, insulating...) and building something that's almost organic in nature.
The Apple Lisa was a very nice machine, with a multitasking operating system, 1MB of protected-mode memory, a hard disk, and some decent applications. You could get work done on a Lisa. It just cost too much.
The original Macintosh, with 128K of RAM, one floppy, no hard drive, no memory protection, and a single-tasking operating system, was really an expensive toy. I've actually used one, and it wasn't fun. Most of the time you either waited for the machine or were swapping diskettes.
Not until the Macintosh was built up to Lisa levels of hardware was it useful. Once it got 512K, a hard drive, and the LaserWriter, it was a useful machine for designers. But that was several years later. The state of the art in hardware just wasn't up to a useful GUI machine at an affordable price until about 1985-1986.
(Bear in mind that, well before the Mac launched, you could buy a Sun UNIX workstation with a 19-inch display and networking for about $20K. And Sun wasn't even the first; Apollo shipped even earlier. The problem was getting the cost down.)
The Segway has to have been one of the most overhyped products of all time. When it was finally revealed on some TV show, the host said "That's it?".
It's a beautiful piece of technology. The last piece of consumer mechanical engineering with that much originality was the Polaroid SX-70. But it's a demonstration that if you throw enough money at the wrong problem, you can solve it.
Put them on eBay, a new batch every week, and make the Government some money. Then we'd find out what the real demand is.
The x86 instruction set is a surprisingly good way to build a computer. The reasons aren't obvious.
First, the original x86 was a huge pain, with that stupid segmented memory arrangement. But IA-32 was better and cleaner; at last there was a flat 32-bit address space. (Yes, there's a segmented 48-bit mode, and Linux even supports it, but at least apps see a flat address space.) AMD-64 is even more regular; the segmented memory stuff is completely gone in 64 bit mode. So there is progress.
RISC architectures could yield simple machines that could execute one simple fixed-width instruction per clock cycle. The early DEC Alphas, the MIPS machines, and early IBM Power chips are examples of straightforward RISC machines. This looked like a big win. The ALU was simple, design teams were small (one midrange MIPS CPU was designed by about six people), and debugging wasn't hard. RISC looked like the future around 1990.
What really changed everything was advanced superscalar architecture. The Pentium Pro, which could execute significantly more than one instruction per clock, changed everything. The complexity was appallingly high, far beyond that of supercomputers. The design teams required were huge; Intel peaked somewhere around 3000 people on that project. But it worked. All the clever stuff, like the "retirement unit" actually worked. Even the horrible cases, like code that stored into instructions just ahead of execution, worked. It was possible to beat the RISC machines without changing the software.
The Pentium Pro was a bit ahead of the available fab technology. It required a multi-chip module, and was expensive to make. But soon fab caught up with architecture, and the result was the Pentium II and III, which delivered this technology to the masses. Then AMD figured out how to do superscalar x86, too, using different approaches than Intel had taken.
The RISC CPUs went superscalar too. But they lost simplicity when they did. One of the big RISC ideas was to have many, many programmer-visible registers and do as much as possible register-to-register. But superscalar technology used register renaming, where the CPU has more internal registers than the programmer sees. The effect is that references to locations near the top of the stack are as efficient as register references. Once the CPU has that capability, all those programmer-visible registers don't help performance.
Making all the instructions the same size, as in most RISC machines, leads to code bloat. Look at RISC code in hex, and you'll see that the middle third of most instructions is zero. Not only does this eat up RAM, it eats up memory and cache bandwidth, which is today's scarce resource. Fixed size instructions simplify instruction decode, but that doesn't really affect performance all that much. So x86, which is a rather compact code representation, actually turns out to be useful.
The KVH TracVision 7 antenna for DirecTV reception is much more advanced. The device mentioned in the article has to be aimed at the satellite by hand. The TracVision units aim automatically. Two axes of mechanical positioning, plus a phased array antenna, are used. Rate gyros, a GPS receiver, and an excessive amount of computer power aim the thing. They even use slip rings, so that if you make too many turns in the same direction, you don't lose signal while the antenna cable unwinds. Only 5" thick, so there's no giant dome on top of the car. Rugged enough to go through a car wash.
Yes, now at last, full TV reception for Hummers, larger SUVs, and motor homes, even while moving. For about $3000.
This unit has a new and obnoxious form of DRM. If you subscribe to feeds of "local channels" via DirecTV, you can only get them within the "local area". GPS data and a database of boundaries enforces this. Go outside the "service area", and the signal turns off.
This is an impressive piece of technology. It seems wasted, given that all it does is let people watch broadcast television.
The problem with the X-prize was that all the money was in first place. When Space Ship One won it, there was no financial incentive for the others to keep going.
The classic example of that was the Kremer Prize for human-powered flight, won in 1977. Once that was done, interest in human-powered flight declined substantially. That effort didn't usher in an era of recreational pedal-powered flying.
Me too. I've had them blocked for so long I wasn't really aware they were still around.
The problem is that the PS3 had the same problems the PS2 had in terms of difficulty to develop for.
Actually, no. On the PS2 and its predecessors, the wierd hardware was mostly devoted to graphics. On the PS3, the graphics hardware is relatively conventional; there's an NVidia GPU inside. It's the non-graphics part of the machine that's non-conventional. This is new in consoles.
Worse, the wierd hardware didn't make it cheaper. Which is the killer. Always before, the wierd hardware on game consoles has been there because you couldn't get equivalent price/performance with conventional hardware.
This wasn't Sony's intent. The original plan for the PS3 was that the Cell processors would do the graphics work. If you see IBM demos of the Cell processor, they actually show it doing graphics. But it didn't really work out. Without enough memory per Cell CPU for a frame buffer, let alone texture maps, the graphics pipeline mapped badly to the Cell architecture. So Sony had to add in an NVidia GPU, which pushed costs up and slipped the schedule.
The Cell concept isn't all that bad, but it needs maybe 16MB per CPU to get programmers out of the streaming straitjacket.
Early in the Cell life-cycle, I went to a talk at Stanford given by IBM's architect for the thing. There was kind of a "build it and they will come" attitude - he didn't know how to use the thing effectively, but that was someone else's problem. That's always a bad sign. Years ago, I went to a talk by a lead Itanium guy, and he said much the same thing - it requires a near-omniscient compiler to get the scheduling right, and they hadn't been able to develop one yet, but he was confident someone would.
Both the Cell and the Itanium share the property that they make it easier to design the chip by pushing work onto the compiler people. That's usually not a good sign. On the other hand, if you let programmers design the CPU, you get something like a VAX, which has a clean, easy-to-program instruction set that could never be made to run fast. Amazingly, x86 is actually a good compromise.
This is just retailing. Something local to do on a boring afternoon. Like gun shows, boat shows, car shows, flea markets, etc. "Dolaher said the press conferences, keynote addresses, and big announcements that have marked previous E3s won't be present at E For All." The options on their web site are "I'm a a gamer" and "I'm an exhibitor". There's no option for people in the industry. And no reason to go there from further away than Long Beach.
If you're in the industry, you go to GDC or the Hollywood Games Summit.
Remember, porting to the PS3 is a huge pain, because of the weird Cell architecture, with very limited memory per CPU. As the tools get better, the costs of porting decline. From a developer perspective, it makes sense to wait.
XML is now so last week. Really l33t web apps use JSON, which is yet another way to write S-expressions like those of LISP, but now in Javascript brackets.
There are several security problems with JSON. First, some web apps parse JSON notation by feeding it into JavaScript's "eval". Now that was dumb. Some JSON support code "filters" the incoming data before the EVAL, but the most popular implementation missed filtering something and left a hole. Second, there's an attack similar to the ones involving redefining XMLHttpRequest: redefining the Array constructor. (Caution, page contains proof of concept exploit.)
The real problem is JavaScript's excessive dynamism. Because you can redefine objects in one script and have that affect another script from a different source, the language is fundamentally vulnerable. It's not clear how to allow "mashups" and prevent this. The last attempt to fix this problem involved adding restrictions to XMLHttpRequest, but that only plugged some of the holes.
As a minimum, it's probably desirable to insist in the browser that, on secure pages, all Javascript and data must come from the main page of the domain. No "mashups" with secure pages.
The stuff on google is often 5+ years old for some parts of the county (the copyright date gets updated, but the images do not)
I've noticed that. That's a violation of copyright law, by the way.
The question is who is setting those dates. Maybe Google's data providers are advancing the copyright date improperly, causing Google's image aggregation system to replace images with ones that are actually older.
About 44% of US adults say, when polled, that they go to church once a week. About 20% actually show up. People thus self-report much higher levels of religion than they actually practice. Polled numbers should be derated according.
The 2001 National Survey of Religious Identification, the largest study on this in the last decade (113,000 respondents) came up with the following self-identified stats, for religions with 0.1% or more market share:
Major trends are that "Secular", "Islam", "Buddism" and "Hinduism" were all up over 100% since 1990.