Amazon and Google faced similar problems, and dealt with them in ways that are roughly equivalent - by adding a tuple store to their system.
If the data behind your web site is mostly accessed via one primary key, a tuple store, something that stores name/value pairs, beats a general-purpose relational database. Both Amazon and Google have such a mechanism in their "cloud" systems. Facebook has a somewhat low-rent solution; they're front-ending MySQL with a tuple store cache. This only works if all the queries contain some ID that has to match exactly, like user ID. Effectively, instead of one big database, the problem consists of a large number of tiny databases, all somewhat independent. Problems like that can be scaled up without much trouble.
Tuple stores distribute nicely - you can spread them over as many machines as you want, just by cutting up the keyspace into conveniently sized shards. There are distributed relational DBMS systems, but they have to be able to do inter-machine joins, which is a hard problem.
(That's what you pay the big bucks to Oracle for.)
What's being proposed for the US is similar to what Canada already has. About 25% of Canadian workers belong to a union, compared to about 12% for the US. The US and Canada had about an equal percentage of unionized workers in the 1950s, when changes in US law made it harder for workers to unionize.
There are successful unions for professionals. Check out The Animation Guild, which is part of IATSE. If it came from Hollywood and was animated, an Animation Guild member probably did it. In Redwood City, Dreamworks and EA have facilities in the same building complex, with many people doing similar jobs. Dreamworks is unionized, but EA is not. The Dreamworks people have reasonable hours, unlike the EA peons.
Here's the Animation Guild standard contract. A few key points:
Everything in the contract is a minimum from the employee side. Individual employees can negotiate for raises and bonuses beyond the minimums. This differs from, say, UAW contracts, which have specific pay scales.
The working week is five days, with two consecutive days off. ("Unions: the people who brought you the weekend".) Beyond five days, pay rises to 150% of the base rate. Beyond 6 days, 200%.
There may still be "crunches", but you get paid well for them. This discourages employers from managing in a way that leads to "crunches".
More than 8 hours per day, pay rises to 150% of the base rate. More than 14 hours per day, 200%. And yes, those multiply by the day overtime rates. This really discourages "crunches".
"On call" employment is at least 4 hours. So if you have to come in on a weekend to deal with a crisis, you get paid for 4 hours minimum. This discourages unnecessary "crises".
There's an industrywide pension plan, and pensions are portable across the industry. As the Animation Guild points out, only two animation studios that were active when they were founded in the 1940s are still active.
Apple doesn't need Macworld because Apple doesn't need fanboys any more.
The Apple fanboy crowd is totally irrelevant to the iPod/iPhone line - those are mass-market consumer products. The laptop product line is aimed more at the status-conscious crowd. Neither market is the Macworld demographic.
Actually, Makay doesn't have a "model"; that 1841 book, which I've been recommending to investors since 2001, is simply a history of the classic early financial crises. Great book; anybody with money or interests in getting some should read it. It describes Version 1 of all the famous disastrous financial schemes, from Law's bank to the South Sea Bubble.
The "ideological assumptions" that were a problem involved deregulation, which got completely out of hand. We used to have a heavily regulated financial system designed during the last depression. Investment and banking were completely separate; banks couldn't speculate in stocks, and brokers couldn't take deposits. This kept stock market problems from taking down
banks. That was the Glass-Stegall Act, repealed in 1999.
The US also used to have a savings and loan system that took deposits and sold mortgages, and didn't do much else. Mortgage securitization is quite new; it didn't become big until the mid-1990s. And mortgages used to require a 20% down payment and be limited to under 3x borrower annual income.
US banks used to be unable to lend for stock market speculation. Only brokers could do that, as
"margin", and brokers couldn't create money in the way banks can.
With all those constraints in place, the financial system held together better during stock downturns. The dot-com collapse didn't take down banks. Now we have banks going down because they lent to hedge funds.
I just saw the poster presentations from CS 229, Machine Learning, at Stanford. The current batch of projects aren't on line yet, but the ones from previous years are.
The projects were very impressive. A vision-guided autonomous helicopter. A system for separating out instruments and vocals from existing audio. A CAPTCHA solver. De-blurring of out of of focus images. Flower recognition. Recognition of hostile network traffic. And those were just a few of the projects. Machine learning really works now.
I've been using OpenOffice since 1.0, and I'm now on 3.0. I don't think I've used Microsoft Word in the last year, although I still have a valid copy of Word 97 around.
OpenOffice actually works now; it doesn't crash or garble documents. But its interface is painful and amateurish.
"Help" brings up some vaguely relevant section of a manual, often one that's meaningless without context. The menus described in the manual tend not to be exactly those in the program. It's like someone ran a manual through a program that converted it into a help file.
Functions like envelope-making never quite work right. Envelope info is mispositioned or clipped wrong. Even in Word 97, this just worked.
It's not clear whether printing settings are part of the document or part of the user preferences. I once had a serious problem with a project done in OO 2.0 because, when the final version was printed, the user printer settings of 8.5x11" paper were used when printing an A4-sized document to A4 paper, the document was silently clipped, and a bad version went out the door. Some items, like "manual feed" for envelopes, can be set in several places, and they're not crosschecked.
I tried the formula editor. I closed the formula window. Now it's gone forever. How do I get it back? The help file won't tell me.
Mail merge and envelope/label generation do roughly the same thing, but have totally different interfaces.
The default heading styles are ugly and lame. You don't mix serif and sans-serif fonts like that. The defaults should be reasonably good-looking.
With enough effort, you can work around these problems. But this is just a word processor. It should just work. And this is version 3; they've been at this for a decade now.
This is a generic problem with open source user applications. They need real usability testing, where naive users are videoed doing various tasks while commenting on what bugs them. They seldom get it.
Search personalization is of marginal value. In fact, it's kind of a pain, because searches become nonportable and nonrepeatable. If you tell someone else "search for...", they won't get the same results you did. But advertising personalization... that's where the money is.
Google offers a great range of services and products, but almost all of them lose money.. No Google product other than search advertising makes money, and even that is declining. The Google Content Network (Google ads on non-Google sites) isn't that beneficial to the actual advertisers, and the more savvy advertisers have opted out of it. People click on those ads, but seldom buy.
(By default, AdWords customers are opted in, and the opt-out checkbox is hard to find.) Google stock is down 57% from the peak, and revenue is projected to decline for the next three years.
So Google is cutting back on new projects, killing off some of the money-losers, and trying to milk their one profitable product, ads on search results, for all they can.
Using search history, it would be straightforward to recognize specific big-ticket buying situations, like "looking for a car" or "looking for a house". This can be used for lead generation. Search for information about cars for a while, and not only do you start seeing car ads all the time, you get phone calls from sales reps.
People like you helping people like us help ourselves. - Processed World
The real search engine is just for backup
on
Google Zeitgeist 2008
·
· Score: 3, Interesting
The front-end machines at Google have a set of canned replies for common queries. Most queries to Google are in fact answered by the first front-end machine reached, without
invoking the main search engine at all. The size of the front-end cache is considered proprietary, but it's not huge.
Diamond grit, as an abrasive, is currently around $0.07/carat in bulk. It's almost all synthetic, not hard to make, and used for a wide variety of cutting tools. Synthetic diamond production is about 100x mined production. The glamour has gone out of diamond; it's now what sewer workers use on their cutting tools when they need to slice through cement pavement.
The diamond industry (i.e. DeBeers) painted themselves into a corner, by taking the position that that "flawless" diamonds are the most valuable. That's not where you want to be positioned going up against the industries that make semiconductor wafers.
This all happened to sapphires about sixty years ago. Sapphires used to be rare and valuable. Then Linde Chemical started synthesizing them, and destroyed the market.
Now you can buy sapphire bar stock and transparent sapphire plates for supermarket checkout scanners. Since then, it's happened to rubies and emeralds. Now, cheap diamonds.
Why run this out of the Executive Office of the President? Trying to
run operational units directly from the White House seldom works well; the
environment is political, not operational. The present cybersecurity office, in
Homeland Security, is ineffective because the incumbent is a former lobbyist.
When Amit Yoran was in charge there, progress was being made. He quit
because he wasn't getting backing from higher in Homeland Security.
The office needs a high-level champion in the White House, but
that's a liasion job.
The problem is that iPhone apps are really plug-ins to a larger application. Nobody makes real money selling plug-ins for any application, phone or otherwise. You're in too inferior a marketing position.
If you actually read Tesla's paper, you find that what he had in mind was powering a small town with a setup where each house had an attic full of antennas to power a 40 watt bulb.
The efficiency would be low, and would require excessive power at the generation end. But it would be wireless power transmission.
The basic problem is that you power not only tuned power receivers, but just about anything with a coil anywhere nearby.
Point to point power transmission via microwaves works better. There have been a few demo systems, mostly for point to point power transmissions between islands. It's been tried successfully between Hawaiian islands, on Reunion Island, and between Japanese islands. Of course, it's been discussed for solar power satellites. So far, nobody has found a commercial justification for doing it, but it works.
Put another way, the advances in 2D have tracked with Moore's Law, but 3D is a completely different exponent.
Nah. There's only so much detail you can see. Rendering a really big world is work-bounded by level of detail processing. It's nowhere near O(N^3). If you get to use fog or obstacles to hide distant areas, there's an constant upper bound on the work required, so it's O(1). That's how most older video games do it.
Without fog, if you preprocess the model to have low-rez versions of objects for distant display, it's O(log N), which is manageable.
There's some liberal-arts school that teaches Forth as a first programming language. The idea is that it's close enough to the machine to make it clear what's really going on, but abstract enough that you can get reasonable amounts of work done with modest amounts of code. It's like the MIT approach of teaching Scheme; nobody writes much production code in Scheme, but it's a straightforward language with a clear underlying model.
(I'm not recommending writing anything real in Forth at this late date. Twenty years ago I used it for some robotics work, but only because there wasn't a C compiler for the 68HC11 at the time.)
If you're using C++ in such a way that 'pointer==array' matters, you are not using it correctly. C++ has STL & boost/TR1 to provide the standard data structures, smart pointers (C#/Java references) and algorithms you want.
Right. That's the wallpaper over the mold. The C arrays are still there, underneath, and you'll often need them for system calls and I/O. The smart pointer stuff is never airtight, because raw pointers seep out. "auto_ptr" went through about four iterations in the standard, and it still sucked. "auto_ptr" objects also have strange destructive assignment semantics. Reference counted memory allocation is a good idea, but the "smart pointer" systems in C++ never seem to become immune to problems. In Perl and Python, that stuff just works, but bolting it on via templates just doesn't cut it.
Also, if you really want managed memory,, there are GC implementations for C++.
Garbage collection and destructors do not play well together. Microsoft tried really hard to make that work in their "Managed C++", and it was a horror. It's possible in "Managed C++" for a destructor to be called more than once.
It's amusing seeing Strostrup whining that schools are teaching Java instead of his C++. The problem with C++ is Strostrup. He's in denial about many of the fundamental problems of C++. He's publicly stated that there's nothing major wrong with C++. If that was the case, we wouldn't need Java and C#, which are, after all, attempts to improve on C++.
Down at the bottom, the fundamental problem with C and C++ is the "pointer=array" concept. That was OK for 1978, but it didn't scale well. It's the cause of most of the buffer overflows in the world. C and C++ don't even have syntax for properly talking about the size of an array parameter. That's just broken. C and C++ need something like
conformant array syntax for parameters and in other contexts where one needs to talk about the size of an array.
The second fundamental problem with C and C++ is that the programmer must obsess on "who owns what", and the language not only doesn't provide help with this, it doesn't even have syntax for talking about it. There's no distinction between a pointer that "owns" an object and one that just "uses" it. Yet if the programmer doesn't carefully make that distinction, the program will have either memory leaks or dangling pointers.
The trend in C++, since templates went in, is to try to wallpaper over the problems with the underlying model. It never quite works; the mold always seeps through the wallpaper.
Container classes almost, but not quite, succeed at encapsulation. There's almost always some place where a raw pointer has to be allowed to leak out. The standards committee has gone off on a "generic programming" tangent, with emphasis on weird template features used by few and used correctly by fewer. Just because you can abuse the C++ template system as a term-rewriting engine doesn't mean you should do that in production code. This results in a whole new class of incredibly obscure compile-time bugs. The standards committee has been thrashing for over a decade in this area; in the 1990s, the new version was to be "C++9x"; now it's "C++0x", and since we're close to 2009 already, "C++1x" looks like the reality.
C++ is the only major language to have hiding ("abstraction") without memory safety.
No previous language had it, and no later language repeats that mistake.
Back around 2001, I made an effort to do something about it, but the political hassle was more than I had time for.
This is really a little operating system, with 44 system calls. Those system calls are the same on Linux, MacOS (IA-32 version) and Windows. That could make this very useful - the same executable can run on all major platforms.
Note that you can't use existing executables. Code has to be recompiled for this
environment. Among other things, the "ret" instruction has to be replaced with
a different, safer sequence. Also, there's no access to the GPU, so games in the browser will be very limited. As a demo, they
ported Quake, but the rendering is entirely on the main CPU. If they wanted to support graphics cross-platform, they could put in OpenGL support.
Executable code is pre-scanned by the loader, sort of like VMware. Unlike VMware, the hard cases are simply disallowed, rather than being interpreted. Most of the things that are disallowed you wouldn't want to do anyway except in an exploit.
This sandbox system makes heavy use of some protection machinery in IA-32 that's unused by existing operating systems. IA-32 has some elaborate segmentation hardware which allows constraining access at a fine-grained level. I once looked into using that hardware for an interprocess communication system with mutual mistrust, trying to figure out a way to lower the cost of secure IPC. There's a seldom-used "call gate" in IA-32 mechanism that almost, but not quite, does the right thing in doing segment switches at a call across a protection boundary. The Google people got cross-boundary calls to work with a "trampoline code" system that works more like a system call, transferring from untrusted to trusted code. This is more like classic "rings of protection" from Multics.
Note that this won't work for 64-bit code. When AMD came up with their extension to IA-32 to 64 bits, they decided to leave out all the classic x86 segmentation machinery because nobody was using it. (I got that info from the architecture designer when he spoke at Stanford.) 64-bit mode is flat address space only.
Annoyed with the situation on his block in San Francisco, a techie has created Adam's Block, which has an HD camera pointed at a drug dealer corner. You can watch the deals go down. Try expanding the left window to full screen; the HD detail is there.
There's an attached blog and audit trail, and people are logging SFPD cars as they go by.
Fans of the site are waiting for an arrest. Hasn't happened yet.
It's streamed out via Justin.tv, so there's enough bandwidth for Slashdot users to watch.
Such as ResPower. They've been around for a while, from before the "grid" era (remember the "grid" era?). This is a good example of a service which successfully scales up the number of machines applied to your job based on available resources and load. Unlike a web service, though, ResPower normally runs fully loaded,
and charges a daily rate with variable turnaround, rather charging for each render.
(They do offer a metered service, but it's not that popular.)
It's worth looking at ResPower because, unlike most of the "grid" or "cloud" services, they have an
established customer base and make money.
Python has terrible problems with concurrency. CPython can't use more than one CPU at all, even in multithreaded programs, because of the infamous "Global Interpreter Lock".
In Python, there's too much shared global state associated with binding. The dynamism that
makes it possible to add a new function to an object during execution means constant
access to object dictionaries shared across threads. Python not only has late binding,
it has hidden late rebinding; some other thread can modify an object while control is within an object instance. This is rare, and usually avoidable, but because it's possible and can't be detected at compile time, the run time system has to make the worst case checks every time.
For parallelism, the issue is not functional programming, but single assignment. In a single-assignment language, each variable can only be changed once. Functional programming is one way of achieving this, but it's not the only way.
The idea is supposed to be that single assignment makes it easy to turn a program into a pipelined form at compile time. It's supposed to make automatic parallelization easier.
In practice, compilers for single-assignment languages haven't been overly impressive in performance.
Supercomputing is mostly a Government-funding boondoggle. The private sector buys few if any supercomputers.
Most of the US government applications are either related to nuclear weapons, or are busywork for underutilized nuclear weapons labs. Sandia, Los Alamos, and Livermore, lacking bombs to design, are looking for something else to justify their continued existence. To some extent, they're senior activity centers for old physicists. There's also "stockpile stewardship", which is an activity center for younger physicists. The idea is to keep some people around who can build an H-bomb if necessary, so that the technology isn't lost as people die off. Since that crowd isn't allowed to actually do much of anything, they want to simulate a lot. It's really a political problem. If the US and Russia allowed each other one underground bang each year, there would be less need for all this iffy simulation.
So don't worry too much about whining from Sandia about supercomputers. When Google or Amazon start complaining that multicore machines are choking in their server farms, it's time to listen.
Rather than laptops with zillions of CPU cores, we're probably going to see CPU chip real estate used for more cache, and maybe even main memory. The near future is the one-chip laptop that sells for $100 or so.
Enom and its many other identities - use only for bulk junk domains
GoDaddy - low-end service; use for unimportant blogs.
Network Solutions - use for general business domains (ibm.com)
MarkMionitor - use for high value domains (gm.com, ubs.com)
MarkMonitor is in the business of protecting "brands", so they have lawyers and technicians on staff to swing into action if somebody pulls something. If you have to ask how much they cost, you can't afford them.
Slashdot Mirror
Right. The term "key/value pair" is generally used by "cloud" people. The term "tuple store" is a more generic term from academia.
Amazon and Google faced similar problems, and dealt with them in ways that are roughly equivalent - by adding a tuple store to their system.
If the data behind your web site is mostly accessed via one primary key, a tuple store, something that stores name/value pairs, beats a general-purpose relational database. Both Amazon and Google have such a mechanism in their "cloud" systems. Facebook has a somewhat low-rent solution; they're front-ending MySQL with a tuple store cache. This only works if all the queries contain some ID that has to match exactly, like user ID. Effectively, instead of one big database, the problem consists of a large number of tiny databases, all somewhat independent. Problems like that can be scaled up without much trouble.
Tuple stores distribute nicely - you can spread them over as many machines as you want, just by cutting up the keyspace into conveniently sized shards. There are distributed relational DBMS systems, but they have to be able to do inter-machine joins, which is a hard problem. (That's what you pay the big bucks to Oracle for.)
What's being proposed for the US is similar to what Canada already has. About 25% of Canadian workers belong to a union, compared to about 12% for the US. The US and Canada had about an equal percentage of unionized workers in the 1950s, when changes in US law made it harder for workers to unionize.
There are successful unions for professionals. Check out The Animation Guild, which is part of IATSE. If it came from Hollywood and was animated, an Animation Guild member probably did it. In Redwood City, Dreamworks and EA have facilities in the same building complex, with many people doing similar jobs. Dreamworks is unionized, but EA is not. The Dreamworks people have reasonable hours, unlike the EA peons.
Here's the Animation Guild standard contract. A few key points:
Unionization is about being jerked around less.
Apple doesn't need Macworld because Apple doesn't need fanboys any more.
The Apple fanboy crowd is totally irrelevant to the iPod/iPhone line - those are mass-market consumer products. The laptop product line is aimed more at the status-conscious crowd. Neither market is the Macworld demographic.
Actually, Makay doesn't have a "model"; that 1841 book, which I've been recommending to investors since 2001, is simply a history of the classic early financial crises. Great book; anybody with money or interests in getting some should read it. It describes Version 1 of all the famous disastrous financial schemes, from Law's bank to the South Sea Bubble.
The "ideological assumptions" that were a problem involved deregulation, which got completely out of hand. We used to have a heavily regulated financial system designed during the last depression. Investment and banking were completely separate; banks couldn't speculate in stocks, and brokers couldn't take deposits. This kept stock market problems from taking down banks. That was the Glass-Stegall Act, repealed in 1999.
The US also used to have a savings and loan system that took deposits and sold mortgages, and didn't do much else. Mortgage securitization is quite new; it didn't become big until the mid-1990s. And mortgages used to require a 20% down payment and be limited to under 3x borrower annual income.
US banks used to be unable to lend for stock market speculation. Only brokers could do that, as "margin", and brokers couldn't create money in the way banks can.
With all those constraints in place, the financial system held together better during stock downturns. The dot-com collapse didn't take down banks. Now we have banks going down because they lent to hedge funds.
I just saw the poster presentations from CS 229, Machine Learning, at Stanford. The current batch of projects aren't on line yet, but the ones from previous years are.
The projects were very impressive. A vision-guided autonomous helicopter. A system for separating out instruments and vocals from existing audio. A CAPTCHA solver. De-blurring of out of of focus images. Flower recognition. Recognition of hostile network traffic. And those were just a few of the projects. Machine learning really works now.
I've been using OpenOffice since 1.0, and I'm now on 3.0. I don't think I've used Microsoft Word in the last year, although I still have a valid copy of Word 97 around.
OpenOffice actually works now; it doesn't crash or garble documents. But its interface is painful and amateurish.
With enough effort, you can work around these problems. But this is just a word processor. It should just work. And this is version 3; they've been at this for a decade now.
This is a generic problem with open source user applications. They need real usability testing, where naive users are videoed doing various tasks while commenting on what bugs them. They seldom get it.
Search personalization is of marginal value. In fact, it's kind of a pain, because searches become nonportable and nonrepeatable. If you tell someone else "search for ...", they won't get the same results you did. But advertising personalization... that's where the money is.
Google offers a great range of services and products, but almost all of them lose money.. No Google product other than search advertising makes money, and even that is declining. The Google Content Network (Google ads on non-Google sites) isn't that beneficial to the actual advertisers, and the more savvy advertisers have opted out of it. People click on those ads, but seldom buy. (By default, AdWords customers are opted in, and the opt-out checkbox is hard to find.) Google stock is down 57% from the peak, and revenue is projected to decline for the next three years. So Google is cutting back on new projects, killing off some of the money-losers, and trying to milk their one profitable product, ads on search results, for all they can.
Using search history, it would be straightforward to recognize specific big-ticket buying situations, like "looking for a car" or "looking for a house". This can be used for lead generation. Search for information about cars for a while, and not only do you start seeing car ads all the time, you get phone calls from sales reps.
People like you helping people like us help ourselves. - Processed World
The front-end machines at Google have a set of canned replies for common queries. Most queries to Google are in fact answered by the first front-end machine reached, without invoking the main search engine at all. The size of the front-end cache is considered proprietary, but it's not huge.
Most queries just aren't very original.
The pictures aren't appearing in my browser. Unclear why; some CSS botch or attempt at DRM, I expect. Anyway, here are the actual picture links:
HTML 3.1 - it just works.
Diamond grit, as an abrasive, is currently around $0.07/carat in bulk. It's almost all synthetic, not hard to make, and used for a wide variety of cutting tools. Synthetic diamond production is about 100x mined production. The glamour has gone out of diamond; it's now what sewer workers use on their cutting tools when they need to slice through cement pavement.
CMU has a new process for microwave-annealing diamonds to remove flaws and make colorless synthetic diamonds.
The diamond industry (i.e. DeBeers) painted themselves into a corner, by taking the position that that "flawless" diamonds are the most valuable. That's not where you want to be positioned going up against the industries that make semiconductor wafers.
This all happened to sapphires about sixty years ago. Sapphires used to be rare and valuable. Then Linde Chemical started synthesizing them, and destroyed the market. Now you can buy sapphire bar stock and transparent sapphire plates for supermarket checkout scanners. Since then, it's happened to rubies and emeralds. Now, cheap diamonds.
Why run this out of the Executive Office of the President? Trying to run operational units directly from the White House seldom works well; the environment is political, not operational. The present cybersecurity office, in Homeland Security, is ineffective because the incumbent is a former lobbyist. When Amit Yoran was in charge there, progress was being made. He quit because he wasn't getting backing from higher in Homeland Security. The office needs a high-level champion in the White House, but that's a liasion job.
The problem is that iPhone apps are really plug-ins to a larger application. Nobody makes real money selling plug-ins for any application, phone or otherwise. You're in too inferior a marketing position.
Yes, you can do this, but why bother?
If you actually read Tesla's paper, you find that what he had in mind was powering a small town with a setup where each house had an attic full of antennas to power a 40 watt bulb. The efficiency would be low, and would require excessive power at the generation end. But it would be wireless power transmission.
The basic problem is that you power not only tuned power receivers, but just about anything with a coil anywhere nearby.
Point to point power transmission via microwaves works better. There have been a few demo systems, mostly for point to point power transmissions between islands. It's been tried successfully between Hawaiian islands, on Reunion Island, and between Japanese islands. Of course, it's been discussed for solar power satellites. So far, nobody has found a commercial justification for doing it, but it works.
Put another way, the advances in 2D have tracked with Moore's Law, but 3D is a completely different exponent.
Nah. There's only so much detail you can see. Rendering a really big world is work-bounded by level of detail processing. It's nowhere near O(N^3). If you get to use fog or obstacles to hide distant areas, there's an constant upper bound on the work required, so it's O(1). That's how most older video games do it. Without fog, if you preprocess the model to have low-rez versions of objects for distant display, it's O(log N), which is manageable.
There's some liberal-arts school that teaches Forth as a first programming language. The idea is that it's close enough to the machine to make it clear what's really going on, but abstract enough that you can get reasonable amounts of work done with modest amounts of code. It's like the MIT approach of teaching Scheme; nobody writes much production code in Scheme, but it's a straightforward language with a clear underlying model.
(I'm not recommending writing anything real in Forth at this late date. Twenty years ago I used it for some robotics work, but only because there wasn't a C compiler for the 68HC11 at the time.)
If you're using C++ in such a way that 'pointer==array' matters, you are not using it correctly. C++ has STL & boost/TR1 to provide the standard data structures, smart pointers (C#/Java references) and algorithms you want.
Right. That's the wallpaper over the mold. The C arrays are still there, underneath, and you'll often need them for system calls and I/O. The smart pointer stuff is never airtight, because raw pointers seep out. "auto_ptr" went through about four iterations in the standard, and it still sucked. "auto_ptr" objects also have strange destructive assignment semantics. Reference counted memory allocation is a good idea, but the "smart pointer" systems in C++ never seem to become immune to problems. In Perl and Python, that stuff just works, but bolting it on via templates just doesn't cut it.
Also, if you really want managed memory,, there are GC implementations for C++.
Garbage collection and destructors do not play well together. Microsoft tried really hard to make that work in their "Managed C++", and it was a horror. It's possible in "Managed C++" for a destructor to be called more than once.
It's amusing seeing Strostrup whining that schools are teaching Java instead of his C++. The problem with C++ is Strostrup. He's in denial about many of the fundamental problems of C++. He's publicly stated that there's nothing major wrong with C++. If that was the case, we wouldn't need Java and C#, which are, after all, attempts to improve on C++.
Down at the bottom, the fundamental problem with C and C++ is the "pointer=array" concept. That was OK for 1978, but it didn't scale well. It's the cause of most of the buffer overflows in the world. C and C++ don't even have syntax for properly talking about the size of an array parameter. That's just broken. C and C++ need something like conformant array syntax for parameters and in other contexts where one needs to talk about the size of an array.
The second fundamental problem with C and C++ is that the programmer must obsess on "who owns what", and the language not only doesn't provide help with this, it doesn't even have syntax for talking about it. There's no distinction between a pointer that "owns" an object and one that just "uses" it. Yet if the programmer doesn't carefully make that distinction, the program will have either memory leaks or dangling pointers.
The trend in C++, since templates went in, is to try to wallpaper over the problems with the underlying model. It never quite works; the mold always seeps through the wallpaper. Container classes almost, but not quite, succeed at encapsulation. There's almost always some place where a raw pointer has to be allowed to leak out. The standards committee has gone off on a "generic programming" tangent, with emphasis on weird template features used by few and used correctly by fewer. Just because you can abuse the C++ template system as a term-rewriting engine doesn't mean you should do that in production code. This results in a whole new class of incredibly obscure compile-time bugs. The standards committee has been thrashing for over a decade in this area; in the 1990s, the new version was to be "C++9x"; now it's "C++0x", and since we're close to 2009 already, "C++1x" looks like the reality.
C++ is the only major language to have hiding ("abstraction") without memory safety. No previous language had it, and no later language repeats that mistake.
Back around 2001, I made an effort to do something about it, but the political hassle was more than I had time for.
This is a fascinating effort. Read the research paper.
This is really a little operating system, with 44 system calls. Those system calls are the same on Linux, MacOS (IA-32 version) and Windows. That could make this very useful - the same executable can run on all major platforms.
Note that you can't use existing executables. Code has to be recompiled for this environment. Among other things, the "ret" instruction has to be replaced with a different, safer sequence. Also, there's no access to the GPU, so games in the browser will be very limited. As a demo, they ported Quake, but the rendering is entirely on the main CPU. If they wanted to support graphics cross-platform, they could put in OpenGL support.
Executable code is pre-scanned by the loader, sort of like VMware. Unlike VMware, the hard cases are simply disallowed, rather than being interpreted. Most of the things that are disallowed you wouldn't want to do anyway except in an exploit.
This sandbox system makes heavy use of some protection machinery in IA-32 that's unused by existing operating systems. IA-32 has some elaborate segmentation hardware which allows constraining access at a fine-grained level. I once looked into using that hardware for an interprocess communication system with mutual mistrust, trying to figure out a way to lower the cost of secure IPC. There's a seldom-used "call gate" in IA-32 mechanism that almost, but not quite, does the right thing in doing segment switches at a call across a protection boundary. The Google people got cross-boundary calls to work with a "trampoline code" system that works more like a system call, transferring from untrusted to trusted code. This is more like classic "rings of protection" from Multics.
Note that this won't work for 64-bit code. When AMD came up with their extension to IA-32 to 64 bits, they decided to leave out all the classic x86 segmentation machinery because nobody was using it. (I got that info from the architecture designer when he spoke at Stanford.) 64-bit mode is flat address space only.
Annoyed with the situation on his block in San Francisco, a techie has created Adam's Block, which has an HD camera pointed at a drug dealer corner. You can watch the deals go down. Try expanding the left window to full screen; the HD detail is there.
There's an attached blog and audit trail, and people are logging SFPD cars as they go by.
Fans of the site are waiting for an arrest. Hasn't happened yet.
It's streamed out via Justin.tv, so there's enough bandwidth for Slashdot users to watch.
Consider for example a rendering farm.
Such as ResPower. They've been around for a while, from before the "grid" era (remember the "grid" era?). This is a good example of a service which successfully scales up the number of machines applied to your job based on available resources and load. Unlike a web service, though, ResPower normally runs fully loaded, and charges a daily rate with variable turnaround, rather charging for each render. (They do offer a metered service, but it's not that popular.)
It's worth looking at ResPower because, unlike most of the "grid" or "cloud" services, they have an established customer base and make money.
Python has terrible problems with concurrency. CPython can't use more than one CPU at all, even in multithreaded programs, because of the infamous "Global Interpreter Lock".
In Python, there's too much shared global state associated with binding. The dynamism that makes it possible to add a new function to an object during execution means constant access to object dictionaries shared across threads. Python not only has late binding, it has hidden late rebinding; some other thread can modify an object while control is within an object instance. This is rare, and usually avoidable, but because it's possible and can't be detected at compile time, the run time system has to make the worst case checks every time.
For parallelism, the issue is not functional programming, but single assignment. In a single-assignment language, each variable can only be changed once. Functional programming is one way of achieving this, but it's not the only way.
The idea is supposed to be that single assignment makes it easy to turn a program into a pipelined form at compile time. It's supposed to make automatic parallelization easier. In practice, compilers for single-assignment languages haven't been overly impressive in performance.
Supercomputing is mostly a Government-funding boondoggle. The private sector buys few if any supercomputers.
Most of the US government applications are either related to nuclear weapons, or are busywork for underutilized nuclear weapons labs. Sandia, Los Alamos, and Livermore, lacking bombs to design, are looking for something else to justify their continued existence. To some extent, they're senior activity centers for old physicists. There's also "stockpile stewardship", which is an activity center for younger physicists. The idea is to keep some people around who can build an H-bomb if necessary, so that the technology isn't lost as people die off. Since that crowd isn't allowed to actually do much of anything, they want to simulate a lot. It's really a political problem. If the US and Russia allowed each other one underground bang each year, there would be less need for all this iffy simulation.
So don't worry too much about whining from Sandia about supercomputers. When Google or Amazon start complaining that multicore machines are choking in their server farms, it's time to listen.
Rather than laptops with zillions of CPU cores, we're probably going to see CPU chip real estate used for more cache, and maybe even main memory. The near future is the one-chip laptop that sells for $100 or so.
Domain registrars come in several tiers.
MarkMonitor is in the business of protecting "brands", so they have lawyers and technicians on staff to swing into action if somebody pulls something. If you have to ask how much they cost, you can't afford them.