Stanford, the venture capital firm
on
Google Turns 10
·
· Score: 5, Interesting
Google started off running on Stanford equipment, and was spun off, as happens frequently at Stanford. Sun and Cisco also started with Stanford people and equipment.
Stanford has become a real estate company and a venture capital firm that runs a university on the side for the tax break. It's working out very well; they now have $21.6 billion in investment assets, including a big chunk of Google. This started around 1991, when the financial management operation was spun off as a separate company.
The financial operation invests in venture pools, which in turn fund venture capitalists, which fund startup companies, some of which become big. They can draw on expertise from the academic side to help evaluate investments. It's working quite well; annualized returns for the past decade were 15.1%. Tax free!
Actually, fixed length instructions have little effect on memory management. Alignment restrictions do. If an instruction can't access more than one page at a time or one cache line at a time, the MMU and cache controller can be simplified somewhat. X86 has no alignment restrictions; MIPS does. Note that alignment restrictions are visible at the source code level; you can write casts in C (typically from, say, "char *" to "int *") which result in pointers that aren't aligned on 2, 4, or 8 byte boundaries, and accessing such a pointer with a longer load will, on some CPUs, result in a machine exception.
Also, MIPS is the other "endian" from X86, so code that doesn't take precautions to be independent of that can fail when ported. In C, this means lots of "htonl" and "ntohl" macro calls are required.
Fixed length instructions do make instruction fetch and lookahead easier. On machines with variable length instructions, just finding the next instruction is a pain. Intel makes likely guesses and sometimes aborts a computation based on a bad guess. AMD Athlon processors unpack x86 code into a fixed-width form as a cache line is loaded. Both approaches work.
There are several steps in superscalar processors. The first is simple lookahead without register renaming, first seen in the CDC 6600 in the 1960s and the thing that Seymour Cray was famous for. Without register renaming, the compiler has to do some work to get multiple instructions going at once; it's necessary to emit code that looks like "load, load, load, operate, operate, operate, store, store, store", using different registers for each load/operate/store sequence. The pipeline stalls as soon as there's a register conflict.
MIPS, PowerPC, and especially SPARC code has to do this, and it's why RISC machines
needed lots of registers. Compilers need to know how much parallelism the actual CPU has, which varies from model to model, to get the superscalar acceleration to do anything. That's why MIPS compilers tend to have many options for the specific CPU implementation targeted.
The next step up is register renaming, where the number of programmer-visible registers is much less than the number actually inside the CPU. Modern X86 machines have about six major programmer-visible registers, but upwards of 40 in the CPU, so the same "register name" containing multiple values at different times can be internally represented as multiple registers, allowing RISC-type concurrency for an instruction set for which concurrency seems nearly impossible. This is where it gets really hard. The Pentium Pro was the first to do this. The compiler doesn't have to be explicitly aware of the details. Internally, such machines are more like data-flow engines than sequential CPUs; what's going on internally has only a vague resemblance to the programmer-visible model.
The trouble with having lots of programmer-visible registers is that you have to save and restore them on subroutine calls and interrupts. SPARC machines had so many registers that they had to add "register windows" and "spill and fill" hardware to deal with all the saving and loading.
A compact instruction set with a modest number of registers and extensive stack top usage, like X86, turns out to be a good input form for a superscalar engine. Intel tried two product lines of RISC machines (the i860 and i960) and a VLIW machine (the Itanium, or "Itanic"), and they were all worse than the X86 line. AMD's 64-bit version of X86 got rid of much of the legacy cruft, and that's a relatively clean architecture, although there's still emulation for 32-bit and 16-bit modes.
MIPS CPUs are very simple to design, if you're willing to accept the limitation of one instruction per clock. I once met the entire design team for a midrange MIPS CPU, and it was six people. When you look at a picture of the silicon, you can barely find the instruction decode and execute logic; it's a tiny fraction of the chip.
MIPS was overrun by the superscalar architectures, where you get more than one instruction per clock, at the cost of a huge increase in CPU logic complexity. The Pentium Pro design team was around 3000 people. (The Pentium II and III were basically Pentium Pro logic reworked for later fab processes.) It's amazing that x86 superscalar machines are even possible. (Think hard for a moment about what has to happen when you store into code just ahead of execution, which is fully supported by all x86 CPUs.) If you're willing to go superscalar, the simplicity goes away, and so does the advantage of the MIPS architecture.
But if you're willing to accept one instruction per clock, and a 2X code bloat over x86 (making all the instructions the same length means the register-to-register instructions take more bytes than they need), it's a simple way to build a CPU.
I always thought the Horizontal pixel count was put before the Vertical pixel count.
TV people put the vertical count ("lines") before the horizontal count, and film people talk about the horizontal count first. What digital cinema people call "2K" is almost the same as "1080p"; both are 1080 lines high, but digital cinema has an extra 128 pixels horizontally.
This difference comes from analog TV, where "line count" was a real count, but horizontal resolution was determined by the analog properties of the weakest part of the transmission path.
The whole point of robots is not to require an operator.
Teleoperators have their uses, but those uses are limited. They're useful if the worksite is dangerous (disarming bombs), unsuitable for humans (underwater), or on a different scale (surgical teleoperators). Remotely piloted vehicles have their uses, too, but even there, the trend is toward automated vehicles.
The remote-presence thing might be useful for people who go to too many meetings and don't have enough clout to force them to be videoconferences. This is a niche market.
We do need more data storage capacity for HTDV, because even with Blu-Ray, there's too much compression. That's the cause of the usual annoying artifact that moving objects are blurred at the edges and stabilize a few frames after they stop moving.
Displays are currently ahead of transmission and storage. Right now, LCD displays are capable of 1080p at frame rates into the 70Hz range, and some game consoles can output imagery approaching that range. But the data rates from most video media can't get up there yet.
"Digital cinema", as seen in theaters, currently comes in 1080x2048 (compared to the 1080x1920 of HTDV), which digital cinema people call "2K", and 2160x4096, or "4K". But their frame rates are low, 24 FPS normally, 48FPS at best. The number to shoot for is slightly above 70; Showscan established in tests years ago that humans can't tell the difference between 70FPS and higher rates, and there really is a noticeable improvement in audience reaction between even 48 FPS and 70 FPS. So we should probably be going for 72FPS.
The future of storage and transmission may be FrameFree compression. This is a combination of motion detection and morphing for image interpolation. When it works well, the frame rate is effectively limited only by the display and decompression technology. It also allows generating slow motion video from regular video, and is used for that in sports applications.
So there's the market target: 4K, 72FPS display, framefree compression, a 150 inch screen, a Super Bowl stream with enough bandwidth, and a case of beer.
Multiple processes and bloat
on
Chrome Vs. IE 8
·
· Score: 4, Interesting
Multiple intercommunicating processes are generally a good thing. And almost all modern operating systems can share read-only code regions between processes, which is safe.
However, once you put "just in time" compilers in, the sharing goes away. This is classically a Java problem; each Java instance has yet another copy of all the Java libraries in use. If Google Gears ends up importing as much cruft as Java does, it will have the same bloat problems.
Still, browsers have become memory hogs, even when rendering pages that aren't doing anything exciting. Firefox can balloon to 300MB after viewing a modest number of relatively vanilla pages. Even with "browser.cache.memory.enable" set to False.
Electronics has to be designed for potting, at least if it dissipates any significant power. You have to provide a heat path (usually a metal heat sink) out of the potted block. This is done routinely for DC-DC brick power supplies. But it's not going to work on a PC motherboard.
Right, it's conformal coating. People do that all the time. I've used Fine-L-Kote on boards.
Boards with connectors or jumpers have problems. If the CPU and RAM are soldered to the board
(as they often are in industrial, consumer, mobile, and automotive devices), just mask off
the connectors, jumpers, switches, battery contacts, etc. with masking tape and start spraying. Fine-L-Kote is transparent, but glows in UV, so you
can use a UV lamp to check if you missed anything. There are much heavier coatings, ones
that really encapsulate the board, and those are widely used for automotive, boat, and aircraft applications.
PC-type motherboards aren't a good choice for this, because of all those connectors. Those are
a weak point for corrosion anyway, so protecting the soldered-in components may not be all that
useful. But if, say, you're putting something like a single-board PC on your boat, it's
quite reasonable.
I ran some of these through our SiteTruth system to get legitimacy ratings. None of them rate very high.
boredatgustavus.net No website - not rated.
contributegustav.org Redirector - not rated - redirects to "braf.org"
braf.org Found in Open Directory, has business address, no ads. Turns out to be Baton Rouge Area Foundation, which has a 3-star rating in Charity Navigator and a writeup in Wikipedia, so they're legitimate.
contributiongustav.org redirects to "braf.org"
donategustav.org redirects to "braf.org".
donationgustav.org redirects to "braf.org".
gustav-hurricane.info No rating, contains frame of empty parking page.
gustav-hurricane.net SiteTruth says: "Site ownership unknown or questionable. -
No Location". It's just a parking page.
gustav-hurricane.org Frame of Sedo parking page.
gustav-hurricane.us No website.
gustav-relief.org No rating - GoDaddy parking page with ads.
gustavassistance.org redirects to "braf.org".
gustavattorney.com No rating - GoDaddy parking page with ads.
gustavcharities.com Rating: "Site ownership unknown or questionable. -
No Location". We were too harsh there; the site does have a street address, but it wasn't enough like a mailing address to be picked up. This page was set up by Samaritan's Purse, which gets four stars from Charity Navigator.
gustavcharity.com Rating: "Site ownership unknown or questionable. -
No Location". Samaritan's Purse again.
gustavclaims.netRating: "Site ownership unknown or questionable. -
No Location". Parked page with ads.
gustavcontribution.org Redirect to "braf.org".
Thus far, I'm not seeing major scams; just aggressive marketing by existing charities.
(SiteTruth is really the wrong tool for this job, because it's focused on business legitimacy, for which we have databases.)
The evacuation is over. The airport has closed, the buses have stopped running, the last train is gone, and the roads are empty. 5% - 10% of the population remains.
And a retail bank statement is kindergarten arithmetic compared with the monthly statement for a private banking client.
I used to have a Credit Suisse account, and they did, indeed, have incomprehensible statements, even for a simple situation. They had a "current account" and a "time account". The current account didn't pay interest, but the "time account" did. Interest from the time account went into the current account, and when it exceeded US$1000, it was moved to the time account in multiples of $1000. Separate statements were provided for each account, on different schedules, didn't mention what was happening in the other account, and were difficult to match up. Lots of weird fees, too, including charging commissions on their own time deposits. It all seemed to be about fee maximization.
And this was without doing much in the way of transactions on the account. If you did lots of transactions against accounts like that, it would be really tough to track what was happening.
The combination of inter-account transactions and differing statement cycles confuses the issue.
The National Hurricane Center did an excellent prediction job, just as they did with Katrina. The storm is almost exactly on the predicted track from the last three days. It's all done on Linux. The forecaster's desktops run Red Hat Linux. The back end systems run Linux. The supercomputing clusters run Linux.
They all still suck for about the same reasons they sucked three years ago.
The problems of Perl are well known, but it's probably the closest thing to "write once,
run everywhere" that we have. Perl is essentially static at Perl 5. There's a Perl 6 effort, with a major language redesign, expected to ship shortly after Duke Nukem Forever.
PHP is gaining because it's a simple way to do dynamic web site back ends.
It's not a great language, and limited to its niche, but useful there.
TCL was never a very good programming language, and it hasn't improved much.
Python is a nice language, but it still suffers from the limitations of the CPython implementation. It's slow, and integration with standard C modules is troublesome. Python has distro packaging problems - the Python maintainers don't coordinate with the maintainers of key modules, like the ones for talking to databases, and as a result Linux distros don't consistently ship with a CPython and a set of modules that play well together. That's why Python hasn't replaced Perl.
Javascript is a moderately painful language, yet we all have to use it. The object model is ill-designed; borrowing from Self was a mistake. Too much use is made of "eval", creating the "JSON" security hole. (Memo to language designers: don't combine the primitives for reading a string into an internal representation and for executing the internal representation. LISP has the "reader" and "eval"; Javascript has one function that does both.) Variable scope, given that the language has "var", is badly thought out. (Python is one of the few languages that does implicit declarations well. Perl had to retrofit "my", and Javascript had to retrofit "var", and in both cases, implicit declarations stayed, confusing the issue.) Because of this, Javascript has scaling problems. Attempts are made to paper this over with "toolkits", usually a bad sign.
I can't really say much about Ruby.
It's interesting that nobody uses Java applets much any more. It's worth understanding why
that failed. But that's another subject.
Why is NVidia using lead-based solders at this late date? The European RoHS deadline for lead-free components was back in 2005.
The NForce and 8800 parts were RoHS compliant years ago.
Are these NVidia parts even exportable to Europe?
At 4 Mb/s, 250Gb is 138 hours of HDTV per month. That's for the HDTV version of Vudu. NetFlix Roku also needs 4 MB/s. Apple TV needs 5 Mb/s in its best mode. Note that if you actually used one of those
boxes that much, you'd be paying over $500 per month in video rental charges.
(It's much like the iPod; filling up a large iPod with music from Apple's store would cost tens of thousands of dollars.)
One implication of all these set-top box movie devices is that there's going to be much more pressure on DSL and cable ISPs to deliver at least 4Mb/s sustained.
APC sells racks with integrated cooling. They have an online configurator program. Run the configurator, fill in your info, and you'll get a rack design.
Try changing the "watts per rack" number. Watch what happens as the configurator adds air conditioning units and fans. Note that as the power density goes up, the cost goes way up.
This is where they start to ask questions like "Do we really need a Web 2.0 web site?"
Now you're starting to get the picture.
I'm not partticularly recommending APC. They just happen to have a useful online tool, one which can give you something to take to your bosses to give them a sense of the costs as you add more equipment to a rack.
I've seen so many of the big labs die. I happened to be at IBM Alamaden the day IBM exited the disk drive business, a sad day and the beginning of the end for Alamaden. I saw Xerox PARC in its heyday; I've used and programmed an original Alto. DEC's labs are long gone, killed in the Compaq/HP takeover. HP Labs is a shadow of its former self.
Who in American industry is still doing basic research?
When wind power is covering less than 10% of the load, the UK study says no special arrangements are necessary to provide extra capacity to cover periods of low wind. I've seen 15% mentioned in US discussions. There's enough excess dispatchable generating capacity ("dispatchable" means you get output when you ask for it) to provide backup power for 10-15% wind.
Above that, it becomes more of a problem.
I've seen some US studies which indicate that even if wind power is averaged across a 1000 mile area (most of the Midwest and Southwest US), about 5% of the time, the whole collection of wind farms is generating very little output. So just running transmission lines around won't solve the problem. You need extra dispatchable capacity.
That dispatchable capacity is usually natural gas, hydro, or pumped storage. Dispatchable capacity of this type is typically a source where the installed equipment is relatively cheap but the fuel is expensive. In practice, this means gas turbines. If you have dams around that collect water but don't have enough continuous flow to be full-time hydropower sources, they can be effective intermittent sources. The California Water Project uses some of its reservoirs that way; they generate power during peak periods, but not all the time, because that would
drain the reservoir. Some California Water Project sites pump water uphill at night, when electricity is cheap, and profitably run it back down during peak periods in the daytime. Pure pumped storage plants are rare; the US has two.
Solar, of course, is not dispatchable. Nuclear plants are normally run full time, since they're mostly capital cost; the fuel cost is small.
I looked at this problem back in the early 1980s, when I was doing some work on TCP. I was trying to come up with a routing protocol that didn't require passing the same information around repeatedly, because backbone networks had very low bandwidth back then, and the existing routing protocols had either O(N^2) traffic or the "hop count to infinity" problem.
I came up with something called "Gateway Database Protocol", which was a scheme for passing tuples of the form "X says Y=Z" around. The idea was that any node seeing inconsistencies in "X says..." would propagate the tuple back to X, revealing the problem to X.
This is enough to detect hijacking, but not enough to stop it. I'd worked out a scheme good enough to automatically correct erroneous data, but not one good enough to deal with the insertion of hostile data. The design goal back then was to guarantee that if the hostile site was removed from the network (perhaps forcibly), the system would then stabilize into a valid state.
That's not enough any more. But it is worthwhile considering that a routing protocol should have the property that if X's info is being faked anywhere in the network, X hears about it. BGP doesn't do that.
Too (sic) bad this case will take several years before anything is decided and appealed.
That works against Apple. Apple is asking for an preliminary injunction, and since this case raises significant tying issues, they're probably not going to get one any time soon.
Slashdot Mirror
Google started off running on Stanford equipment, and was spun off, as happens frequently at Stanford. Sun and Cisco also started with Stanford people and equipment.
Stanford has become a real estate company and a venture capital firm that runs a university on the side for the tax break. It's working out very well; they now have $21.6 billion in investment assets, including a big chunk of Google. This started around 1991, when the financial management operation was spun off as a separate company. The financial operation invests in venture pools, which in turn fund venture capitalists, which fund startup companies, some of which become big. They can draw on expertise from the academic side to help evaluate investments. It's working quite well; annualized returns for the past decade were 15.1%. Tax free!
Well, their traffic is up. I can ping them, but HTTP connections are timing out.
Compile -> Jar -> War -> Deploy -> Expand -> Launch
Sun's Matryoshka_doll approach to Java has become a bit much.
Actually, fixed length instructions have little effect on memory management. Alignment restrictions do. If an instruction can't access more than one page at a time or one cache line at a time, the MMU and cache controller can be simplified somewhat. X86 has no alignment restrictions; MIPS does. Note that alignment restrictions are visible at the source code level; you can write casts in C (typically from, say, "char *" to "int *") which result in pointers that aren't aligned on 2, 4, or 8 byte boundaries, and accessing such a pointer with a longer load will, on some CPUs, result in a machine exception.
Also, MIPS is the other "endian" from X86, so code that doesn't take precautions to be independent of that can fail when ported. In C, this means lots of "htonl" and "ntohl" macro calls are required.
Fixed length instructions do make instruction fetch and lookahead easier. On machines with variable length instructions, just finding the next instruction is a pain. Intel makes likely guesses and sometimes aborts a computation based on a bad guess. AMD Athlon processors unpack x86 code into a fixed-width form as a cache line is loaded. Both approaches work.
There are several steps in superscalar processors. The first is simple lookahead without register renaming, first seen in the CDC 6600 in the 1960s and the thing that Seymour Cray was famous for. Without register renaming, the compiler has to do some work to get multiple instructions going at once; it's necessary to emit code that looks like "load, load, load, operate, operate, operate, store, store, store", using different registers for each load/operate/store sequence. The pipeline stalls as soon as there's a register conflict. MIPS, PowerPC, and especially SPARC code has to do this, and it's why RISC machines needed lots of registers. Compilers need to know how much parallelism the actual CPU has, which varies from model to model, to get the superscalar acceleration to do anything. That's why MIPS compilers tend to have many options for the specific CPU implementation targeted.
The next step up is register renaming, where the number of programmer-visible registers is much less than the number actually inside the CPU. Modern X86 machines have about six major programmer-visible registers, but upwards of 40 in the CPU, so the same "register name" containing multiple values at different times can be internally represented as multiple registers, allowing RISC-type concurrency for an instruction set for which concurrency seems nearly impossible. This is where it gets really hard. The Pentium Pro was the first to do this. The compiler doesn't have to be explicitly aware of the details. Internally, such machines are more like data-flow engines than sequential CPUs; what's going on internally has only a vague resemblance to the programmer-visible model.
The trouble with having lots of programmer-visible registers is that you have to save and restore them on subroutine calls and interrupts. SPARC machines had so many registers that they had to add "register windows" and "spill and fill" hardware to deal with all the saving and loading.
A compact instruction set with a modest number of registers and extensive stack top usage, like X86, turns out to be a good input form for a superscalar engine. Intel tried two product lines of RISC machines (the i860 and i960) and a VLIW machine (the Itanium, or "Itanic"), and they were all worse than the X86 line. AMD's 64-bit version of X86 got rid of much of the legacy cruft, and that's a relatively clean architecture, although there's still emulation for 32-bit and 16-bit modes.
MIPS CPUs are very simple to design, if you're willing to accept the limitation of one instruction per clock. I once met the entire design team for a midrange MIPS CPU, and it was six people. When you look at a picture of the silicon, you can barely find the instruction decode and execute logic; it's a tiny fraction of the chip.
MIPS was overrun by the superscalar architectures, where you get more than one instruction per clock, at the cost of a huge increase in CPU logic complexity. The Pentium Pro design team was around 3000 people. (The Pentium II and III were basically Pentium Pro logic reworked for later fab processes.) It's amazing that x86 superscalar machines are even possible. (Think hard for a moment about what has to happen when you store into code just ahead of execution, which is fully supported by all x86 CPUs.) If you're willing to go superscalar, the simplicity goes away, and so does the advantage of the MIPS architecture.
But if you're willing to accept one instruction per clock, and a 2X code bloat over x86 (making all the instructions the same length means the register-to-register instructions take more bytes than they need), it's a simple way to build a CPU.
I always thought the Horizontal pixel count was put before the Vertical pixel count.
TV people put the vertical count ("lines") before the horizontal count, and film people talk about the horizontal count first. What digital cinema people call "2K" is almost the same as "1080p"; both are 1080 lines high, but digital cinema has an extra 128 pixels horizontally. This difference comes from analog TV, where "line count" was a real count, but horizontal resolution was determined by the analog properties of the weakest part of the transmission path.
The whole point of robots is not to require an operator.
Teleoperators have their uses, but those uses are limited. They're useful if the worksite is dangerous (disarming bombs), unsuitable for humans (underwater), or on a different scale (surgical teleoperators). Remotely piloted vehicles have their uses, too, but even there, the trend is toward automated vehicles.
The remote-presence thing might be useful for people who go to too many meetings and don't have enough clout to force them to be videoconferences. This is a niche market.
We do need more data storage capacity for HTDV, because even with Blu-Ray, there's too much compression. That's the cause of the usual annoying artifact that moving objects are blurred at the edges and stabilize a few frames after they stop moving.
Displays are currently ahead of transmission and storage. Right now, LCD displays are capable of 1080p at frame rates into the 70Hz range, and some game consoles can output imagery approaching that range. But the data rates from most video media can't get up there yet.
"Digital cinema", as seen in theaters, currently comes in 1080x2048 (compared to the 1080x1920 of HTDV), which digital cinema people call "2K", and 2160x4096, or "4K". But their frame rates are low, 24 FPS normally, 48FPS at best. The number to shoot for is slightly above 70; Showscan established in tests years ago that humans can't tell the difference between 70FPS and higher rates, and there really is a noticeable improvement in audience reaction between even 48 FPS and 70 FPS. So we should probably be going for 72FPS.
The future of storage and transmission may be FrameFree compression. This is a combination of motion detection and morphing for image interpolation. When it works well, the frame rate is effectively limited only by the display and decompression technology. It also allows generating slow motion video from regular video, and is used for that in sports applications.
So there's the market target: 4K, 72FPS display, framefree compression, a 150 inch screen, a Super Bowl stream with enough bandwidth, and a case of beer.
Multiple intercommunicating processes are generally a good thing. And almost all modern operating systems can share read-only code regions between processes, which is safe.
However, once you put "just in time" compilers in, the sharing goes away. This is classically a Java problem; each Java instance has yet another copy of all the Java libraries in use. If Google Gears ends up importing as much cruft as Java does, it will have the same bloat problems.
Still, browsers have become memory hogs, even when rendering pages that aren't doing anything exciting. Firefox can balloon to 300MB after viewing a modest number of relatively vanilla pages. Even with "browser.cache.memory.enable" set to False.
Electronics has to be designed for potting, at least if it dissipates any significant power. You have to provide a heat path (usually a metal heat sink) out of the potted block. This is done routinely for DC-DC brick power supplies. But it's not going to work on a PC motherboard.
Right, it's conformal coating. People do that all the time. I've used Fine-L-Kote on boards.
Boards with connectors or jumpers have problems. If the CPU and RAM are soldered to the board (as they often are in industrial, consumer, mobile, and automotive devices), just mask off the connectors, jumpers, switches, battery contacts, etc. with masking tape and start spraying. Fine-L-Kote is transparent, but glows in UV, so you can use a UV lamp to check if you missed anything. There are much heavier coatings, ones that really encapsulate the board, and those are widely used for automotive, boat, and aircraft applications.
PC-type motherboards aren't a good choice for this, because of all those connectors. Those are a weak point for corrosion anyway, so protecting the soldered-in components may not be all that useful. But if, say, you're putting something like a single-board PC on your boat, it's quite reasonable.
This looks like a spam. If they don't even mention the domain name, they're probably not very serious about it.
I get those all the time, especially from my "downside.com" domain.
I ran some of these through our SiteTruth system to get legitimacy ratings. None of them rate very high.
Thus far, I'm not seeing major scams; just aggressive marketing by existing charities.
(SiteTruth is really the wrong tool for this job, because it's focused on business legitimacy, for which we have databases.)
The evacuation is over. The airport has closed, the buses have stopped running, the last train is gone, and the roads are empty. 5% - 10% of the population remains.
And a retail bank statement is kindergarten arithmetic compared with the monthly statement for a private banking client.
I used to have a Credit Suisse account, and they did, indeed, have incomprehensible statements, even for a simple situation. They had a "current account" and a "time account". The current account didn't pay interest, but the "time account" did. Interest from the time account went into the current account, and when it exceeded US$1000, it was moved to the time account in multiples of $1000. Separate statements were provided for each account, on different schedules, didn't mention what was happening in the other account, and were difficult to match up. Lots of weird fees, too, including charging commissions on their own time deposits. It all seemed to be about fee maximization.
And this was without doing much in the way of transactions on the account. If you did lots of transactions against accounts like that, it would be really tough to track what was happening. The combination of inter-account transactions and differing statement cycles confuses the issue.
The National Hurricane Center did an excellent prediction job, just as they did with Katrina. The storm is almost exactly on the predicted track from the last three days. It's all done on Linux. The forecaster's desktops run Red Hat Linux. The back end systems run Linux. The supercomputing clusters run Linux.
They all still suck for about the same reasons they sucked three years ago.
The problems of Perl are well known, but it's probably the closest thing to "write once, run everywhere" that we have. Perl is essentially static at Perl 5. There's a Perl 6 effort, with a major language redesign, expected to ship shortly after Duke Nukem Forever.
PHP is gaining because it's a simple way to do dynamic web site back ends. It's not a great language, and limited to its niche, but useful there.
TCL was never a very good programming language, and it hasn't improved much.
Python is a nice language, but it still suffers from the limitations of the CPython implementation. It's slow, and integration with standard C modules is troublesome. Python has distro packaging problems - the Python maintainers don't coordinate with the maintainers of key modules, like the ones for talking to databases, and as a result Linux distros don't consistently ship with a CPython and a set of modules that play well together. That's why Python hasn't replaced Perl.
Javascript is a moderately painful language, yet we all have to use it. The object model is ill-designed; borrowing from Self was a mistake. Too much use is made of "eval", creating the "JSON" security hole. (Memo to language designers: don't combine the primitives for reading a string into an internal representation and for executing the internal representation. LISP has the "reader" and "eval"; Javascript has one function that does both.) Variable scope, given that the language has "var", is badly thought out. (Python is one of the few languages that does implicit declarations well. Perl had to retrofit "my", and Javascript had to retrofit "var", and in both cases, implicit declarations stayed, confusing the issue.) Because of this, Javascript has scaling problems. Attempts are made to paper this over with "toolkits", usually a bad sign.
I can't really say much about Ruby.
It's interesting that nobody uses Java applets much any more. It's worth understanding why that failed. But that's another subject.
Why is NVidia using lead-based solders at this late date? The European RoHS deadline for lead-free components was back in 2005. The NForce and 8800 parts were RoHS compliant years ago. Are these NVidia parts even exportable to Europe?
At 4 Mb/s, 250Gb is 138 hours of HDTV per month. That's for the HDTV version of Vudu. NetFlix Roku also needs 4 MB/s. Apple TV needs 5 Mb/s in its best mode. Note that if you actually used one of those boxes that much, you'd be paying over $500 per month in video rental charges. (It's much like the iPod; filling up a large iPod with music from Apple's store would cost tens of thousands of dollars.)
One implication of all these set-top box movie devices is that there's going to be much more pressure on DSL and cable ISPs to deliver at least 4Mb/s sustained.
OK, here's a way to approach the problem.
APC sells racks with integrated cooling. They have an online configurator program. Run the configurator, fill in your info, and you'll get a rack design.
Try changing the "watts per rack" number. Watch what happens as the configurator adds air conditioning units and fans. Note that as the power density goes up, the cost goes way up.
This is where they start to ask questions like "Do we really need a Web 2.0 web site?" Now you're starting to get the picture.
I'm not partticularly recommending APC. They just happen to have a useful online tool, one which can give you something to take to your bosses to give them a sense of the costs as you add more equipment to a rack.
That's sad.
I've seen so many of the big labs die. I happened to be at IBM Alamaden the day IBM exited the disk drive business, a sad day and the beginning of the end for Alamaden. I saw Xerox PARC in its heyday; I've used and programmed an original Alto. DEC's labs are long gone, killed in the Compaq/HP takeover. HP Labs is a shadow of its former self.
Who in American industry is still doing basic research?
Here's a useful briefing paper on dealing with intermittency in wind power. It's a UK document, and has some hard numbers about wind plants in Europe.
When wind power is covering less than 10% of the load, the UK study says no special arrangements are necessary to provide extra capacity to cover periods of low wind. I've seen 15% mentioned in US discussions. There's enough excess dispatchable generating capacity ("dispatchable" means you get output when you ask for it) to provide backup power for 10-15% wind. Above that, it becomes more of a problem.
I've seen some US studies which indicate that even if wind power is averaged across a 1000 mile area (most of the Midwest and Southwest US), about 5% of the time, the whole collection of wind farms is generating very little output. So just running transmission lines around won't solve the problem. You need extra dispatchable capacity.
That dispatchable capacity is usually natural gas, hydro, or pumped storage. Dispatchable capacity of this type is typically a source where the installed equipment is relatively cheap but the fuel is expensive. In practice, this means gas turbines. If you have dams around that collect water but don't have enough continuous flow to be full-time hydropower sources, they can be effective intermittent sources. The California Water Project uses some of its reservoirs that way; they generate power during peak periods, but not all the time, because that would drain the reservoir. Some California Water Project sites pump water uphill at night, when electricity is cheap, and profitably run it back down during peak periods in the daytime. Pure pumped storage plants are rare; the US has two.
Solar, of course, is not dispatchable. Nuclear plants are normally run full time, since they're mostly capital cost; the fuel cost is small.
Did you write it down? Any chance you can provide a link?
There was a Ford Aerospace internal technical publication, but Ford Aerospace is long gone. I have a copy but no rights to distribute it.
I looked at this problem back in the early 1980s, when I was doing some work on TCP. I was trying to come up with a routing protocol that didn't require passing the same information around repeatedly, because backbone networks had very low bandwidth back then, and the existing routing protocols had either O(N^2) traffic or the "hop count to infinity" problem.
I came up with something called "Gateway Database Protocol", which was a scheme for passing tuples of the form "X says Y=Z" around. The idea was that any node seeing inconsistencies in "X says ..." would propagate the tuple back to X, revealing the problem to X.
This is enough to detect hijacking, but not enough to stop it. I'd worked out a scheme good enough to automatically correct erroneous data, but not one good enough to deal with the insertion of hostile data. The design goal back then was to guarantee that if the hostile site was removed from the network (perhaps forcibly), the system would then stabilize into a valid state.
That's not enough any more. But it is worthwhile considering that a routing protocol should have the property that if X's info is being faked anywhere in the network, X hears about it. BGP doesn't do that.
Too (sic) bad this case will take several years before anything is decided and appealed.
That works against Apple. Apple is asking for an preliminary injunction, and since this case raises significant tying issues, they're probably not going to get one any time soon.