If your goal is to create a "production system" of some sort, then you should pick pretty carefully from one of the following lists:
A scripting language, with Bash, being really ubiquitously available, being a good first choice, and fallback options being Perl, Python, PHP, Ruby
A "compiles-to-native" language, either C or C++
If you favor dynamic frameworks, then Java.
(Or perhaps Mono...)
If you are trying to learn, are in a position to consider the results "throwaway code," and are interested in learning programming concepts, then you should look quite a bit more widely:
For heavy concurrency, consider Erlang
And it would be well worth taking a side-trip to do something non-trivial in Prolog to see how backtracking works.
If you want something that compiles down to pretty fast object code that might be a bit stricter than C or C++, then it would be well worth taking a peek at Modula-3, Ada, or Eiffel.
It would be well worth taking a look at Common Lisp and/or Scheme, as they offer considerably different object models from what is "traditional" in C++/Java, and, as long as you don't merely play the academic game of "just doing list processing" or "just doing recursion", you can learn some very different approaches to programming.
Icon was the string processing language from the makers of SNOBOL that looks quite a lot like C (which SNOBOL doesn't!), and which introduced, to computer languages, having generators (which Ruby & Python have since adopted, and which you can also find in the Common Lisp SERIES package), as well as coroutines, which are a more event-driven-ish way of handling concurrency (probably nicer than threads).
Haskell or OCAML provide more "conventional" (e.g. - somewhat more Algol/C-shaped) views on functional programming than do Lisp or Prolog, and have interesting bits to them.
th respecting understand this simple fact.At the end of the day, with so many excellent relational databases available at zero or little cost, choosing MySQL as your database speaks poorly of you. Just about any database is better than MySQL.
True though that may be, there are quite a lot of people running databases not because they want to develop a new application, in which case, yes, indeed, "choosing worst options speaks poorly of them," but rather because they want to run Application X, where someone else (whom we might speak poorly of!) wrote Application X to only be compatible with the "worse options."
But PostgreSQL is a great option, so why would people spend so much effort trying to rebuild the MySQL developer base from scratch? That's a spectacularly good point that proponents of the "faith in the GPL" position seem wont to miss.
Yes, indeed, if MySQL AB (or Sun) suddenly "turn evil" (and as Sun hasn't got the most spectacularly positive history with any of their acquisitions; name one?), this introduces the problem that fans of MySQL(tm), which would probably need to change its name (as happened when Interbase became Firebird), would need to recreate a developer base as well as organizational reputation from zero.
It might be apropos to compare to SAP-DB aka MaxDB, which, when "open sourced," engaged rather little enthusiasm, even though it had plenty of functionality that MySQL(tm) doesn't have yet. There was no choice but to engage paid developers whose job it was to maintain it. It never developed such "organizational reputation" in the Open Source community.
Mozilla looks like a pretty big success, independent of former parent, Netscape, but it took years of very active sponsorship for that to happen.
I could easily see an "Independent MySQL Fork" being destined for failure.
I guess it's time to see if PostgreSQL's documentation and tools have managed to get any less user-hostile over the years. In 8.3, the "contrib" docs have been integrated into the main SGML documentation base, which seems pretty helpful.
Whether or not to regard this as "user-hostile" seems to be very much in the eye of the beholder. There's the old joke that "Unix is user friendly; it's just a bit selective about its friends" which seems likely to apply pretty well.
To my mind, it's fairly "friendly," notably from the perspective that it's not got the frightening quantities of version-dependent caveats that I frequently see when browsing MySQL documentation. (Of course, those caveats tend to be driven by wild variations in functionality between storage engines...)
The one remaining question is mindshare. For example, pretty much every ISP offers MySQL as part of a basic hosting package. No one's saying they have to stop doing that, but are they going to start offering other open source DBMSs in the same way now? I sure hope so. My hosting service (a2) offers both. Now there are obviously a lot of the built-in apps that are entirely MySQL-specific (e.g. - such as WordPress and such), but PostgreSQL is there.
No, not the "entire FOSS" community
on
SCO Loses
·
· Score: 1
The entire FOSS community thanks you for your skill and all the hard work and thanks go to Novell for being willing to see this through."
No, this is not something relevant to "the entire FOSS" community. For instance, if SCO had had more success, and this had adversely affected Linux (e.g. The Kernel), this would have generally led to migrations to the various BSD-based systems.
And adoption is, of course, a two-edged sword for those already in such communities; to some degree, the popularity of Linux draws in "bozos" that the BSD folk would rather not have around. There are remappings of the following that are possible:-).
"Huh? Windows was designed to keep the idiots away from Unix so we
could hack in peace. Let's not break that." -- Tom Christiansen
I'm more involved, these days, with the PostgreSQL community; the SCO lawsuits were fairly much irrelevant to that community, from some standpoints.
I don't think you understand B-trees if you are assuming log base 2 numbers of comparisons.
In most systems (probably even including MySQL), a B-tree is an index structure consisting of sets of pages. Each page might be (say) 8K long, so that if the index value were (say) 16 bytes long, you could fit somewhere on the order of 512 index entries on each page.
In that case, the number of index accesses required to access "billions" of rows would be log (base 512) (10^9), so you'd expect to hit the desired tuple in 3-4 page accesses.
(Obviously, if the number of tuples per page is lower or higher, the base for the logarithm changes...)
It is worth observing that Gasperson recently solicited "Top 3" reasons to pick MySQL(tm) in a LinkedIn Discussion recently.
A goodly number of pro and con arguments were presented there; Tina evidently sought to glean the ones that she could keep as unambiguous ones. She failed, on the "price" one, in that most of the other OSS database systems don't have a MySQL AB ready to collect licensing fees from you...
There's an excellent reason not to enable these sorts of integrity constraints, by default: Because it would, by default, break a whole lot of the traditional web applications that expect version 3 style behaviour.
If they had version 6 "break with historical stupidity," that would forcibly break compatibility with legacy applications, and it would pretty much eliminate any argument for remaining with MySQL.
After all, if the migration to version 6 requires rewriting your applications, isn't that a "breakage" significant enough to cause decision makers to say: "Hmm. They're requiring me to rewrite my applications. At this point, there isn't any reason not to open my choices wider, and consider other DBMSes, is there?"
That's one of the reasons, I expect, that Windows Vista didn't have so many Longhorn features in it; if it's fundamentally a totally new (and significantly incompatible) platform requiring substantial redesign of applications, people will think more than twice about adopting it. The same sorts of things hold true.
It's all well and good to add a "be careful with my data now" setting, but that's pretty much a pyrrhic victory if it makes all the old applications break...
If using this setting requires major remedies to revise applications and retune them, that may be no less work than redeploying on something that has mature support for data integrity...
The handling of "large columns" gets a bit better in Slony-I 1.2; in earlier versions, the replication engine would blindly grab groups of 100 tuples into memory to get ready to replicate them. If you have big columns with 50MB of data in them, this could lead to loading 5000MB of data into memory, and then throwing it across the wire to replicate it. What with a couple copies getting made (the copy loaded into memory, then turned into a query to be submitted to the subscriber), this could lead to a pretty large memory footprint.
One user regularly hits cases like that, and actually wound up upgrading his replication servers to have >32GB of memory to support this.
In 1.2, that case largely goes away. Large tuples aren't immediately loaded into memory; those larger than a (configurable) threshold get left on disk, to be pulled one by one. One might imagine that to be a possible source of inefficiency, but consider, you've got an insert that's loading 50MB of data into one tuple. There is no amount of index scanning that can possibly be material beside that!
Slony-I most certainly does support replicating "large data;" what it doesn't support is the Large Object interface, which is one that essentially amounts to having a UNIX I/O API sitting on top of SQL. There are doubtless users of Large Objects out there; the "user interface" is arcane enough that sensible people usually prefer to store large amounts of data as plain old columns that get TOASTed...
This effect is already taking place; what with the population of usefully competent people of India having been heavily "mined" by existing "outsourcing" and foreign hiring, it is no longer the case that India is a clear "bargain."
That is why there have been further pursuits of outsourcing opportunities in China and Russia, and even places a bit further "off the already beaten path," essentially because once the "beaten path" has gotten "beaten," you're left with either bidding prices up, or fighting over those that didn't get reasonably decent educations.
The third possibility, of course, is to spend on infrastructure, but that's an activity with a pretty huge latency time, high risk, and no short term payoff. Indeed, in order to get real benefits, it may be necessary to invest, on the educational side of things, in institutions going all the way down to the elementary level, which means a latency of ~15 years before there are commercially meaningful results.
In order to change the schools, you might have to pay good people to teach, rather than getting other immediately-valuable results, thereby eating into your potential benefits.
I don't think there's any easy way out of the relevant quagmires...
SCTV proposed this for several of the Monster Chiller Theatre presentations; you send in $20 (or so) and get aerosol cans filled with scents, and when you see the blue dot on the screen, spray yourself with the blue can.
Lotus Notes has many things clumsy about it, but one thing it was pretty good at was storing encrypted replicable documents.
The notion here would be that your documents would get stored in Notes as "syncable" objects. Any time you connect to the central server, you can push/pull updates, which may be (optionally) stored in encrypted form.
If your laptop blows up due to bad batteries or gets ripped off at the airport, there are therefore two huge merits:
You only lose the document updates since the last SYNC. Cleaning up is as easy as connecting up a new laptop and running the SYNC process.
The documents are encrypted, which, if the password isn't particularly guessable, should make it at least somewhat challenging for thieves to steal data.
There's something suspicious about the missing car seat, but the findings of blood strike me as less than "total proof of guilt."
It is not evident from the reports what kind of sensitivity the blood tests had, which is an issue. If you searched about my apartment, you'd find some of my blood here and there, due to a nose bleed or two. I, of course, am not dead, it would be downright silly to conclude, from the finding of blood, that I had been murdered. I don't know to what degree the police findings suggest any particular action at all.
I'd frankly expect there to be some blood found in a number of places in the Reiser "matrimonial home." Women have a monthly cycle that involves some emission of blood, which would be likely to leave a "trail" in the bathroom, and which could show up elsewhere. Uncareful kitchen work with knives could leave some blood there.
At the more unfortunate end of things, if things had gotten heated between the Reisers, a physical blow could induce (say) a nose bleed. That could well represent a criminal act, and cause the things seemingly observed by police, but not, in fact, be murder.
I'm not looking to find Hans Reiser innocent, or guilty; that's not my place. I don't know if he killed his wife; if he did, then, barring pretty wild circumstances, he's presumably guilty of murder. If he didn't do it, then he's not. There is a whole lot unfortunate about the situation, regardless.
What has been publicized thus far does not point particularly strongly at any option yet being most probable.
The "long tunnel inside the Earth" idea is a pretty good notion, save for the problem of bumping your head as soon as the capsule hits atmosphere at Mach-whatever. When the capsule strikes the atmosphere at the enormously-high "muzzle velocity," you'd get crushed by that enormous force.
This is a wonderful idea for launching solid materials that can be packed in tightly that can survive the application of enormous forces. If they're outright solid, that's super.
The only way I could see human survival is if you were immersed entirely in water during the course of the "hit the atmosphere" part. But my suspicion is that significant bubbles of air (e.g. - lungs) would be troublesome.
It doesn't have to be "man-rated" to be highly useful; if you can fire solid materials into orbit for pennies per kilogram, as well as water, that improves the economics spectacularly.
There has been an
example presented on this, already. A GPU can be useful for doing large sorts, which is something databases tend to do quite often in complex queries. It was a win if there was more than 1MB of data to sort.
The benefit comes in that the GPU is tightly connected to a bunch of fast RAM that isn't being competed over by the general purpose CPU(s).
So, you throw 128MB or such of data onto the GPU, and you can get it sorted several times faster than a regular CPU could do it. Presumably, more onboard memory could give even more of a win.
What PHP code I have read has been pretty consistent with a "COBOL-like" view of the world. The only PHP package I seriously "reviewed" was a library system where each possible form and each response thereof was expressed as a separate PHP file, all of them "templated" in the common COBOL fashion where it looked like the programmer had only ever written one program, and then copied it, over and over, once for each web page in the application.
(I have worked with ex-COBOLers; duplicating the deck was a real common approach...)
This of course suffers from the problem that if you decide that you need to change the background colour, you need to modify it in 83-odd.php files.
Nothing about this implies that PHP programmers are forced into such ghastly habits, but I do tend to find habits repeated:-(.
Back in the day, what really happened was that MySQL chose simple. In some cases, that happened to be faster.
PostgreSQL has been getting pretty steadily faster; MySQL has been steadily adding additional database engines. The paucity of published benchmarks suggests that the latter probably hasn't helped performance; the confusion that results from having too many subtly incompatible features to choose from doesn't suggest that it's getting "better" terribly quickly.
If composition of the encryption algorithm with itself represents a group, then encrypting multiple times is simply equivalent to encrypting once, using a different key.
You can pretty easily see this with linear congruential methods; it's harder to prove this sort of thing for the common encryption algorithms.
The whole reason why people adopted 3DES, which is a three-time superencryption application of DES, is that DES is not a group for multiple applications, meaning that you do get "more encryption" when you apply it multiple times.
We don't know what algorithm was being used in the original poster's situation, so we have no idea whether multiple applications of the algorithm do any extra good or not.
If it "is a group," then multiple applications are completely worthless. If it isn't, then multiple applications might be hoped to provide some additional strength, but we don't know offhand whether an extra 64 bits of key provides 1 bit worth of extra protection, or if it provides a full 64 bit improvement.
As much as it nicely rhymes with "Bloated Goats," for mobile users, the ability to stow your documents in an encrypted, replicated data store is worth rather a lot.
It represents a decent answer to the "oops, someone stole my laptop at the airport" problem in that it offers both a quick recovery process and some protection that the stealers should not get at your data.
I'll be very curious as to what happens with respect to document management, whether they'll be supporting OpenOffice.org, or if there's either some other strategy (SmartSuite for Linux???), or a lack of strategy...
replace the scheduler with parallelizing operators.
replace the filesystem with collections."
Sounds a lot like a Lisp environment to me... That means that the "components" are actually function references, which can do fairly much anything. The environment then consists of a set of object references, which is definitely like your notion of "collections."
I'm not so sure about the notion of "parallelizing operators;" concurrent programming has always been hard, fundamentally because it's harder to understand nondeterministic processes than those that are deterministic.
I certainly would agree that this is a different approach from the present tendancy towards "Unix everywhere."
The trouble is that bootstrapping becomes problematic. If you build something that is more or less like Unix, then you've got compilers, file utilities, program editors, SCM tools, and all such, "for free." If you build something that is different enough, then there are two choices:
Your system is built using Unix-like sets of tools, and is target-compiled for the desired environment. You're forever dependent on Unix.
Alternatively, if you're trying to self-host, then you've got a five year project to build compilers, code management tools, graphical environment tools, and hardware drivers, pretty much all before you get to the real project of building the OS. And you're left chasing hardware compatibility, because the hardware that's cheap and available today will be replaced by new models that won't be 100% compatible a year from now.
When they jumped into building NT workstations, that was a clear "desperation move." In retrospect, it is clear that it was a bad move, but it is not clear what would have been a conspicuously better move.
They had to do something, and, as a public company, the management had to be seen to be doing something.
One could argue that "going Linux" some time earlier could have had some merit; I don't think that's self-evident, nor is it clear how going down that road would have kept them from going under.
In effect, they got nibbled to death from various sides.
nVidia built graphics hardware that made it possible to get "near SGI-class" graphics on pedestrian PCs.
The Gartner Group was pushing "Itanium! Itanium! Itanium!" as the only 64 bit architecture that would survive, leaving MIPS out in the cold. Gartner was wrong; it's more like "Itanic"...
But SGI did jump on the IA-64 bandwagon, to their loss...
The only UNIX vendors that are retaining market share are IBM and Sun; the others are watching share erode to Linux...
It's not clear how SGI could have "harnessed" Linux to keep market share for Irix or for high end SGI hardware...
The point of the contest isn't to produce unbreakable coffee cups; it is to produce engineers that know how to solve engineering problems.
Arguably, their solution represents a bending of the rules; if that is the case, then this should presumably lead to the rules being modified next year so as to prevent this "abuse."
But personally, I don't think it represents an "abuse." The students decided to take a different approach as to where they would apply their "high technology." In most cases, the participants tried to create fancier forms of ceramics; these guys applied their problem solving skills to other aspects of the problem, and did so sufficiently well that they got a second place finish with a material that was consciously and by design inferior to the ceramics used by other teams.
This reminds me of the technology choices made in Vinge's A Fire Upon The Deep. In that book, they had "slow" and "fast" zones, where computers were either virtually useless and stupid, or, in the "High Beyond," potentially god-like in their powers. Ship designs would vary considerably depending on where they were going. The protagonist's ship winds up getting a redesign along the way, where it is designed, by one of the "god-like" Powers, to perform particularly well in the Slow Zones. This winds up involving using low-technologies (short on computing power, and such) with High Beyond "elegance."
The analogy here should be obvious: our intrepid New Mexicans were using fired clay (a low technology) with a great deal of design thought having gone into how the device was built.
If it was clear, to the judges, that there was a great deal of design work that went into it, it seems to me that it is not at all unfair that the entry won.
Are you sure it's "free market capitalism" that they want to spread?
Or something that at some level resembles that enough that they could call it such, whilst actually being neither free (as most participants are realistically indentured slaves), a market (since only one or two companies control 100% of the sales), or capitalism (as the benefits would accrue to people with political capital... Oh well, I guess I'm wrong about that one...)...
... If Count Dooku had not been consciously Sith-influenced, but rather an honest "loyal opposition."
This would have required only minimal changes to the sequencing of things, and could have shown off off the fall of the Old Republic as an honest-to-goodness tragedy. Having the Sith successfully playing off two honestly well-intentioned sides against each other could have worked out excellently well.
What was also unfortunate is that little more than lip-service was paid to the various "failures of democracy." It seemed to me that when Dooku explained, in Kenobi's earshot, why he was collecting up forces to oppose what was going on in the parliament, he had some pretty legitimate reasons for concern.
Unfortunately, all we saw, after the various "things failing," was that people seized at power of one sort or another to respond to them. What perhaps wasn't clear enough was that seizure of power was, in every case, a mistake.
Slashdot Mirror
(Or perhaps Mono...)
And it would be well worth taking a side-trip to do something non-trivial in Prolog to see how backtracking works.
There are a lot of interesting computer languages out there!
th respecting understand this simple fact.At the end of the day, with so many excellent relational databases available at zero or little cost, choosing MySQL as your database speaks poorly of you. Just about any database is better than MySQL.
True though that may be, there are quite a lot of people running databases not because they want to develop a new application, in which case, yes, indeed, "choosing worst options speaks poorly of them," but rather because they want to run Application X, where someone else (whom we might speak poorly of!) wrote Application X to only be compatible with the "worse options."
Yes, indeed, if MySQL AB (or Sun) suddenly "turn evil" (and as Sun hasn't got the most spectacularly positive history with any of their acquisitions; name one?), this introduces the problem that fans of MySQL(tm), which would probably need to change its name (as happened when Interbase became Firebird), would need to recreate a developer base as well as organizational reputation from zero.
It might be apropos to compare to SAP-DB aka MaxDB, which, when "open sourced," engaged rather little enthusiasm, even though it had plenty of functionality that MySQL(tm) doesn't have yet. There was no choice but to engage paid developers whose job it was to maintain it. It never developed such "organizational reputation" in the Open Source community.
Mozilla looks like a pretty big success, independent of former parent, Netscape, but it took years of very active sponsorship for that to happen.
I could easily see an "Independent MySQL Fork" being destined for failure.
To my mind, it's fairly "friendly," notably from the perspective that it's not got the frightening quantities of version-dependent caveats that I frequently see when browsing MySQL documentation. (Of course, those caveats tend to be driven by wild variations in functionality between storage engines...)
The one remaining question is mindshare. For example, pretty much every ISP offers MySQL as part of a basic hosting package. No one's saying they have to stop doing that, but are they going to start offering other open source DBMSs in the same way now? I sure hope so. My hosting service (a2) offers both. Now there are obviously a lot of the built-in apps that are entirely MySQL-specific (e.g. - such as WordPress and such), but PostgreSQL is there.No, this is not something relevant to "the entire FOSS" community. For instance, if SCO had had more success, and this had adversely affected Linux (e.g. The Kernel), this would have generally led to migrations to the various BSD-based systems.
And adoption is, of course, a two-edged sword for those already in such communities; to some degree, the popularity of Linux draws in "bozos" that the BSD folk would rather not have around. There are remappings of the following that are possible :-).
"Huh? Windows was designed to keep the idiots away from Unix so we
could hack in peace. Let's not break that." -- Tom Christiansen
I'm more involved, these days, with the PostgreSQL community; the SCO lawsuits were fairly much irrelevant to that community, from some standpoints.
In most systems (probably even including MySQL), a B-tree is an index structure consisting of sets of pages. Each page might be (say) 8K long, so that if the index value were (say) 16 bytes long, you could fit somewhere on the order of 512 index entries on each page.
In that case, the number of index accesses required to access "billions" of rows would be log (base 512) (10^9), so you'd expect to hit the desired tuple in 3-4 page accesses.
(Obviously, if the number of tuples per page is lower or higher, the base for the logarithm changes...)
A goodly number of pro and con arguments were presented there; Tina evidently sought to glean the ones that she could keep as unambiguous ones. She failed, on the "price" one, in that most of the other OSS database systems don't have a MySQL AB ready to collect licensing fees from you...
If they had version 6 "break with historical stupidity," that would forcibly break compatibility with legacy applications, and it would pretty much eliminate any argument for remaining with MySQL.
After all, if the migration to version 6 requires rewriting your applications, isn't that a "breakage" significant enough to cause decision makers to say: "Hmm. They're requiring me to rewrite my applications. At this point, there isn't any reason not to open my choices wider, and consider other DBMSes, is there?"
That's one of the reasons, I expect, that Windows Vista didn't have so many Longhorn features in it; if it's fundamentally a totally new (and significantly incompatible) platform requiring substantial redesign of applications, people will think more than twice about adopting it. The same sorts of things hold true.
If using this setting requires major remedies to revise applications and retune them, that may be no less work than redeploying on something that has mature support for data integrity...
One user regularly hits cases like that, and actually wound up upgrading his replication servers to have >32GB of memory to support this.
In 1.2, that case largely goes away. Large tuples aren't immediately loaded into memory; those larger than a (configurable) threshold get left on disk, to be pulled one by one. One might imagine that to be a possible source of inefficiency, but consider, you've got an insert that's loading 50MB of data into one tuple. There is no amount of index scanning that can possibly be material beside that!
Slony-I most certainly does support replicating "large data;" what it doesn't support is the Large Object interface, which is one that essentially amounts to having a UNIX I/O API sitting on top of SQL. There are doubtless users of Large Objects out there; the "user interface" is arcane enough that sensible people usually prefer to store large amounts of data as plain old columns that get TOASTed...
That is why there have been further pursuits of outsourcing opportunities in China and Russia, and even places a bit further "off the already beaten path," essentially because once the "beaten path" has gotten "beaten," you're left with either bidding prices up, or fighting over those that didn't get reasonably decent educations.
The third possibility, of course, is to spend on infrastructure, but that's an activity with a pretty huge latency time, high risk, and no short term payoff. Indeed, in order to get real benefits, it may be necessary to invest, on the educational side of things, in institutions going all the way down to the elementary level, which means a latency of ~15 years before there are commercially meaningful results.
In order to change the schools, you might have to pay good people to teach, rather than getting other immediately-valuable results, thereby eating into your potential benefits.
I don't think there's any easy way out of the relevant quagmires...
SCTV proposed this for several of the Monster Chiller Theatre presentations; you send in $20 (or so) and get aerosol cans filled with scents, and when you see the blue dot on the screen, spray yourself with the blue can.
As Count Floyd discovered, "Very Scary!!!"
The notion here would be that your documents would get stored in Notes as "syncable" objects. Any time you connect to the central server, you can push/pull updates, which may be (optionally) stored in encrypted form.
If your laptop blows up due to bad batteries or gets ripped off at the airport, there are therefore two huge merits:
It is not evident from the reports what kind of sensitivity the blood tests had, which is an issue. If you searched about my apartment, you'd find some of my blood here and there, due to a nose bleed or two. I, of course, am not dead, it would be downright silly to conclude, from the finding of blood, that I had been murdered. I don't know to what degree the police findings suggest any particular action at all.
I'd frankly expect there to be some blood found in a number of places in the Reiser "matrimonial home." Women have a monthly cycle that involves some emission of blood, which would be likely to leave a "trail" in the bathroom, and which could show up elsewhere. Uncareful kitchen work with knives could leave some blood there.
At the more unfortunate end of things, if things had gotten heated between the Reisers, a physical blow could induce (say) a nose bleed. That could well represent a criminal act, and cause the things seemingly observed by police, but not, in fact, be murder.
I'm not looking to find Hans Reiser innocent, or guilty; that's not my place. I don't know if he killed his wife; if he did, then, barring pretty wild circumstances, he's presumably guilty of murder. If he didn't do it, then he's not. There is a whole lot unfortunate about the situation, regardless.
What has been publicized thus far does not point particularly strongly at any option yet being most probable.
This is a wonderful idea for launching solid materials that can be packed in tightly that can survive the application of enormous forces. If they're outright solid, that's super.
The only way I could see human survival is if you were immersed entirely in water during the course of the "hit the atmosphere" part. But my suspicion is that significant bubbles of air (e.g. - lungs) would be troublesome.
It doesn't have to be "man-rated" to be highly useful; if you can fire solid materials into orbit for pennies per kilogram, as well as water, that improves the economics spectacularly.
The benefit comes in that the GPU is tightly connected to a bunch of fast RAM that isn't being competed over by the general purpose CPU(s).
So, you throw 128MB or such of data onto the GPU, and you can get it sorted several times faster than a regular CPU could do it. Presumably, more onboard memory could give even more of a win.
This of course suffers from the problem that if you decide that you need to change the background colour, you need to modify it in 83-odd .php files.
Nothing about this implies that PHP programmers are forced into such ghastly habits, but I do tend to find habits repeated :-(.
PostgreSQL has been getting pretty steadily faster; MySQL has been steadily adding additional database engines. The paucity of published benchmarks suggests that the latter probably hasn't helped performance; the confusion that results from having too many subtly incompatible features to choose from doesn't suggest that it's getting "better" terribly quickly.
You can pretty easily see this with linear congruential methods; it's harder to prove this sort of thing for the common encryption algorithms.
The whole reason why people adopted 3DES, which is a three-time superencryption application of DES, is that DES is not a group for multiple applications, meaning that you do get "more encryption" when you apply it multiple times.
We don't know what algorithm was being used in the original poster's situation, so we have no idea whether multiple applications of the algorithm do any extra good or not.
If it "is a group," then multiple applications are completely worthless. If it isn't, then multiple applications might be hoped to provide some additional strength, but we don't know offhand whether an extra 64 bits of key provides 1 bit worth of extra protection, or if it provides a full 64 bit improvement.
It represents a decent answer to the "oops, someone stole my laptop at the airport" problem in that it offers both a quick recovery process and some protection that the stealers should not get at your data.
I'll be very curious as to what happens with respect to document management, whether they'll be supporting OpenOffice.org, or if there's either some other strategy (SmartSuite for Linux???), or a lack of strategy...
Sounds a lot like a Lisp environment to me... That means that the "components" are actually function references, which can do fairly much anything. The environment then consists of a set of object references, which is definitely like your notion of "collections."
I'm not so sure about the notion of "parallelizing operators;" concurrent programming has always been hard, fundamentally because it's harder to understand nondeterministic processes than those that are deterministic.
I certainly would agree that this is a different approach from the present tendancy towards "Unix everywhere."
The trouble is that bootstrapping becomes problematic. If you build something that is more or less like Unix, then you've got compilers, file utilities, program editors, SCM tools, and all such, "for free." If you build something that is different enough, then there are two choices:
That's a tough road to go down...
They had to do something, and, as a public company, the management had to be seen to be doing something.
One could argue that "going Linux" some time earlier could have had some merit; I don't think that's self-evident, nor is it clear how going down that road would have kept them from going under.
In effect, they got nibbled to death from various sides.
But SGI did jump on the IA-64 bandwagon, to their loss...
It's not clear how SGI could have "harnessed" Linux to keep market share for Irix or for high end SGI hardware...
Arguably, their solution represents a bending of the rules; if that is the case, then this should presumably lead to the rules being modified next year so as to prevent this "abuse."
But personally, I don't think it represents an "abuse." The students decided to take a different approach as to where they would apply their "high technology." In most cases, the participants tried to create fancier forms of ceramics; these guys applied their problem solving skills to other aspects of the problem, and did so sufficiently well that they got a second place finish with a material that was consciously and by design inferior to the ceramics used by other teams.
This reminds me of the technology choices made in Vinge's A Fire Upon The Deep. In that book, they had "slow" and "fast" zones, where computers were either virtually useless and stupid, or, in the "High Beyond," potentially god-like in their powers. Ship designs would vary considerably depending on where they were going. The protagonist's ship winds up getting a redesign along the way, where it is designed, by one of the "god-like" Powers, to perform particularly well in the Slow Zones. This winds up involving using low-technologies (short on computing power, and such) with High Beyond "elegance."
The analogy here should be obvious: our intrepid New Mexicans were using fired clay (a low technology) with a great deal of design thought having gone into how the device was built.
If it was clear, to the judges, that there was a great deal of design work that went into it, it seems to me that it is not at all unfair that the entry won.
Or something that at some level resembles that enough that they could call it such, whilst actually being neither free (as most participants are realistically indentured slaves), a market (since only one or two companies control 100% of the sales), or capitalism (as the benefits would accrue to people with political capital... Oh well, I guess I'm wrong about that one...)...
This would have required only minimal changes to the sequencing of things, and could have shown off off the fall of the Old Republic as an honest-to-goodness tragedy. Having the Sith successfully playing off two honestly well-intentioned sides against each other could have worked out excellently well.
What was also unfortunate is that little more than lip-service was paid to the various "failures of democracy." It seemed to me that when Dooku explained, in Kenobi's earshot, why he was collecting up forces to oppose what was going on in the parliament, he had some pretty legitimate reasons for concern.
Unfortunately, all we saw, after the various "things failing," was that people seized at power of one sort or another to respond to them. What perhaps wasn't clear enough was that seizure of power was, in every case, a mistake.