Good point. I think we'll just have to suspend our disbelief here, since with my limited imagination I can't think a valid answer to either the computation or power problems. Looks like no gloopy metal robots for us anytime in the near future!
In fact, the power needed to run the T-1000's computations pales in comparison with the energy required to move all of that metal around. I can think of two ways to get that much power:
1) "Eat" organic matter you find in the environment and metabolize it to produce energy.
2) Carry an onboard power plant, such as a fusion or antimatter reactor.
In either case, individual computation units could be equipped with super-high-density storage batteries, so they could survive away from the power plant for short periods of time. This suggests, of course, that computation units are much bigger than a single molecule.
Is this just an off-the-cuff remark, or did T3 actually mention this fact to the viewers sometime during the movie? If so, can you remember how it was phrased?
Obviously, the TX was a refinement of and an improvement on the T-1000 and its "gloopy metal" construction. But aside from mentioning that the T-1000 used a decentralized computing architecture, they never got down to specifying where inside all that gloop the computation was taking place...I guess we were supposed to believe that every molecule of the metal was somehow contributing toward the running of the T-1000.
Come to think of it, acting like a T-1000 doesn't take much computing power. I bet my desktop PC could do it! All it needs to do is say "Get out" and "Tell me where this boy is" in a monotone, and randomly stab people. Should be a binch!
W.R.T. the lobby scene, good point -- now that I think about it, the two scenes are very visually similar. But how can you not see the symbology in the "Do not use lift if there is a fire" sign on the elevator door in The Matrix? Clearly, this is the Wachowski's way of reminding us that causality rules supreme, that all actions have their consequences! (Just kidding. The elevator scene is just another cinematic shiny bit, dangling in front of the viewer's eyes.)
W.R.T. to Kusanagi being ordinary: a being's notion of ordinariness depends on context. Within the context that Kusanagi is familiar with, she is an ordinary cyborg. She and her team are perhaps more highly skilled than other members of the same force, who are in turn very different from ordinary citizens. But Kusanagi is not fundamentally different from her peers. Or so she thinks.
When Kusanagi finds out that she is in fact far from ordinary, your perception of what makes "Kusanagi" is radically altered, but your (and her) perception of the world in which she lives, is fundamentally the same as it was before.
Compare this with The Matrix, where you need to rethink not only your ideas about Neo, but your ideas about the world(s) in which he lives, multiple times.
I hope this makes sense...I'm trying to be deliberately vague on specific plot points, in order to avoid spoilers.
Sorry, how does it follow that Wachowskis plagiarized GITS? I'm not defending the Wachowskis -- Matrix is already a rip-off of about a dozen schools of western, eastern, ancient and modern philosophy -- but the storylines seem largely divergent.
GITS:
Some chick thinks she's an ordinary chick living in an ordinary world
Chick gets mixed up in something big
Chick turns out to be VERY un-ordinary
...but she's living in an ordinary world (i.e. not fundamentally different from the world she thought she was in before)
Matrix:
Some dude thinks he's an ordinary dude living in an ordinary world
Dude gets mixed up in something VERY big (earth-shattering)
Dude turns out to be VERY un-ordinary
...and the world he's living in is fundamentally different from what he thought
I think you've hit the nail on the head here. The real problem with a retail PPC port of Windows is that there's no target market!
Anyone with a PPC system is already a huge Mac fan, and anybody looking to buy a speedy Windows system is going to buy Intel hardware at 75% of the cost. Anyone who wants to run MacOS server applications on Intel hardware can simply run GNU Darwin.
The real market is to be found in the millions of Intel users who want to get their hands on MacOS, but don't want to shell out the greenbacks for premium-priced Apple PPC hardware, and/or who don't feel comfortable with Apple's "don't look inside the box" mentality.
Re:One word that kill Atkins for me.
on
Hackers On Atkins
·
· Score: 1
Call them back and ask about the glycemic index of Guinness. The glycemic index is a measure of the net effect of the sugars and carbs found in a given food on your metabolism. The higher a food's glycemic index number, the more readily your body assimilates the calories from carbohydrates contained in the food, and the more it tends to make you crave more food.
Sugar isn't all that bad for you, calorie-wise. The problem is that sugar -- and other substances with a high glycemic index -- cause you to become hungrier, which makes you eat more overall.
I'm no expert in this stuff -- it's all hearsay from my three roommates, who are on the South Beach diet and have lost a total of 180 lbs between them so far.
I lost my own weight -- almost 120 lbs of it -- using The Hacker's Diet, back in 1999 before it was trendy. Simply counting calories and getting plenty of exercise seemed to work fine for me. But my roommates have been losing weight faster than I ever did, and their figures have been improving at a rate that outstrips their weight loss (i.e. they seem to be losing fat without losing so much muscle).
Microsoft has taken the first step toward removing the binary compatability burden from their vendors' shoulders by introducing.NET as their blessed-from-on-high development platform.
Inherent to.NET, of course, is the write-once-run-anywhere concept. IMHO this mentality comes just in time, as we are on the doorstep of 64-bit computing, at which time the latest architecture from a given vendor (Intel or AMD, take your pick) will no longer be compatible with the previous generation of chips. Ready or not, Windows is about to support multiple architectures.
Transmeta has proven that one can achieve non-native compatability (i.e. without building a compatability mode into the silicon); this, combined with the tremendous amount of research that's gone into virtualization and emulation since the mid 90s means that it's no longer a pipe dream to dynamically translate code between architectures. This is especially true if you're translating a binary that targets the same underlying API, and the API is designed to abstract away the BIOS and other architecture-dependent parts of a computer.
I'm not saying that we'll see a PPC port of Windows sold in stores -- I agree with you that it's about as likely as Bill Gates slapping a penguin bumper sticker on his car. I'm just saying that the technical obstacles that killed off Alpha/PPC Windows have since been surmounted.
Re:One word that kill Atkins for me.
on
Hackers On Atkins
·
· Score: 2, Interesting
Surprisingly enough, Guinness is one of the best low-carb beers to drink. The South Beach diet, a gentler less radical alternative to Atkins, recommends that you drink Guinness whenever you want a beer.
So, next time you want to indulge in a pint of the black stuff, you can do so happily...just as long as it's just one or two pints. Any more than that, and you should plan on drinking your dinner.:)
I don't understand, what you mean, because where I come from, commas are revered and considered, an integral part, of society. If I had a nickel, for every time one of my countrymen, used a comma in a sentence, I'd be a very rich man, indeed.
We don't get much done where I'm from, but nobody ever accused us of talking too fast.
Seriously -- thanks for cracking down on my lax puncutation. Even if I was forced to insert the ole foot a few inches into the mouth, on account of practicing sloppy English in a comment that was supposed to berate sloppy English.
That's just how Gibson writes. If he talks that way too, I can only imagine the sublime surreality of his lunch order, or his instructions to the cable guy.
But no, I think he was just using this bit of media exposure as a chance to grandstand his slick, chromed buzzword-laden writing style. Trying to scare up a few more readers, as any self-respecting, self-promoting artist should always be trying to do.
One day, perhaps I'll write a send-up of Gibson. It would be a boring and very ordinary short story with no sci-fi elements, that nonetheless sounded cool as all shit because of the language.
The entire point of my post was that safety is not the same thing as acceptable risk. At the end of the post, I even acknowledged that "risk" is defined in terms of mission success or failure rather than loss of life. I couldn't have come closer to saying what you just said if I'd stolen the words from your mouth.
We're not at odds here; we both agree on the fundamental idea that NASA's purpose is to explore space. I'm saying that NASA best serves their purpose when they work to minimize the risk associated with every mission; by definition, minimizing the risk will maximize the chance that the mission will succeed! This is true whether the mission is a sat launch, an unmanned probe or a frickin' Mars mission.
Space is a dangerous place. There are so many things completely out of our control that space travel will never be "safe."
With all of these uncontrollable elements of risk facing us, does it not make sense to take care of the things you *do* control?
Since Senator Joe-Bob's answer would be to let Mom, God and Apple Pie take care of space travel, I tend to agree. NASA is, by law and as a matter of fact, the most qualified agency around to make decisions about space travel. But there's a great deal of room for improvement.
NASA is old. They still work under the weight of a crusty 60s-era layer of bureacrats. They are dogmatic, self-important and no doubt there are employees at every level of the organization who are more concerned with their jobs (after decades of having them) than with their work.
That's not to say we need to take NASA out back and shoot them all. As the original poster said, NASA merely needs some fresh blood, some new ways of doing things. Sean O'Keefe was a good start. "Faster better cheaper" was a step in the right direction. It's a pity we keep cutting their budget while at the same time pressing them for ever more results.
Between China's space program and the impending X-Prize event, I think space development is about to enter a new golden age -- not necessarily corresponding to a greater number of actual missions flown, not at first. But the headway we make in the next 10 years will set the stage for the next 100 years of space travel.
You've made a very good point, disguised as a silly joke.
The name of the game isn't safety. As you point out, space travel is inherently unsafe. The focus of the space program, then, should be on the efficient mitigation of risk.
For every action a planning team can take to mitigate risk, there is an associated cost. If I include three redundant valves in my liquid propellant delivery system, let's say that reduces the chance of a catastrophic failure by 25%... unfortunately it also triples the mass of the system and the number of interconnects between components, which correspondingly increases the cost and the chance of failure in some component of the system.
NASA's mandate should be to find the optimal balance between high cost and low risk. Of course, we also need to distinguish between risk of mission failure and risk of people losing their lives...but that's a stickier issue.
BankOne announced today that their online payment service will be renamed to Napster in order to leverage the brand-name recognition afforded by their recent buyout of the defunct music-swapping network.
Furthermore, their collections department will henceforth be known as United Payout Service, and collections agents will show up at your door wearing brown "UPS" uniforms and carrying tantalizingly wrapped parcels.
Brad Templeton, formerly of the Electronic Frontier Foundation but now hailing from the recently-renamed Quarter Pounder with Cheese, said in response to the news "This misrepresentation just the kind of thing we're against! I've half a mind to report these folks to the Securities and Exchange Commission!"
A spokesman from the SEC was unavailable for comment, remarking that he cannot make any official position statements until the agency finishes its internal reorganization next Tuesday, at which time it will be known as the Fuzzy Bunnies Commission.
is that it's hard to spoof. Getting your example.org to become #1 in the search results would require a whole lotta linking! And it'd have to be other people linking to you, not vice-versa.
I wonder if the only sort of indexing they apply is a hash. Seems like that would rather limit the power of their query language.
If I were implementing an in-memory DBMS, I'd keep several indices of every "primary key" for a table. A hash table, for equality and membership tests. A balanced search tree, for comparison and sorting. Maybe others.
Of course, if I understand Prevayler's approach, any bean property can serve as a key -- that means indexing all of the properties. That'll eat quite a bit of memory, in addition to all of the objects already filling core memory.
If the Prevayler benchmarkers were using a MySQL database whose tables were all forced to use the HEAP implementation, then I'd say the benchmark is valid and Prevayler really IS 3,000 times faster than MySQL.
However, I strongly doubt this is the case. I'm assuming the benchmarkers were allowing MySQL to automatically select the table type, and using a RAM disk as the location of MySQL's database files. In that case, MySQL was using a disk-optimized table structure even though its backing store was in memory.
Page reads or block reads? If one is talking about virtual memory, then one speaks of pages (which have been swapped out into disk blocks); else one normally speaks of blocks on disk.
No problem if you've decided to use nonstandard terminology. I only ask because I want to make sure you're thinking of disk access and not virtual memory, which is a different beast.
The Linux kernel is smart enough by now to do read-ahead caching of disk blocks; in that case, if what you've said is true, a memory-mapped file or a RAM disk will tend to act more like memory than disk.
I haven't looked at the kernel code lately, so I'll take your word for it that asking for a block read does not always suspend the process.
I think we're both arguing the same point: that Prevayler is not much faster than MySQL, except by virtue of the fact that its database resides in RAM. I was just trying to explain the 300,000% discrepancy between the claimed speed of Prevayler and the speed of MySQL with a RAM backing store.
Didn't I just say that Prevayler will only work for applications whose entire database will gracefully fit into core (plus some swap)?
I'm not trying to explain why Prevayler is "better" than a DBMS in this thread; I happen to think it is *not* better, except for small applications that aren't expected to scale up. My argument is that the statement "Prevayler is 3,000 faster than MySQL" is misleading.
But, to answer your question, you do have an easy out. Since the entirety of Prevayler support in your application involves only a few dozen function calls, you remove those few dozen calls from the app then switch to using Java Data Objects, or perhaps find a native OODBMS. They do exist.
And with memory-mapped files -- a feature common to all modern OSes -- you can do the same in any language. But that won't really help us, since it would run abysmally slowly. You can't just read an object from disk every time you need to perform an operation on it -- that's taking the worst of both worlds.
Furthermore, you can't index your objects and query them according to the properties of their fields -- unless support for introspection (enumerating the methods and fields available from a class) is built directly into every class you write. That's a lot of code bloat, and it's ugly and slow. Think of implementing COM IDispatch for EVERY class you want to be part of your database. Ugly!
No; in C++, you should talk to an RDBMS. In fact, if you're even representing your business objects as C++ objects, you should be taken outside and shot.
C++ is best for writing lean, mean applications with a moderate amount of UI. I should know, as I'm primarily a C++ prorammer.
But, really, this is all aside the point. We can have a C++ vs. Java holy war elsewhere. This discussion is about Prevayler vs. disk-based RDBMS.
I'm sure that, with its entire database cached in memory, MySQL's performance *does* improve dramatically. But it's still using maladapted algorithms for doing all of its queries -- the poor algorithms think they're reading blocks from a disk, not pages from memory. And of course every time the MySQL process performs a "disk" read, control reverts to the kernel and the process sacrifices the rest of its quantum. So MySQL will never be able to take full advantage of the fact that it's running with a memory backing store.
My point was simply that Prevayler is naturally going to be much faster than a MySQL database, because one of them is dealing with RAM and the other is dealing with disk. Hence, comparing Prevayler and MySQL performance is like comparing apples and oranges.
We're agreed that Prevayler is very useful, provided that your application fits its memory and reliability constraints. Thus, instead of distracting us with how much faster their orange is than the MySQL apple, they should spend their time evangelizing the "orange" way of doing things.
Prevayler doesn't map data into an RDBMS. Prevayler removes the RDBMS entirely.
In Prevayler, your "database" is represented natively as a collection of objects, which reference each other by holding pointers to each other, just like any other God-fearing object in core memory. It builds indices, also in memory, to support query operations on this big collection of objects. The whole shebang is periodically serialized to disk, to make it persistent between invocations of your application.
So: Prevayler is natively an OODBMS, and not a tool to map between OO and relational databases. Any language that supports introspection can support prevalence, and hence Prevayler. Such languages include Perl, Python and C#.
Even for languages that don't support introspection, you could still implement a prevalence system, but it would be rather awkward and not seamless. Your objects would all need to know how to serialize and deserialize themselves, and also provide indexing information about themselves...a clunky and unwiedly approach. Which is why you're unlikely to see Prevayler for C++ any time soon.
I disagree with Prevayler's approach for more fundamental reasons, having to do with the fact that the whole database must always exist in memory. But I won't get into that here.
If you could cache an entire MySQL database in RAM, I'm sure your MySQL performance would improve dramatically.
If you could then optimize MySQL's search routines for working on memory instead of disk blocks, your MySQL performance would improve even more dramatically. As it is now, MySQL must go through all sorts of contortions, probably using B-Tree-like structures for indexing, and other fanciful datatypes I can't even conceive of without a PhD. The reason for all of this silliness is the fact that MySQL's backing store is disk, not memory.
In a prevalence system like Prevayler, one of the fundamental tenents of the system is that ALL of your objects are ALWAYS in memory, and are only serialized to disk when they change, for persistence.
So...yes: as always, a memory-based system will be three orders of magnitude (or more!) faster than a disk-based system. Prevayler vs. DBMS is no exception to this rule.
But when your website has grown popular, your prevalance database has swelled to 30 gigs and you find yourself hosting it on massive systems with 12 gigs of core memory and another 30 gigs of swap space -- when your memory access times are starting to look like disk access times because of swapping -- well, don't come crying to mwe.
Prevalence is a brilliant solution, for small projects. But they only scale to the size of your physical memory, or slightly (50-100%) larger. You can't expect them to scale beyond that.
SCO's vicious and unwarranted attack on the free software community warrants a forceful response. We cannot stand by and let them destroy GNU/Linux while simultaneously profiting from the community's other efforts.
In order to stop SCO dead in their tracks, here is what I propose.
FSF should create a new version of the GPL that specifically forbids SCO, or any of its subsidiaries or related corporate entities, from using any software written under the license. The license should also prevent the software from being installed or used on any system running an SCO-supplied operating system.
Someone at FSF could draft a standard version of this modified GPL license and call it GPL-SCO ("GPL minus SCO"). Starting with Samba, open source projects could switch over to the new license. The license changes probably wouldn't be retroactive, but at least SCO would be prevented from using future versions of the products.
It's time to lock SCO down. Hit them where it hurts. They are a sinking ship and they will eventually die, but by eliminating their revenue and their customer base we make sure they die sooner rather than later.
"Tell me, Mr. McBride...what good is a lawsuit, when you are unable to pay your legal bills?"
Slashdot Mirror
Good point. I think we'll just have to suspend our disbelief here, since with my limited imagination I can't think a valid answer to either the computation or power problems. Looks like no gloopy metal robots for us anytime in the near future!
In fact, the power needed to run the T-1000's computations pales in comparison with the energy required to move all of that metal around. I can think of two ways to get that much power:
1) "Eat" organic matter you find in the environment and metabolize it to produce energy.
2) Carry an onboard power plant, such as a fusion or antimatter reactor.
In either case, individual computation units could be equipped with super-high-density storage batteries, so they could survive away from the power plant for short periods of time. This suggests, of course, that computation units are much bigger than a single molecule.
Is this just an off-the-cuff remark, or did T3 actually mention this fact to the viewers sometime during the movie? If so, can you remember how it was phrased?
Obviously, the TX was a refinement of and an improvement on the T-1000 and its "gloopy metal" construction. But aside from mentioning that the T-1000 used a decentralized computing architecture, they never got down to specifying where inside all that gloop the computation was taking place...I guess we were supposed to believe that every molecule of the metal was somehow contributing toward the running of the T-1000.
Come to think of it, acting like a T-1000 doesn't take much computing power. I bet my desktop PC could do it! All it needs to do is say "Get out" and "Tell me where this boy is" in a monotone, and randomly stab people. Should be a binch!
W.R.T. the lobby scene, good point -- now that I think about it, the two scenes are very visually similar. But how can you not see the symbology in the "Do not use lift if there is a fire" sign on the elevator door in The Matrix? Clearly, this is the Wachowski's way of reminding us that causality rules supreme, that all actions have their consequences! (Just kidding. The elevator scene is just another cinematic shiny bit, dangling in front of the viewer's eyes.)
W.R.T. to Kusanagi being ordinary: a being's notion of ordinariness depends on context. Within the context that Kusanagi is familiar with, she is an ordinary cyborg. She and her team are perhaps more highly skilled than other members of the same force, who are in turn very different from ordinary citizens. But Kusanagi is not fundamentally different from her peers. Or so she thinks.
When Kusanagi finds out that she is in fact far from ordinary, your perception of what makes "Kusanagi" is radically altered, but your (and her) perception of the world in which she lives, is fundamentally the same as it was before.
Compare this with The Matrix, where you need to rethink not only your ideas about Neo, but your ideas about the world(s) in which he lives, multiple times.
I hope this makes sense...I'm trying to be deliberately vague on specific plot points, in order to avoid spoilers.
Sorry, how does it follow that Wachowskis plagiarized GITS? I'm not defending the Wachowskis -- Matrix is already a rip-off of about a dozen schools of western, eastern, ancient and modern philosophy -- but the storylines seem largely divergent.
GITS:
Matrix:
I think you've hit the nail on the head here. The real problem with a retail PPC port of Windows is that there's no target market!
Anyone with a PPC system is already a huge Mac fan, and anybody looking to buy a speedy Windows system is going to buy Intel hardware at 75% of the cost. Anyone who wants to run MacOS server applications on Intel hardware can simply run GNU Darwin.
The real market is to be found in the millions of Intel users who want to get their hands on MacOS, but don't want to shell out the greenbacks for premium-priced Apple PPC hardware, and/or who don't feel comfortable with Apple's "don't look inside the box" mentality.
Call them back and ask about the glycemic index of Guinness. The glycemic index is a measure of the net effect of the sugars and carbs found in a given food on your metabolism. The higher a food's glycemic index number, the more readily your body assimilates the calories from carbohydrates contained in the food, and the more it tends to make you crave more food.
Sugar isn't all that bad for you, calorie-wise. The problem is that sugar -- and other substances with a high glycemic index -- cause you to become hungrier, which makes you eat more overall.
I'm no expert in this stuff -- it's all hearsay from my three roommates, who are on the South Beach diet and have lost a total of 180 lbs between them so far.
I lost my own weight -- almost 120 lbs of it -- using The Hacker's Diet, back in 1999 before it was trendy. Simply counting calories and getting plenty of exercise seemed to work fine for me. But my roommates have been losing weight faster than I ever did, and their figures have been improving at a rate that outstrips their weight loss (i.e. they seem to be losing fat without losing so much muscle).
Microsoft has taken the first step toward removing the binary compatability burden from their vendors' shoulders by introducing .NET as their blessed-from-on-high development platform.
.NET, of course, is the write-once-run-anywhere concept. IMHO this mentality comes just in time, as we are on the doorstep of 64-bit computing, at which time the latest architecture from a given vendor (Intel or AMD, take your pick) will no longer be compatible with the previous generation of chips. Ready or not, Windows is about to support multiple architectures.
Inherent to
Transmeta has proven that one can achieve non-native compatability (i.e. without building a compatability mode into the silicon); this, combined with the tremendous amount of research that's gone into virtualization and emulation since the mid 90s means that it's no longer a pipe dream to dynamically translate code between architectures. This is especially true if you're translating a binary that targets the same underlying API, and the API is designed to abstract away the BIOS and other architecture-dependent parts of a computer.
I'm not saying that we'll see a PPC port of Windows sold in stores -- I agree with you that it's about as likely as Bill Gates slapping a penguin bumper sticker on his car. I'm just saying that the technical obstacles that killed off Alpha/PPC Windows have since been surmounted.
Surprisingly enough, Guinness is one of the best low-carb beers to drink. The South Beach diet, a gentler less radical alternative to Atkins, recommends that you drink Guinness whenever you want a beer.
:)
So, next time you want to indulge in a pint of the black stuff, you can do so happily...just as long as it's just one or two pints. Any more than that, and you should plan on drinking your dinner.
I don't understand, what you mean, because where I come from, commas are revered and considered, an integral part, of society. If I had a nickel, for every time one of my countrymen, used a comma in a sentence, I'd be a very rich man, indeed.
We don't get much done where I'm from, but nobody ever accused us of talking too fast.
Seriously -- thanks for cracking down on my lax puncutation. Even if I was forced to insert the ole foot a few inches into the mouth, on account of practicing sloppy English in a comment that was supposed to berate sloppy English.
You were fooled by our insidious language, which makes it virtually impossible to distinguish between simple past tense and passive voice.
What the headline said was:
Mars attacked [Earth], 65 years ago today.
What you thought it said (and what it actually might have said if Slashdot were a newspaper) was:
Mars attacked [by] Earth, 65 years ago today.
Bloody hell..and they call this a language?
That's just how Gibson writes. If he talks that way too, I can only imagine the sublime surreality of his lunch order, or his instructions to the cable guy.
But no, I think he was just using this bit of media exposure as a chance to grandstand his slick, chromed buzzword-laden writing style. Trying to scare up a few more readers, as any self-respecting, self-promoting artist should always be trying to do.
One day, perhaps I'll write a send-up of Gibson. It would be a boring and very ordinary short story with no sci-fi elements, that nonetheless sounded cool as all shit because of the language.
The entire point of my post was that safety is not the same thing as acceptable risk. At the end of the post, I even acknowledged that "risk" is defined in terms of mission success or failure rather than loss of life. I couldn't have come closer to saying what you just said if I'd stolen the words from your mouth.
We're not at odds here; we both agree on the fundamental idea that NASA's purpose is to explore space. I'm saying that NASA best serves their purpose when they work to minimize the risk associated with every mission; by definition, minimizing the risk will maximize the chance that the mission will succeed! This is true whether the mission is a sat launch, an unmanned probe or a frickin' Mars mission.
Space is a dangerous place. There are so many things completely out of our control that space travel will never be "safe."
With all of these uncontrollable elements of risk facing us, does it not make sense to take care of the things you *do* control?
Since Senator Joe-Bob's answer would be to let Mom, God and Apple Pie take care of space travel, I tend to agree. NASA is, by law and as a matter of fact, the most qualified agency around to make decisions about space travel. But there's a great deal of room for improvement.
NASA is old. They still work under the weight of a crusty 60s-era layer of bureacrats. They are dogmatic, self-important and no doubt there are employees at every level of the organization who are more concerned with their jobs (after decades of having them) than with their work.
That's not to say we need to take NASA out back and shoot them all. As the original poster said, NASA merely needs some fresh blood, some new ways of doing things. Sean O'Keefe was a good start. "Faster better cheaper" was a step in the right direction. It's a pity we keep cutting their budget while at the same time pressing them for ever more results.
Between China's space program and the impending X-Prize event, I think space development is about to enter a new golden age -- not necessarily corresponding to a greater number of actual missions flown, not at first. But the headway we make in the next 10 years will set the stage for the next 100 years of space travel.
You've made a very good point, disguised as a silly joke.
... unfortunately it also triples the mass of the system and the number of interconnects between components, which correspondingly increases the cost and the chance of failure in some component of the system.
The name of the game isn't safety. As you point out, space travel is inherently unsafe. The focus of the space program, then, should be on the efficient mitigation of risk.
For every action a planning team can take to mitigate risk, there is an associated cost. If I include three redundant valves in my liquid propellant delivery system, let's say that reduces the chance of a catastrophic failure by 25%
NASA's mandate should be to find the optimal balance between high cost and low risk. Of course, we also need to distinguish between risk of mission failure and risk of people losing their lives...but that's a stickier issue.
BankOne announced today that their online payment service will be renamed to Napster in order to leverage the brand-name recognition afforded by their recent buyout of the defunct music-swapping network.
Furthermore, their collections department will henceforth be known as United Payout Service, and collections agents will show up at your door wearing brown "UPS" uniforms and carrying tantalizingly wrapped parcels.
Brad Templeton, formerly of the Electronic Frontier Foundation but now hailing from the recently-renamed Quarter Pounder with Cheese, said in response to the news "This misrepresentation just the kind of thing we're against! I've half a mind to report these folks to the Securities and Exchange Commission!"
A spokesman from the SEC was unavailable for comment, remarking that he cannot make any official position statements until the agency finishes its internal reorganization next Tuesday, at which time it will be known as the Fuzzy Bunnies Commission.
is that it's hard to spoof. Getting your example.org to become #1 in the search results would require a whole lotta linking! And it'd have to be other people linking to you, not vice-versa.
I wonder if the only sort of indexing they apply is a hash. Seems like that would rather limit the power of their query language.
If I were implementing an in-memory DBMS, I'd keep several indices of every "primary key" for a table. A hash table, for equality and membership tests. A balanced search tree, for comparison and sorting. Maybe others.
Of course, if I understand Prevayler's approach, any bean property can serve as a key -- that means indexing all of the properties. That'll eat quite a bit of memory, in addition to all of the objects already filling core memory.
If the Prevayler benchmarkers were using a MySQL database whose tables were all forced to use the HEAP implementation, then I'd say the benchmark is valid and Prevayler really IS 3,000 times faster than MySQL.
However, I strongly doubt this is the case. I'm assuming the benchmarkers were allowing MySQL to automatically select the table type, and using a RAM disk as the location of MySQL's database files. In that case, MySQL was using a disk-optimized table structure even though its backing store was in memory.
Page reads or block reads? If one is talking about virtual memory, then one speaks of pages (which have been swapped out into disk blocks); else one normally speaks of blocks on disk.
No problem if you've decided to use nonstandard terminology. I only ask because I want to make sure you're thinking of disk access and not virtual memory, which is a different beast.
The Linux kernel is smart enough by now to do read-ahead caching of disk blocks; in that case, if what you've said is true, a memory-mapped file or a RAM disk will tend to act more like memory than disk.
I haven't looked at the kernel code lately, so I'll take your word for it that asking for a block read does not always suspend the process.
I think we're both arguing the same point: that Prevayler is not much faster than MySQL, except by virtue of the fact that its database resides in RAM. I was just trying to explain the 300,000% discrepancy between the claimed speed of Prevayler and the speed of MySQL with a RAM backing store.
Didn't I just say that Prevayler will only work for applications whose entire database will gracefully fit into core (plus some swap)?
I'm not trying to explain why Prevayler is "better" than a DBMS in this thread; I happen to think it is *not* better, except for small applications that aren't expected to scale up. My argument is that the statement "Prevayler is 3,000 faster than MySQL" is misleading.
But, to answer your question, you do have an easy out. Since the entirety of Prevayler support in your application involves only a few dozen function calls, you remove those few dozen calls from the app then switch to using Java Data Objects, or perhaps find a native OODBMS. They do exist.
And with memory-mapped files -- a feature common to all modern OSes -- you can do the same in any language. But that won't really help us, since it would run abysmally slowly. You can't just read an object from disk every time you need to perform an operation on it -- that's taking the worst of both worlds.
Furthermore, you can't index your objects and query them according to the properties of their fields -- unless support for introspection (enumerating the methods and fields available from a class) is built directly into every class you write. That's a lot of code bloat, and it's ugly and slow. Think of implementing COM IDispatch for EVERY class you want to be part of your database. Ugly!
No; in C++, you should talk to an RDBMS. In fact, if you're even representing your business objects as C++ objects, you should be taken outside and shot.
C++ is best for writing lean, mean applications with a moderate amount of UI. I should know, as I'm primarily a C++ prorammer.
But, really, this is all aside the point. We can have a C++ vs. Java holy war elsewhere. This discussion is about Prevayler vs. disk-based RDBMS.
Thank you for the clarification.
I'm sure that, with its entire database cached in memory, MySQL's performance *does* improve dramatically. But it's still using maladapted algorithms for doing all of its queries -- the poor algorithms think they're reading blocks from a disk, not pages from memory. And of course every time the MySQL process performs a "disk" read, control reverts to the kernel and the process sacrifices the rest of its quantum. So MySQL will never be able to take full advantage of the fact that it's running with a memory backing store.
My point was simply that Prevayler is naturally going to be much faster than a MySQL database, because one of them is dealing with RAM and the other is dealing with disk. Hence, comparing Prevayler and MySQL performance is like comparing apples and oranges.
We're agreed that Prevayler is very useful, provided that your application fits its memory and reliability constraints. Thus, instead of distracting us with how much faster their orange is than the MySQL apple, they should spend their time evangelizing the "orange" way of doing things.
Prevayler doesn't map data into an RDBMS. Prevayler removes the RDBMS entirely.
In Prevayler, your "database" is represented natively as a collection of objects, which reference each other by holding pointers to each other, just like any other God-fearing object in core memory. It builds indices, also in memory, to support query operations on this big collection of objects. The whole shebang is periodically serialized to disk, to make it persistent between invocations of your application.
So: Prevayler is natively an OODBMS, and not a tool to map between OO and relational databases. Any language that supports introspection can support prevalence, and hence Prevayler. Such languages include Perl, Python and C#.
Even for languages that don't support introspection, you could still implement a prevalence system, but it would be rather awkward and not seamless. Your objects would all need to know how to serialize and deserialize themselves, and also provide indexing information about themselves...a clunky and unwiedly approach. Which is why you're unlikely to see Prevayler for C++ any time soon.
I disagree with Prevayler's approach for more fundamental reasons, having to do with the fact that the whole database must always exist in memory. But I won't get into that here.
If you could cache an entire MySQL database in RAM, I'm sure your MySQL performance would improve dramatically.
If you could then optimize MySQL's search routines for working on memory instead of disk blocks, your MySQL performance would improve even more dramatically. As it is now, MySQL must go through all sorts of contortions, probably using B-Tree-like structures for indexing, and other fanciful datatypes I can't even conceive of without a PhD. The reason for all of this silliness is the fact that MySQL's backing store is disk, not memory.
In a prevalence system like Prevayler, one of the fundamental tenents of the system is that ALL of your objects are ALWAYS in memory, and are only serialized to disk when they change, for persistence.
So...yes: as always, a memory-based system will be three orders of magnitude (or more!) faster than a disk-based system. Prevayler vs. DBMS is no exception to this rule.
But when your website has grown popular, your prevalance database has swelled to 30 gigs and you find yourself hosting it on massive systems with 12 gigs of core memory and another 30 gigs of swap space -- when your memory access times are starting to look like disk access times because of swapping -- well, don't come crying to mwe.
Prevalence is a brilliant solution, for small projects. But they only scale to the size of your physical memory, or slightly (50-100%) larger. You can't expect them to scale beyond that.
SCO's vicious and unwarranted attack on the free software community warrants a forceful response. We cannot stand by and let them destroy GNU/Linux while simultaneously profiting from the community's other efforts.
In order to stop SCO dead in their tracks, here is what I propose.
FSF should create a new version of the GPL that specifically forbids SCO, or any of its subsidiaries or related corporate entities, from using any software written under the license. The license should also prevent the software from being installed or used on any system running an SCO-supplied operating system.
Someone at FSF could draft a standard version of this modified GPL license and call it GPL-SCO ("GPL minus SCO"). Starting with Samba, open source projects could switch over to the new license. The license changes probably wouldn't be retroactive, but at least SCO would be prevented from using future versions of the products.
It's time to lock SCO down. Hit them where it hurts. They are a sinking ship and they will eventually die, but by eliminating their revenue and their customer base we make sure they die sooner rather than later.
"Tell me, Mr. McBride...what good is a lawsuit, when you are unable to pay your legal bills?"