Thank you! Excellent point! Not only do you need an expensive craft, you will need all the crazy amount of infrastructure necessary to get people into orbit, to resupply and service the craft. The list of necessary things that would need to be set up before you can have regular trips going back and forth is mind blowing.
This guy thinks he could do it in worst case within 15 years and break even with $500K per seat.
I'm sorry, but there's no nice way to put it: that's just plain stupid.
Agree. There is no way in hell one drone needs anywhere near that kind of bandwidth. Even 500 Mb/s is incredible.
If it turns out 500 Mb/s is accurate, then whoever the contractor is that designed this thing needs to be fired pronto.
Why did it take more than 100 years for someone to think of it? If this is the first discovery of this idea, then that makes me despair for the intelligence of the human race...
The actual claim of doubling capacity is way overblown for most deployments. The only time you will get double capacity is when you only have two radios and they are only trying to talk to each other. So, for a home network that might be the case.
However, in the far more common cases of lots of radios competing for medium access with each transmitting towards a very small subset of the nodes in range, you will not get doubling of capacity. What you can get is a significantly better media access control (MAC) layer by improving the channel access control mechanism.
This new mechanism will allow a transmitter to detect if its signal is colliding with another transmitter's signal. Currently, when a radio transmits it can only hear itself and will continue transmitting even if another radio was transmitting at the same time, which usually garbles both signals for all receivers. With this new mechanism, a transmitter will be able to stop very quickly if it hears another radio simultaneously transmitting.
This would allow radios to, for example, use CSMA/CD rather than just plain CSMA.
The problem is that he reverse engineered their deterministic process for generating winners and losers and then was able to pick out the winning cards based on the partial information they revealed. The order in which they are printed doesn't really matter. Given any random subset of the cards he could pick the winners out of them at a much higher % than he should have been able to if they were actually random.
Sounds to me like they should figure the game out in such a way that a real random number generator will generate winners and losers at the desired rates on average and then just rely on the law of averages / large numbers to give them their desired take.
Tell me, is it wrong in any way (e.g. - legally, morally, etc.) to go purchase a book, make a bunch of copies of it and sell them? If so, then please explain why?
If a book did have a license attached to it (I wouldn't be surprised if e-books already do), then it would be up to you whether you wanted to buy the book or not.
Why might an author or publisher do this? Think about college text book publishers: if they didn't have to worry about the burgeoning resale market for their books amongst their target population, then they might be able to charge far more reasonable prices for a first sale. (Leave aside the fact that students are effectively captive to the textbooks their professors decide upon)
Way to go! You completely ignored my core point, which is that the price of the product was specifically chosen based on the (legally binding) assumption that it would only benefit the original purchaser. If the owner of the intellectual property intended to have their, for example, game with limited replay value passed on ad infinitum, then they would price it differently. You violated their pricing assumption when you violated the end user license agreement.
Of course, none of this seems like it would matter to you in the least because you apparently think anyone should be able to duplicate someone else's intellectual property ad infinitum and sell it themselves for their own benefit. You don't even think straight up piracy is wrong, so there's no point in trying to argue legality, much less ethics, with you.
To your point about items that are not used up and passed along, here again, I disagree with you. All physical items degenerate with use, even things like books, but especially things like cars. Digital items can be protected (erasure codes, backups, etc.) in such a way that they never degenerate. Now imagine a universe where a car never degenerated even when driven hard. In such a universe, car makers would be forced to charge much, much, much more per car to survive because every car they produced could stay on the road potentially forever meaning they have far less opportunities for direct sales. Today, car manufacturers build into their pricing assumptions the fact that cars depreciate at a fairly predictable rate with a turnover leading to fairly predictable demand. If some magical way was found that completely circumvented this assumption, then car manufacturers would be forced to greatly increase prices and ultimately would probably be forced out of business.
Unfortunately, with many people agreeing with your opinion when it comes to intellectual property you certainly reduce the business opportunities available to people creating such property. Ultimately, less good intellectual property is produced because the rewards aren't as attractive as they might otherwise be.
What is the fundamental difference between selling software that you purchased and selling several copies of it that you make? I think we all agree that the latter case definitely should not be allowed without the owner's consent as you are selling someone else's intellectual property for your own monetary gain.
But what about the former case where you essentially sell one copy and stop using (even retaining) your copy? If you are able to get near full price for your secondary sale, which you often can with software, then you have essentially used the original owner's product for free for some period of time. Worse, this process can continue ad infinitum -- many people can derive whatever value they need from this product (e.g. - think video games with limited replay value) and then pass it along to the next person who wants it and (nearly) recoup whatever their monetary investment was.
Many people derive the benefit they want from the product for a tiny, often zero, fraction of the price the original purveyor intended for a single person to pay to derive that benefit. That and the fact that software doesn't depreciate similarly to most physical items are the essential problems here. If the purveyor had intended to sell you a transferable license that might get passed on to many people, then you can damn sure bet they would charge a significantly higher price for it initially. Similarly, if the purveyor had intended to sell you a license that would let you sell as many copies of the software as you wanted (i.e. - be a distributor), then they would price it very differently (i.e. - one huge license price, or a per license sold revenue sharing agreement).
Secondary sales of licensed software that transfer the product against the wishes of the intellectual property owner essentially steal from them because the original price point they chose was based on the (legally justified) assumption that only one person would derive the expected benefit from the product. The secondary sale breaks the license agreement and violates the original pricing assumption of the original purveyor.
From the clues in the article clips (it would be great if someone could summarize the full ones) it seems that the family got a hold of the officer's email address and were sending him email. I have no idea how much or what was the topic of those emails, but I'm pretty sure the harassment claim stemmed from these emails and not from the original video taping.
As a private individual you can set up just about whatever kind of surveillance on your property that you like. The road is a public place and you are allowed to video tape in public places as well, so there should be no legal problem with doing what they did.
My main point is that it is obvious we don't have the full story from these news clips and all the people who are railing against this officer and his abuse of power are rushing to judgement. That being said, I'm still willing to bet the officer brought the suit because he was PO'ed about being reported to his superiors. People abuse the legal system this way all the time. The problem is that his suit has turned this minor incident into a big PR story and so the local government might be forced to take some kind of politically correct action against him for his speeding... hoisted by his own petard possibly...
Am I taking crazy pills? If you comply with the BSD license then it obviously gives you permission to create derivative works or even minor modifications.
"[2] Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:"
So long as you meet the conditions, which are to (a) reproduce the copyright notice, (b) the list of conditions and (c) the warranty disclaimer, then the license gives you permission to create modifications, derivative works, etc.
The problem is that the author has incorrectly included the original license grant into the list of conditions that must be reproduced by redistributors / modifiers / etc. A redistributor / modifier is not required to reproduce [2] in their redistribution / modification. See this post for more detail. Therefore, they are not required to allow modification, redistribution, etc. of their derivative work.
It seems that this lawyer has not been trained in computer science because he is glossing over an important detail of the license to reach his incorrect conclusion. The BSD license says (using the author's numbering and my emphasis):
"2 Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
3 * Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
4 * Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
5 * Neither the name of the [organization] nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission."
The license requires, per clauses 2-4, that a user reproduce (a) the copyright notice, (b) the list of conditions and (c) the disclaimer of the original license. The author reads this as requiring that the entire BSD license be reproduced in any redistrubtion or use of the code. But this is only true if (a), (b) and (c) comprise the entirety of the BSD license. I argue that they do not!
The key question is, "What is the 'list of conditions' that must be reproduced?" The author incorrectly claims that [2] is part of the list of conditions that must be maintained by a user, which would create a viral mechanism that this paper describes.
It is obvious from [2]'s use of the phrase "the following conditions" and the fact that [3, 4, 5] are preceded by asterisks and use the phrase "this list of conditions" that [2] is not intended to be part of the list of conditions. The list of conditions only consists of [3, 4, 5]. Therefore, redistributors / users are not required to maintain the original grant of the license [2] in their use or redistribution of the code.
The flaw in the author's argument is that he is incorrectly including the original grant of the license [2] into the list of conditions [3, 4, 5]. The license truly only requires that users reproduce clauses [1, 3, 4, 5, 6] of the BSD license in their redistrubtions or use.
I was actually looking forward to reading a quick introduction on Python as I primarily use C/C++ and I thought, "Hey, if it's on the front page of slashdot, then it's probably a decent article."
Instead, I found this craptastic waste of time that doesn't even approach funny. It's just a bunch of really cheesy and way too obvious "jokes."
Anyway, I don't mean to put down the author so much as whoever approved this story getting on the front page of slashdot. You guys are better than this.:)
As many other posters have noted, hydrogen is only an efficient storage medium for energy, so the energy to create hydrogen still has to come from somewhere. To power this "hydrogen economy" we can choose from non-renewables (oil, coal, nuclear), renewables (solar, hydro, wind, sea, geo) or some blend thereof.
In the near term it would be (is) oil and coal with a pinch of nuclear and hydro. If we wanted to get off of our dependence on oil in the near future, we'd have to go nearly all coal (not enough hydro and nuclear has too many image problems, the worst being the spent fuel). The U.S. COULD do this as we have some of the largest unexploited, extractable deposits of coal on the planet. Of course, coal has all the environmental drawbacks of oil and then some.
The real solution to our energy and environmental problems is to go with renewables. In the long run, we will use up all of the non-renewables (hence, the name) and while we're doing that we will wreak havoc on our environment and ourselves. Renewable energy, in particular solar power, solves all of our problems: it's safe, environmental impact is nearly nil and it's vastly abundant. Currently, solar power's one fatal flaw is infrastructure (i.e. - collection / production) cost. I believe in time that technology will solve this problem. Improving and deploying solar technology is where I would put the majority of my R&D money, not in developing fuel cells which only half addresses a small part of the real problem! (BTW, IMHO solar space power is unrealistic for the forseeable future)
Here's a picture of the future I'd like to see: every building is helping to power itself and others through solar cell roofs. During the day, most buildings (i.e. - residences) overproduce and spin up kinetic batteries and supply energy to the grid. At night they draw from these batteries and the grid. Sunny places (e.g. - Arizona, Nevada, etc.) really overproduce and help the less sunny places. The grid is backstopped by centralized nuclear and solar plants to supplement during times of extreme demand or lulls (i.e. - winter) in supply. The electric grid becomes much more distributed and energy flows from disparate sources to where it is needed as necessary in a minimal loss manner. This model also has nice side effects such as far fewer power losses in general and our infrastructure is harder to attack.
This brings us back to the question "How do we power automobiles?" We've seen that electric cars have severe drawbacks. Using electricity to produce hydrogen to power fuel cells is a good option. In the model above, if residences produced enough spare electricity to "power" their vehicles' hydrogen needs, then we wouldn't have the transmission loss we have in our current centralized model (this is around a 30% loss today). A possibly better option would be to develop kinetic batteries to power cars. These things are currently close to 80% efficient! The main drawback with them is a possible safety hazard (flying bits of shrapnel (bullets) after a minor accident).
In conclusion, if we are going to spend $100B on energy, then lets spend it on the real energy PRODUCTION problem first!
I can't believe I haven't seen Berkeley DB mentioned a LOT more here as a great alternative to both RDBMS and OODBMS.
BDB is a key-value DB -- it doesn't do SQL. Each DB is a simple "table" of keys to blocks of data. Tell BDB how to compare keys and augment BDB to convert the blocks of data into whatever you like (e.g. - un/serialize your objects). If you won't be doing too much convoluted SQL-like logic and you need an ACID datastore, then BDB is the way to go.
It has most everything you could want:
-- fully ACID (trnxns/rollback/snapshots)
-- single or multi-threaded/process access
-- fine grain locking
-- multi-node failover/balancing
-- multiple indexes per DB
-- SUPER flexible (trade features for speed)
-- AWESOME performance
-- little to no DB administration
-- under development for more than 10 years (debugged)
-- can handle DB sizes up to 256TB
-- can handle record sizes up to 4GB
-- supports most popular languages
-- is maintained by a world class company
-- you can buy support from the maintainers
-- open source + FREE for a lot of uses
I don't think anything out there with a similiar feature set can consistenly outpeform BDB.
First, let me say that the safest thing you can do is not store sensitive data. Barring that, the next safest thing you can do is store sensitive data on a physically secured machine(s) not attached to a network. Any data accesses/transfers should be done "manually" (moving HDDs, or CDs, etc.) and logged by trusted personnel. Barring that, you want your database process to be able to locally decrypt stored data. This implies, regardless of encryption scheme, that the secret portion of your key somehow be locally available. Because the key is available locally it is subject to attack if your server comes under attack. Therefore the only thing you can do is make access to the secret key as difficult as possible...
First, regardless of the scheme you choose you should monitor this machine(s) and the database process(es) to the best of your ability to detect aberrent behavior. For example, if a database process dies, you need to understand why -- was someone trying to cause a core dump to get at its memory? Logging of machine level and process level events and online/offline auditing of your logs can help detect aberrent behavior. Contact a security firm if this kind of stuff keeps you up at night.
Second, physically secure the machine(s) to the best of your ability. Hosting facilities generally provide pretty high physical security. Buy good locks for your cage(s) and only give logged physical access to trusted personnel. You can get as crazy as you want with physical security if you are really worried...
Off the top of my head I can think of two ways to make access to your secret key difficult.
(1) Store the secret key only in the volatile memory of your database process -- don't allow core dumps of any sort and don't allow your process to swap to disk. The key should be entered by hand by trusted personnel through a secure terminal upon database process reboot and rekeying of the database.
An attacker from outside would need to be able to get access to the memory of your process and sift through it to find your key. There are ways to do this, but it would require a pretty sophisticated adversary. If you are monitoring activity on your machine you would probably be able to detect such an attack. If a machine was physically stolen, continuous power would have to be supplied to it during the theft -- doable, but somewhat difficult.
(2) Have encryption/decryption performed by a "tamper-proof" hardware card or attached machine. Here, to "get at" the key the attacker _should_ have to convince the card that he is the authorized process, usually through a challenge-response mechanism. At some point a secret needs to be provided to the process. The advantage with this method, is that after it is authenticated the process can forget its authentication secret and/or that the authentication secret is only good for one authentication. Again, the authentication secret should be entered into the processes' volatile memory by trusted personnel through a secure terminal.
In this scenario, an attacker from outside would have to hijack the process after it has been authenitcated and direct it to execute his code. This attack is doable, but with good monitoring should be easily detected.
Insider attacks are much more difficult to prevent. With trusted inside personnel you can usually only depend on unimpeachable event logs to track down attacks after they occur. When trusted insiders collude it may be next to impossible to prevent and/or prosecute attacks.
Slashdot Mirror
I hope so and I hope some of the legislatures reminded him that he was under oath ...
Thank you! Excellent point! Not only do you need an expensive craft, you will need all the crazy amount of infrastructure necessary to get people into orbit, to resupply and service the craft. The list of necessary things that would need to be set up before you can have regular trips going back and forth is mind blowing.
This guy thinks he could do it in worst case within 15 years and break even with $500K per seat.
I'm sorry, but there's no nice way to put it: that's just plain stupid.
Ten to fifteen years? Dude, please pass whatever it is you are smoking because that's F'ing nuts!
I think even fifty years would be grossly optimistic for "commercial" travel to Mars.
How about we "conquer" Moon before we try for the much harder target of Mars???!!!
Agree. There is no way in hell one drone needs anywhere near that kind of bandwidth. Even 500 Mb/s is incredible. If it turns out 500 Mb/s is accurate, then whoever the contractor is that designed this thing needs to be fired pronto.
Exactly.
...
Your suggestion is even better than mine, which was going to be why not generate random "blocks" of a single character instead of nine?
I imagine the monkeys would have "recreated Shakespeare" in less than a second
Why did it take more than 100 years for someone to think of it? If this is the first discovery of this idea, then that makes me despair for the intelligence of the human race ...
The actual claim of doubling capacity is way overblown for most deployments. The only time you will get double capacity is when you only have two radios and they are only trying to talk to each other. So, for a home network that might be the case.
However, in the far more common cases of lots of radios competing for medium access with each transmitting towards a very small subset of the nodes in range, you will not get doubling of capacity. What you can get is a significantly better media access control (MAC) layer by improving the channel access control mechanism.
This new mechanism will allow a transmitter to detect if its signal is colliding with another transmitter's signal. Currently, when a radio transmits it can only hear itself and will continue transmitting even if another radio was transmitting at the same time, which usually garbles both signals for all receivers. With this new mechanism, a transmitter will be able to stop very quickly if it hears another radio simultaneously transmitting.
This would allow radios to, for example, use CSMA/CD rather than just plain CSMA.
The problem is that he reverse engineered their deterministic process for generating winners and losers and then was able to pick out the winning cards based on the partial information they revealed. The order in which they are printed doesn't really matter. Given any random subset of the cards he could pick the winners out of them at a much higher % than he should have been able to if they were actually random.
... :(
Sounds to me like they should figure the game out in such a way that a real random number generator will generate winners and losers at the desired rates on average and then just rely on the law of averages / large numbers to give them their desired take.
Forgot to login, sorry for the dup
Isn't one requirement of a patent for it to be non-obvious?!!!
That a well informed person in the relevant field probably wouldn't think of the invention in the natural course of events?!!!
No way in heck should this have been granted as this use is beyond obvious -- it is sitting on your face wriggling!!!
Tell me, is it wrong in any way (e.g. - legally, morally, etc.) to go purchase a book, make a bunch of copies of it and sell them? If so, then please explain why?
If a book did have a license attached to it (I wouldn't be surprised if e-books already do), then it would be up to you whether you wanted to buy the book or not.
Why might an author or publisher do this? Think about college text book publishers: if they didn't have to worry about the burgeoning resale market for their books amongst their target population, then they might be able to charge far more reasonable prices for a first sale. (Leave aside the fact that students are effectively captive to the textbooks their professors decide upon)
Way to go! You completely ignored my core point, which is that the price of the product was specifically chosen based on the (legally binding) assumption that it would only benefit the original purchaser. If the owner of the intellectual property intended to have their, for example, game with limited replay value passed on ad infinitum, then they would price it differently. You violated their pricing assumption when you violated the end user license agreement.
Of course, none of this seems like it would matter to you in the least because you apparently think anyone should be able to duplicate someone else's intellectual property ad infinitum and sell it themselves for their own benefit. You don't even think straight up piracy is wrong, so there's no point in trying to argue legality, much less ethics, with you.
To your point about items that are not used up and passed along, here again, I disagree with you. All physical items degenerate with use, even things like books, but especially things like cars. Digital items can be protected (erasure codes, backups, etc.) in such a way that they never degenerate. Now imagine a universe where a car never degenerated even when driven hard. In such a universe, car makers would be forced to charge much, much, much more per car to survive because every car they produced could stay on the road potentially forever meaning they have far less opportunities for direct sales. Today, car manufacturers build into their pricing assumptions the fact that cars depreciate at a fairly predictable rate with a turnover leading to fairly predictable demand. If some magical way was found that completely circumvented this assumption, then car manufacturers would be forced to greatly increase prices and ultimately would probably be forced out of business.
Unfortunately, with many people agreeing with your opinion when it comes to intellectual property you certainly reduce the business opportunities available to people creating such property. Ultimately, less good intellectual property is produced because the rewards aren't as attractive as they might otherwise be.
What is the fundamental difference between selling software that you purchased and selling several copies of it that you make? I think we all agree that the latter case definitely should not be allowed without the owner's consent as you are selling someone else's intellectual property for your own monetary gain.
But what about the former case where you essentially sell one copy and stop using (even retaining) your copy? If you are able to get near full price for your secondary sale, which you often can with software, then you have essentially used the original owner's product for free for some period of time. Worse, this process can continue ad infinitum -- many people can derive whatever value they need from this product (e.g. - think video games with limited replay value) and then pass it along to the next person who wants it and (nearly) recoup whatever their monetary investment was.
Many people derive the benefit they want from the product for a tiny, often zero, fraction of the price the original purveyor intended for a single person to pay to derive that benefit. That and the fact that software doesn't depreciate similarly to most physical items are the essential problems here. If the purveyor had intended to sell you a transferable license that might get passed on to many people, then you can damn sure bet they would charge a significantly higher price for it initially. Similarly, if the purveyor had intended to sell you a license that would let you sell as many copies of the software as you wanted (i.e. - be a distributor), then they would price it very differently (i.e. - one huge license price, or a per license sold revenue sharing agreement).
Secondary sales of licensed software that transfer the product against the wishes of the intellectual property owner essentially steal from them because the original price point they chose was based on the (legally justified) assumption that only one person would derive the expected benefit from the product. The secondary sale breaks the license agreement and violates the original pricing assumption of the original purveyor.
From the clues in the article clips (it would be great if someone could summarize the full ones) it seems that the family got a hold of the officer's email address and were sending him email. I have no idea how much or what was the topic of those emails, but I'm pretty sure the harassment claim stemmed from these emails and not from the original video taping.
... hoisted by his own petard possibly ...
As a private individual you can set up just about whatever kind of surveillance on your property that you like. The road is a public place and you are allowed to video tape in public places as well, so there should be no legal problem with doing what they did.
My main point is that it is obvious we don't have the full story from these news clips and all the people who are railing against this officer and his abuse of power are rushing to judgement. That being said, I'm still willing to bet the officer brought the suit because he was PO'ed about being reported to his superiors. People abuse the legal system this way all the time. The problem is that his suit has turned this minor incident into a big PR story and so the local government might be forced to take some kind of politically correct action against him for his speeding
Am I taking crazy pills? If you comply with the BSD license then it obviously gives you permission to create derivative works or even minor modifications.
"[2] Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:"
So long as you meet the conditions, which are to (a) reproduce the copyright notice, (b) the list of conditions and (c) the warranty disclaimer, then the license gives you permission to create modifications, derivative works, etc.
The problem is that the author has incorrectly included the original license grant into the list of conditions that must be reproduced by redistributors / modifiers / etc. A redistributor / modifier is not required to reproduce [2] in their redistribution / modification. See this post for more detail. Therefore, they are not required to allow modification, redistribution, etc. of their derivative work.
It seems that this lawyer has not been trained in computer science because he is glossing over an important detail of the license to reach his incorrect conclusion. The BSD license says (using the author's numbering and my emphasis):
"2 Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
3 * Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
4 * Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
5 * Neither the name of the [organization] nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission."
The license requires, per clauses 2-4, that a user reproduce (a) the copyright notice, (b) the list of conditions and (c) the disclaimer of the original license. The author reads this as requiring that the entire BSD license be reproduced in any redistrubtion or use of the code. But this is only true if (a), (b) and (c) comprise the entirety of the BSD license. I argue that they do not!
The key question is, "What is the 'list of conditions' that must be reproduced?" The author incorrectly claims that [2] is part of the list of conditions that must be maintained by a user, which would create a viral mechanism that this paper describes.
It is obvious from [2]'s use of the phrase "the following conditions" and the fact that [3, 4, 5] are preceded by asterisks and use the phrase "this list of conditions" that [2] is not intended to be part of the list of conditions. The list of conditions only consists of [3, 4, 5]. Therefore, redistributors / users are not required to maintain the original grant of the license [2] in their use or redistribution of the code.
The flaw in the author's argument is that he is incorrectly including the original grant of the license [2] into the list of conditions [3, 4, 5]. The license truly only requires that users reproduce clauses [1, 3, 4, 5, 6] of the BSD license in their redistrubtions or use.
I was actually looking forward to reading a quick introduction on Python as I primarily use C/C++ and I thought, "Hey, if it's on the front page of slashdot, then it's probably a decent article." Instead, I found this craptastic waste of time that doesn't even approach funny. It's just a bunch of really cheesy and way too obvious "jokes." Anyway, I don't mean to put down the author so much as whoever approved this story getting on the front page of slashdot. You guys are better than this. :)
As many other posters have noted, hydrogen is only an efficient storage medium for energy, so the energy to create hydrogen still has to come from somewhere. To power this "hydrogen economy" we can choose from non-renewables (oil, coal, nuclear), renewables (solar, hydro, wind, sea, geo) or some blend thereof.
In the near term it would be (is) oil and coal with a pinch of nuclear and hydro. If we wanted to get off of our dependence on oil in the near future, we'd have to go nearly all coal (not enough hydro and nuclear has too many image problems, the worst being the spent fuel). The U.S. COULD do this as we have some of the largest unexploited, extractable deposits of coal on the planet. Of course, coal has all the environmental drawbacks of oil and then some.
The real solution to our energy and environmental problems is to go with renewables. In the long run, we will use up all of the non-renewables (hence, the name) and while we're doing that we will wreak havoc on our environment and ourselves. Renewable energy, in particular solar power, solves all of our problems: it's safe, environmental impact is nearly nil and it's vastly abundant. Currently, solar power's one fatal flaw is infrastructure (i.e. - collection / production) cost. I believe in time that technology will solve this problem. Improving and deploying solar technology is where I would put the majority of my R&D money, not in developing fuel cells which only half addresses a small part of the real problem! (BTW, IMHO solar space power is unrealistic for the forseeable future)
Here's a picture of the future I'd like to see: every building is helping to power itself and others through solar cell roofs. During the day, most buildings (i.e. - residences) overproduce and spin up kinetic batteries and supply energy to the grid. At night they draw from these batteries and the grid. Sunny places (e.g. - Arizona, Nevada, etc.) really overproduce and help the less sunny places. The grid is backstopped by centralized nuclear and solar plants to supplement during times of extreme demand or lulls (i.e. - winter) in supply. The electric grid becomes much more distributed and energy flows from disparate sources to where it is needed as necessary in a minimal loss manner. This model also has nice side effects such as far fewer power losses in general and our infrastructure is harder to attack.
This brings us back to the question "How do we power automobiles?" We've seen that electric cars have severe drawbacks. Using electricity to produce hydrogen to power fuel cells is a good option. In the model above, if residences produced enough spare electricity to "power" their vehicles' hydrogen needs, then we wouldn't have the transmission loss we have in our current centralized model (this is around a 30% loss today). A possibly better option would be to develop kinetic batteries to power cars. These things are currently close to 80% efficient! The main drawback with them is a possible safety hazard (flying bits of shrapnel (bullets) after a minor accident).
In conclusion, if we are going to spend $100B on energy, then lets spend it on the real energy PRODUCTION problem first!
I can't believe I haven't seen Berkeley DB mentioned a LOT more here as a great alternative to both RDBMS and OODBMS.
BDB is a key-value DB -- it doesn't do SQL. Each DB is a simple "table" of keys to blocks of data. Tell BDB how to compare keys and augment BDB to convert the blocks of data into whatever you like (e.g. - un/serialize your objects). If you won't be doing too much convoluted SQL-like logic and you need an ACID datastore, then BDB is the way to go.
It has most everything you could want:
-- fully ACID (trnxns/rollback/snapshots)
-- single or multi-threaded/process access
-- fine grain locking
-- multi-node failover/balancing
-- multiple indexes per DB
-- SUPER flexible (trade features for speed)
-- AWESOME performance
-- little to no DB administration
-- under development for more than 10 years (debugged)
-- can handle DB sizes up to 256TB
-- can handle record sizes up to 4GB
-- supports most popular languages
-- is maintained by a world class company
-- you can buy support from the maintainers
-- open source + FREE for a lot of uses
I don't think anything out there with a similiar feature set can consistenly outpeform BDB.
First, let me say that the safest thing you can do is not store sensitive data. Barring that, the next safest thing you can do is store sensitive data on a physically secured machine(s) not attached to a network. Any data accesses/transfers should be done "manually" (moving HDDs, or CDs, etc.) and logged by trusted personnel. Barring that, you want your database
process to be able to locally decrypt stored data. This implies, regardless of encryption scheme, that the secret portion of your key somehow be locally available. Because the key is available locally it is subject to attack if your server comes under attack. Therefore the only thing you can do is make access to the secret key as difficult as possible...
First, regardless of the scheme you choose you should monitor this machine(s) and the database process(es) to the best of your ability to detect aberrent behavior. For example, if a database process dies, you need to understand why -- was someone trying to cause a core dump to get at its memory? Logging of machine level and process level events and online/offline auditing of your logs can help detect aberrent behavior. Contact a security firm if this kind of stuff keeps you up at night.
Second, physically secure the machine(s) to the best of your ability. Hosting facilities generally provide pretty high physical security. Buy good locks for your cage(s) and only give logged physical access to trusted personnel. You can get as crazy as you want with physical security if you are really worried...
Off the top of my head I can think of two ways to make access to your secret key difficult.
(1) Store the secret key only in the volatile memory of your database process -- don't allow core dumps of any sort and don't allow your process to swap to disk. The key should be entered by hand by trusted personnel through a secure terminal upon database process reboot and rekeying of the database.
An attacker from outside would need to be able to get access to the memory of your process and sift through it to find your key. There are ways to do this, but it would require a pretty sophisticated adversary. If you are monitoring activity on your
machine you would probably be able to detect such an attack. If a machine was physically stolen, continuous power would have to be supplied to it during the theft -- doable, but somewhat difficult.
(2) Have encryption/decryption performed by a "tamper-proof" hardware card or attached machine. Here, to "get at" the key the
attacker _should_ have to convince the card that he is the authorized process, usually through a challenge-response mechanism. At some point a secret needs to be provided to the process. The advantage with this method, is that after it is authenticated the process can forget its authentication secret and/or that the authentication secret is only good for one authentication. Again, the authentication secret should be entered into the processes' volatile memory by trusted personnel through a secure
terminal.
In this scenario, an attacker from outside would have to hijack the process after it has been authenitcated and direct it to execute his code. This attack is doable, but with good monitoring should be easily detected.
Insider attacks are much more difficult to prevent. With trusted inside personnel you can usually only depend on unimpeachable event logs to track down attacks after they occur. When trusted insiders collude it may be next to impossible to prevent and/or prosecute attacks.