They weren't aliens; they were futuristic mecha, and Kubrick was responsible for that part anyway. The ending isn't as straight-forward as it first seems.
Most of your requirements could easily be covered by git (or perhaps another DVCS). It takes very little disk space; doesn't store diffs; has great version control, file integrity checking, and backups; repos are self-contained and easily moved from computer to computer.
For coding use-cases or the one you mentioned--writable working tree and read-only history--it's perfect. However, there are design tradeoffs in git that may not make it *completely* suitable. Its handling of large binary files is probably a little slow. You could probably lower the zlib compression to get that working faster.
As for filesystem integration, Resier4's plugin system or something similar is suitable for the job. Unfortunately, reiser4's future is uncertain...
This is where that love-it/hate-it thing comes in, I guess...
(First off, I know you didn't say this, but it'll inevitably come up--those aren't aliens, damnit! They're advanced mecha. One of them is even the narrator; the movie starts with him/it saying "Those were the days when..." It's unfortunate that so many people never realized this, but on the other hand it clicks if you watch it a second time and then you get a lot more out of it.)
Many people have called the movie a fairy tale, and they'd be right to do so. But you can take that even further; it's a fairy tale that advanced mecha tell each other, long after humans have gone extinct. What parts of the last half-hour were real, if any? When he went back to his house that seemed both real and eerily artificial, the visuals suggested to me that it was all a vision in his head. They read his mind anyways; they might as well have been feeding him these images, even as he was really still half-frozen at the bottom of the ice excavation. The time-space continuum excuse especially sounded like a fabricated lie... Was it inevitable that David would be woken up by *something* someday, simply because he was not mortal? Perhaps there are thousands of discarded robots like him, buried inside the frozen Earth. The advanced mechas eventually dig out and feed a similar story to each that finally satisfies and terminate its program. Is this compassion between robots? Why do they do it? Are they trying to make robots dream, or are they saying that death is just another dream?
The movie asked a lot of questions about what it means to be human--similar to BR, but focused on love. I remember a particular review of A.I. (it had quite good reviews) that summed it up quite well and it seems to me the message of the movie: "To be real is to be mortal; to be human is to love, to dream and to perish." Perhaps that's why the advanced mechas gave him the choice. Hmm...
Anyways, personally I found that the ending was incredibly sad and not a happy one at all. I disagree that it would have been at all satisfying for the movie to just end on the ocean's floor, and for David to truly never "die." But you could take it either way, and stuff like this is why I found it so fascinating. And then of course there was the (first "mature") Alternate Reality Game/viral marketing that was really neat in itself. Ultimately, of course, it's up to your own experience.
Nuclear Energy is non-renewable? Excuse me? That is like stating that solar energy or wind power is non-renewable. They are ALL in infinite supply and are non-expendable (we cannot use them all up.) Uranium--while there is probably centuries' worth left--is used up during fission. It's ultimately non-renewable.
A bad solution is to create sym-links everywhere. A better solution would be to have labels appear as virtual directories.
How about hard links?
Granted, it isn't perfect; you'd likely use extra tools to manage it (e.g. http://linuxgazette.net/issue44/oneill.html), you couldn't label across filesystems, and disk space reporting would have a field day.
I wonder which filesystems have this sort of functionality built in? Omitting Reiser4...
Agreed; I have the Intel 2915 in mine and it's working like a charm. Be sure to use a recent kernel;)
As for laptop models, I highly recommend the ASUS line of whitebooks. I have the Z63A myself, and it's very solidly constructed, stylish, and gets up to 5 hours of battery life if I undervolt and dim it a bit. Relatively light too. Other ASUS models have actual video cards, although this one is just Intel Integrated. It still works like a charm. The build quality is great for the value--and a nice "open-source"y benefit of whitebooks in general is that you have the option of just buying the laptop shell, and purchasing the CPU, RAM, HD, and wi-fi card separately, and no Windows tax. There's a 12" or so model too, if that's what you're looking for, and I bet there are plenty of new models I haven't seen since I made my purchase.
No horror stories to report as of yet, other than some minor frustration with SATA in less recent kernels. It isn't too hard to get the widescreen resolution running natively on X either. I haven't had to apply any kernel patches to get it to work, though if I want to attempt suspend-to-disk I probably will have to.
I admit that I did install Windows before Linux, as Windows doesn't like it the other way around--but I easily could have made this a Linux-only machine. Just boot off the CD like normal, and make sure you have a wired connection when you're installing. No problems here. Ubuntu's LiveCD worked fine when I tried it once.
You're probably aware of this, but if you search Google for, say, "Linux on Z63A," you get pretty detailed guides--someone even installed a forum devoted soley to the subject! The model-specific resources are definitely much better than the general "linux on laptops" pages, as you've probably seen. Cheers!
Cracks are more a matter of reverse engineering the assembly code, which, considering that the binaries are right there for you to dissect, is pretty widely accomplished. Unlocking content, meanwhile, is a matter of encryption. The keys would be held at the central unlocking server and distributed as you bought them. "Cracking" the content would essentially be break the encryption. No vulnerable code to disassemble in this case.
(Though this doesn't take into consideration the possibility of buying a key once and sharing it with your friends. The only way crack-proof method I see around that is by using different keys for each customer, and that means re-encrypting a terabyte of data per customer, soo... bring on the quantum computers!)
Considering that the "OS," per se, is really just doing some very specific Cell processor management and tacking on features like voice chat and custom music, I'd say that they'd definitely be building it themselves. They wouldn't need all the scheduling, I/O handling, multitasking, etc. complexities of a modern OS; just simple implementations that don't have to deal with competing processes, the basic run-time support that games need, and the ever-present features. The games get to take care of the rest.
They didn't name it DA42 in the first place; they just happened to notice an asteroid having the provisional designation of 2001 DA42, if you read the summary correctly.
Slashdot Mirror
Have you read Terry Pratchett's Thud! ?
It's fairly up to interpretation, as other posters in this thread will likely share their views, but here's an old post I wrote on the subject: http://slashdot.org/comments.pl?sid=240961&cid=19641209
They weren't aliens; they were futuristic mecha, and Kubrick was responsible for that part anyway. The ending isn't as straight-forward as it first seems.
Most of your requirements could easily be covered by git (or perhaps another DVCS). It takes very little disk space; doesn't store diffs; has great version control, file integrity checking, and backups; repos are self-contained and easily moved from computer to computer.
For coding use-cases or the one you mentioned--writable working tree and read-only history--it's perfect. However, there are design tradeoffs in git that may not make it *completely* suitable. Its handling of large binary files is probably a little slow. You could probably lower the zlib compression to get that working faster.
As for filesystem integration, Resier4's plugin system or something similar is suitable for the job. Unfortunately, reiser4's future is uncertain...
This is where that love-it/hate-it thing comes in, I guess...
(First off, I know you didn't say this, but it'll inevitably come up--those aren't aliens, damnit! They're advanced mecha. One of them is even the narrator; the movie starts with him/it saying "Those were the days when..." It's unfortunate that so many people never realized this, but on the other hand it clicks if you watch it a second time and then you get a lot more out of it.)
Many people have called the movie a fairy tale, and they'd be right to do so. But you can take that even further; it's a fairy tale that advanced mecha tell each other, long after humans have gone extinct. What parts of the last half-hour were real, if any? When he went back to his house that seemed both real and eerily artificial, the visuals suggested to me that it was all a vision in his head. They read his mind anyways; they might as well have been feeding him these images, even as he was really still half-frozen at the bottom of the ice excavation. The time-space continuum excuse especially sounded like a fabricated lie... Was it inevitable that David would be woken up by *something* someday, simply because he was not mortal? Perhaps there are thousands of discarded robots like him, buried inside the frozen Earth. The advanced mechas eventually dig out and feed a similar story to each that finally satisfies and terminate its program. Is this compassion between robots? Why do they do it? Are they trying to make robots dream, or are they saying that death is just another dream?
The movie asked a lot of questions about what it means to be human--similar to BR, but focused on love. I remember a particular review of A.I. (it had quite good reviews) that summed it up quite well and it seems to me the message of the movie: "To be real is to be mortal; to be human is to love, to dream and to perish." Perhaps that's why the advanced mechas gave him the choice. Hmm...
Anyways, personally I found that the ending was incredibly sad and not a happy one at all. I disagree that it would have been at all satisfying for the movie to just end on the ocean's floor, and for David to truly never "die." But you could take it either way, and stuff like this is why I found it so fascinating. And then of course there was the (first "mature") Alternate Reality Game/viral marketing that was really neat in itself. Ultimately, of course, it's up to your own experience.
How about hard links?
Granted, it isn't perfect; you'd likely use extra tools to manage it (e.g. http://linuxgazette.net/issue44/oneill.html), you couldn't label across filesystems, and disk space reporting would have a field day.
I wonder which filesystems have this sort of functionality built in? Omitting Reiser4...
Near-perfect. According to the guidelines, you're supposed to use "!funny" instead of "notfunny."
Agreed; I have the Intel 2915 in mine and it's working like a charm. Be sure to use a recent kernel ;)
As for laptop models, I highly recommend the ASUS line of whitebooks. I have the Z63A myself, and it's very solidly constructed, stylish, and gets up to 5 hours of battery life if I undervolt and dim it a bit. Relatively light too. Other ASUS models have actual video cards, although this one is just Intel Integrated. It still works like a charm. The build quality is great for the value--and a nice "open-source"y benefit of whitebooks in general is that you have the option of just buying the laptop shell, and purchasing the CPU, RAM, HD, and wi-fi card separately, and no Windows tax. There's a 12" or so model too, if that's what you're looking for, and I bet there are plenty of new models I haven't seen since I made my purchase.
No horror stories to report as of yet, other than some minor frustration with SATA in less recent kernels. It isn't too hard to get the widescreen resolution running natively on X either. I haven't had to apply any kernel patches to get it to work, though if I want to attempt suspend-to-disk I probably will have to.
I admit that I did install Windows before Linux, as Windows doesn't like it the other way around--but I easily could have made this a Linux-only machine. Just boot off the CD like normal, and make sure you have a wired connection when you're installing. No problems here. Ubuntu's LiveCD worked fine when I tried it once.
You're probably aware of this, but if you search Google for, say, "Linux on Z63A," you get pretty detailed guides--someone even installed a forum devoted soley to the subject! The model-specific resources are definitely much better than the general "linux on laptops" pages, as you've probably seen. Cheers!
Cracks are more a matter of reverse engineering the assembly code, which, considering that the binaries are right there for you to dissect, is pretty widely accomplished. Unlocking content, meanwhile, is a matter of encryption. The keys would be held at the central unlocking server and distributed as you bought them. "Cracking" the content would essentially be break the encryption. No vulnerable code to disassemble in this case.
(Though this doesn't take into consideration the possibility of buying a key once and sharing it with your friends. The only way crack-proof method I see around that is by using different keys for each customer, and that means re-encrypting a terabyte of data per customer, soo... bring on the quantum computers!)
Considering that the "OS," per se, is really just doing some very specific Cell processor management and tacking on features like voice chat and custom music, I'd say that they'd definitely be building it themselves. They wouldn't need all the scheduling, I/O handling, multitasking, etc. complexities of a modern OS; just simple implementations that don't have to deal with competing processes, the basic run-time support that games need, and the ever-present features. The games get to take care of the rest.
They didn't name it DA42 in the first place; they just happened to notice an asteroid having the provisional designation of 2001 DA42, if you read the summary correctly.