But what's in Snowcrash? Isn't that the one with the sword brandishing pizza
delivery guy? I held off on reading it because I have this mental block that
when a sword/light sabre is involved, it crossed that thin line into fantasy
aka space opera.
You need to read it. How can you not read a book that begins:
The Deliverator belongs to an elite order, a hallowed subcategory. He's got esprit up to here. Right now, he is preparing to carry out his third mission of the night. His uniform is black as activated charcoal, filtering the very light out of the air. A bullet will bounce off its arachnofiber weave like a wren hitting a patio door, but excess perspiration wafts through it like a breeze through a freshly napalmed forest. Where his body has bony extremities, the suit has sintered armorgel: feels like gritty jello, protects like a stack of telephone books.
It only gets better.
Plus the opinions of some that say that Neal S would write
and write and the book will end when he decides to stop. (or something to that
effect).
They're right. But if the worst thing you can say about something is that you wanted more of it, then it must be doing something right.
Even The Island and Paycheck and Deja Vu (human cloning and memory erasure and time travel), while over the top only as Bay and Woo and Scott can do, still offered some interesting insights into the consequences of those actions.
I use Paycheck as my favourite example of how a really good idea for a science fiction movie can go horribly wrong due to a hammy script.
Sheldrake reported something like a 40% success rate on a test of esp using phone calls, which is higher than the expected 33% chance value [...].
And also almost certainly bullshit. This stuff isn't real. We've been testing it for decades, and it's come to nothing, because there's nothing there.
You can't prove a negative. We can assert that we have so far been unable to detect any such effects, which merely puts telepathy on a par with the Higgs boson and gravitational waves.
Has anyone read Anathem yet? It is a difficult read, mainly because Stephensons goes on a 100-page philosophical tangent, but it is very rewarding. It also contains the most realistic space battle description evar. Definitely my favourite science fiction novel, although I am not a big sci fi fan. I tried reading Asimove short stories, and found myself bored out of my mind. Well, science fiction does not age well.
From my point of view, Anathem is one of the best novels I've ever read, and certainly the best published in the last couple of years. Unfortunately, you do need to be highly-educated to understand parts of it. A good grounding in mathematics and the philosophy of science is essential!
I agree, I think there's been a backlash against technobabble which is steering scifi away from Star Trek tech-porn towards a more BSG style focused more on people than cool gadgets. I certainly enjoy Star Trek, but they've saturated the gee-whiz-look-at-this-cool-gadget market, and people are ready for something new. Now that we've been exploring space for a few decades, and everyone has cool gadgets, they want more depth in the stories. It's not so much that scifi is running out of steam, it's just evolving as all genres do.
No, it just means that people are starting to realise that scy fy is not science fiction. Science fiction has always been about the people. Read some great science fiction novels: Frank Herbert's "Dune", Greg Bear's "Eon", Heinlein's "The Moon is a Harsh Mistress", Orson Scott Card's "Ender's Game", Asimov's "The End of Eternity", Poul Anderson's "Tau Zero". In none of these novels are the protagonists problems solved by a technological deus ex machina; in all of them, the technology and speculative science is merely a barely-explained canvas upon which a human drama is played out.
BSG wasn't considered "good" science fiction because "focussing on the people" was a new and clever evolution of the genre; rather, it was "good" because it went back to the form that made science fiction great.
It's not just disingenuous it's just just plain wrong. SF has never been about predicting the future. SF is an extremely broad genre but if I had to put it into a sound bite I would say it is about positing a "what if" and writing a story about it(this leave out a bunch of SF subcategories I know)... what if advanced aliens showed up tomorrow. What if we all had computers in our brains. What if we could travel quickly across the galaxy. What if there was an evil dystopic government that monitored our every move. They are all clichés in SF... but the stories written around them are about how human beings react to the changes. SF in a literacy genre that is an obvious reaction to the rapid changes in technology in the last several hundred years. And sometimes there are green slave girls involved.
Exactly. Science fiction is not about science, or technology, or trying to predict the future. Science fiction is about people, and regularly points out that people are people no matter what technological toys you hand them.
You need to check out Baen Books -- they're a publisher that still publishes lots of excellent science fiction (as well as some pretty bad stuff too, admittedly) -- and all their books are available as DRM-free e-books. In particular, the Free Library is great.
Some publishers do "get it". Unfortunately, the majority don't.
The issue suddenly became much less of a big deal to me. In the end, it comes down to whether you trust the quality of Fedora packages and the security of their signing key. Either you do, in which case this isn't a problem, or you don't, in which case you shouldn't be using Fedora.
Things get complicated when the project's server are physically compromised. I agree that the mechanism is neat and very useful but the developers jumped the gun when they altered the default configuration without notifying anyone. This change wasn't even mentioned in the release notes. That alone raises questions about the project's development process.
Fedora prided itself with default security policy since it had SELinux enabled by default. This change is exactly in the reverse direction.
In some ways, I think this is a good idea. If users are used to "if I want to install something then I need to enter my/root's password," then they will get desensitised to the necessity of checking that the package is from a trustworthy source.
With Fedora 12's approach, because users will only be prompted for a password for installing unsigned packages, it makes it automatically more notable.
In any case, I agree with you that this is a poorly-thought-out, poorly-documented, and hard-to-locally-revert change. And thus sucks, despite honourable intentions. "The road to hell...," etc.
My favoured approach:
Installing signed package from repository: prompt for user's password.
Installing unsigned package/package from source other than repository: prompt for root's password.
Upgrading signed packages from repository: no prompt.
Trusting the repos has nothing to do with it. If I've got my users on Fedora as their desktops, I don't want them installing packages that I don't know about. Why should the average user have a web or FTP server running on the desktop? Default configurations have frequently been the location for vulnerabilities, and many users could install a service and then not be able to secure it properly because most of those configuration files require root or sudo access.
I agreed with you about this, so I investigated. It turns out that daemons packaged by Fedora are disabled by default, and require someone with root access to enable them. A package won't pass review if that's not the case.
The issue suddenly became much less of a big deal to me. In the end, it comes down to whether you trust the quality of Fedora packages and the security of their signing key. Either you do, in which case this isn't a problem, or you don't, in which case you shouldn't be using Fedora.
My biggest problem with KDE 4.3 is the fact that SSL is completely broken. I've stopped using Konqueror altogether because of this, and it causes annoyances in KMail as well. I can't believe they released with a bug that serious.
That is strange. It works fine for me on Fedora. Have you reported the bug to your distribution?
And how, exactly, would you propose these missing elements?
*cough* What I meant was, how would you propose to implement these missing elements?
The comments on this story give me the distinct impression that no matter what Google does w.r.t. the personal data they have to store on their users, it won't be enough.
Interesting idea of "control". There is no way to determine this is more than just pushing buttons in a UI.
There is neither transparency and an element of verification that the functions were indeed performed, nor is there an element of validation to demonstrate the effective execution of the user selected functions.
And how, exactly, would you propose these missing elements?
Your suggestion: Place the app's binaries on the server for each architecture. Go around to each machine and set up environment modules. Write a script to start the app and put it in a directory on the server. Tell everybody "hey, run X by double clicking on it here."
My actual solution:
Place the app's binaries on the server for each architecture. Place the environment module scripts which choose which binaries to choose on the server as well.
Create a package containing the minimal environment modules code needed to get each machine to access the central server and pick up the main modules scripts. Place it in your local package repository (alongside your bandwidth-saving mirror of the distribution's package repository). Remote install it on every user machine with a couple of lines of shell. Tell users to run X just like they'd run any other application -- by selecting it from the "Applications" menu.
Go make coffee and grab a snack.
New version comes out? Install it, create new modules file, test it, then change default version to be used to new version once you're satisfied. All without touching a user workstation. Some users need to carry on using a particular old version? You can do that too, by adding one line of shell to their shell login script (which is easy because you're mounting their home directories from the NAS).
When you've got tens of users, all of whom need to run slightly different versions (or combinations of versions!) of software, and you want to manage all that in a way that, from the users' point of view, Just Works? "Hey, run X by double clicking on it here," is mediocrity.
To satisfy my personal curiosity: do you actual administer multi-machine Linux deployments? I don't, but I've been on the user end of several very competent and large organisations who have large numbers of Linux workstations, and I've never heard, "Hey, run X by double clicking on it here," in the way you describe.
Maybe Blizzard should go and beg iD Software for some advice, then. They've been shipping perfectly functioning universal Linux builds of their games for years now. Or perhaps 2D Boy? Or Introversion. If tiny indie studios and massive names in the industry can all manage it, Blizzard could too.
Your average desktop user does not want to go, 'Oh, well, I'm running on Processor X, with distribution Y, patch Z. I guess that means I need/this/ tarball (or this subdirectory of the big tarball).' Fat binaries solve this problem.
Your average desktop user doesn't do that though. He goes to his "Add/Remove Applications" applet in the system configuration tool, types the name of the application into the search field, clicks "Install" -- and the system takes care of working out which binaries need to be downloaded and installed for him.
Adobe's current installation instructions for the Flash plugin (on Fedora) are to manually install an architecture-independent package which enables the Adobe package repository, then install the Flash plugin by the normal "Add/Remove Applications" procedure. This ensures that the user gets the right architecture and library linkage, an installation layout suited to the distribution, and that the plugin is kept fully up-to-date using the normal package updating process. Adobe's website is even very reliable about detecting that I'm running Fedora and directing me to the correct instructions for enabling their repository.
I have a hazy recollection of the last time I was faced with the problem you describe, but I think it was probably while trying to install ATi graphics drivers on Fedora Core 3. In 2005. Yes, that would be FOUR YEARS AGO.
And that would be almost-excusable, except for the brain-dead "open source is king" approach for updates: "The whole-thing's free anyway, why not just re-send the whole thing?" binary patches are pretty-much unheard of. Of course, sending the whole thing is really just a work-around because-
Package managers generally do NOT bother to detect when they are about to clobber or alter "the wrong file". When they do, they don't bother to keep a record of what they/would/ consider to be "the right file", making "merging" impossible and difference examination a guessing game. That doesn't even matter, because the first step in an "Upgrade" is usually to just completely remove the existing package, which means...
Whoa there, chum. Let's get some facts in there.
I run Fedora, a well-known Linux distribution that practically has "open source is king" as its slogan. It uses RPM, a well-known package system. Funnily enough, I just updated my system, and, guess what, the update process downloaded binary patches for my existing packages. Well gosh.
And, even stranger, I have a file on my system called '/etc/dovecot.conf.rpmnew'. Believe it or not, it's there because when I last updated my Dovecot package, RPM detected that I had modified my configuration file and carefully didn't clobber it.
You clearly have no idea about the current state of Linux package management technology. Don't let that get in the way of your ignorance-fueled rant though!
True, but the ability to handle such things can come in handy. As an example, suppose you've got a setup where you're running apps off a server. You've got several different hardware platforms going, but you want your users to be able to double click the server hosted apps without worrying about picking the right one for the computer they happen to be sitting at. A fat binary is pretty much the only way to solve that problem.
The correct solution to this problem is environment modules. One of their many applications is setting up the scheme you describe -- totally transparently to the user, and in a easily maintainable way for the administrator, and I've seen them used successfully company-wide at a large semiconductor engineering corporation I worked for in the past.
Those of us who actually care about inode counts think such a scheme is an insanely bad idea. This means that for every binary with three architectures (say i386, i386+SSE3, x86_64), you now have three binary files and a script file instead of one file. You've just increased the number of inodes your OS takes by a significant amount.
Is this seriously an issue with 21st century filesystems?
The council is not a democratic institution, they conduct negotiations in secret, they advocate draconian measures, they frequently force the European Parliament, the only elected body of the EU, to bend down to it's will. We need to get rid of these people NOW! They are a very dangerous bunch of people.
The European Council is indeed a democratic institution: it's comprised of the heads of state or government of the member states, all of whom are elected (in the case of monarchies, the Prime Minister sits on the Council).
The European Commission is the non-democratic farce comprised of appointed, unelected bureaucrats who do things like try and push through software patents in a fisheries bill and ignore demands made by our elected representatives in the European Parliament.
Since there is no tangential velocity, unless the thing gets up to geo, there's going to have to be a big rocket to supply the additional deltav to reach orbit.
That's correct. The space elevator design calls for the elevator to stretch from the surface, to a large space station in GEO, to a point the same distance the other side of GEO. That way you can get a big bunch of the velocity needed for an interplanetary trajectory simply by going to the outer end of the space elevator and letting go!
And you're also quite right in saying that 5 m/s is too slow for human transit to GEO, but it's probably good enough for cargo payloads. One of the biggest problems, though, is that the elevator would travel through the van Allen belts, and you don't want to spend long there or the radiation will destroy your electronics.
The key word that's part of ICBM is "ballistic", from the Greek ballein, I throw. It's travelling through extremely thin gas, and its trajectory is therefore practically simple Newtonian dynamics. Its position from moment to moment should be extremely predictable.
That's why penetration aids were invented. Sure, it's easy to hit something, but picking out which of the 20-30 ballistic targets is the actual warhead that's trying to blow you away is hard.
Slashdot Mirror
But what's in Snowcrash? Isn't that the one with the sword brandishing pizza delivery guy? I held off on reading it because I have this mental block that when a sword/light sabre is involved, it crossed that thin line into fantasy aka space opera.
You need to read it. How can you not read a book that begins:
The Deliverator belongs to an elite order, a hallowed subcategory. He's got esprit up to here. Right now, he is preparing to carry out his third mission of the night. His uniform is black as activated charcoal, filtering the very light out of the air. A bullet will bounce off its arachnofiber weave like a wren hitting a patio door, but excess perspiration wafts through it like a breeze through a freshly napalmed forest. Where his body has bony extremities, the suit has sintered armorgel: feels like gritty jello, protects like a stack of telephone books.
It only gets better.
Plus the opinions of some that say that Neal S would write and write and the book will end when he decides to stop. (or something to that effect).
They're right. But if the worst thing you can say about something is that you wanted more of it, then it must be doing something right.
Even The Island and Paycheck and Deja Vu (human cloning and memory erasure and time travel), while over the top only as Bay and Woo and Scott can do, still offered some interesting insights into the consequences of those actions.
I use Paycheck as my favourite example of how a really good idea for a science fiction movie can go horribly wrong due to a hammy script.
Sheldrake reported something like a 40% success rate on a test of esp using phone calls, which is higher than the expected 33% chance value [...].
And also almost certainly bullshit. This stuff isn't real. We've been testing it for decades, and it's come to nothing, because there's nothing there.
You can't prove a negative. We can assert that we have so far been unable to detect any such effects, which merely puts telepathy on a par with the Higgs boson and gravitational waves.
Sci-Fi ran out of steam when the writers started putting more emphasis on sex and bottom of the barrel characters that represent the worst of society.
Sorry, what? Go read some real science fiction.
I assume that you're basing your assertion on the crap that you see on TV and in the cinemas, right?
Already we have areas of science so specialized that scientists can not communicate to each other as to the details of their expertise.
Haha. You might be interested in this short science fiction story, then: "Babel II" by Christopher Anvil
(If you enjoyed that, check out the Webscriptions website -- loads of DRM-free science fiction and fantasy e-books)
Has anyone read Anathem yet? It is a difficult read, mainly because Stephensons goes on a 100-page philosophical tangent, but it is very rewarding. It also contains the most realistic space battle description evar. Definitely my favourite science fiction novel, although I am not a big sci fi fan. I tried reading Asimove short stories, and found myself bored out of my mind. Well, science fiction does not age well.
From my point of view, Anathem is one of the best novels I've ever read, and certainly the best published in the last couple of years. Unfortunately, you do need to be highly-educated to understand parts of it. A good grounding in mathematics and the philosophy of science is essential!
I agree, I think there's been a backlash against technobabble which is steering scifi away from Star Trek tech-porn towards a more BSG style focused more on people than cool gadgets. I certainly enjoy Star Trek, but they've saturated the gee-whiz-look-at-this-cool-gadget market, and people are ready for something new. Now that we've been exploring space for a few decades, and everyone has cool gadgets, they want more depth in the stories. It's not so much that scifi is running out of steam, it's just evolving as all genres do.
No, it just means that people are starting to realise that scy fy is not science fiction. Science fiction has always been about the people. Read some great science fiction novels: Frank Herbert's "Dune", Greg Bear's "Eon", Heinlein's "The Moon is a Harsh Mistress", Orson Scott Card's "Ender's Game", Asimov's "The End of Eternity", Poul Anderson's "Tau Zero". In none of these novels are the protagonists problems solved by a technological deus ex machina; in all of them, the technology and speculative science is merely a barely-explained canvas upon which a human drama is played out.
BSG wasn't considered "good" science fiction because "focussing on the people" was a new and clever evolution of the genre; rather, it was "good" because it went back to the form that made science fiction great.
It's not just disingenuous it's just just plain wrong. SF has never been about predicting the future. SF is an extremely broad genre but if I had to put it into a sound bite I would say it is about positing a "what if" and writing a story about it(this leave out a bunch of SF subcategories I know)... what if advanced aliens showed up tomorrow. What if we all had computers in our brains. What if we could travel quickly across the galaxy. What if there was an evil dystopic government that monitored our every move. They are all clichés in SF... but the stories written around them are about how human beings react to the changes. SF in a literacy genre that is an obvious reaction to the rapid changes in technology in the last several hundred years. And sometimes there are green slave girls involved.
Exactly. Science fiction is not about science, or technology, or trying to predict the future. Science fiction is about people, and regularly points out that people are people no matter what technological toys you hand them.
You need to check out Baen Books -- they're a publisher that still publishes lots of excellent science fiction (as well as some pretty bad stuff too, admittedly) -- and all their books are available as DRM-free e-books. In particular, the Free Library is great.
Some publishers do "get it". Unfortunately, the majority don't.
The issue suddenly became much less of a big deal to me. In the end, it comes down to whether you trust the quality of Fedora packages and the security of their signing key. Either you do, in which case this isn't a problem, or you don't, in which case you shouldn't be using Fedora.
Things get complicated when the project's server are physically compromised. I agree that the mechanism is neat and very useful but the developers jumped the gun when they altered the default configuration without notifying anyone. This change wasn't even mentioned in the release notes. That alone raises questions about the project's development process.
Fedora prided itself with default security policy since it had SELinux enabled by default. This change is exactly in the reverse direction.
In some ways, I think this is a good idea. If users are used to "if I want to install something then I need to enter my/root's password," then they will get desensitised to the necessity of checking that the package is from a trustworthy source.
With Fedora 12's approach, because users will only be prompted for a password for installing unsigned packages, it makes it automatically more notable.
In any case, I agree with you that this is a poorly-thought-out, poorly-documented, and hard-to-locally-revert change. And thus sucks, despite honourable intentions. "The road to hell...," etc.
My favoured approach:
Trusting the repos has nothing to do with it. If I've got my users on Fedora as their desktops, I don't want them installing packages that I don't know about. Why should the average user have a web or FTP server running on the desktop? Default configurations have frequently been the location for vulnerabilities, and many users could install a service and then not be able to secure it properly because most of those configuration files require root or sudo access.
I agreed with you about this, so I investigated. It turns out that daemons packaged by Fedora are disabled by default, and require someone with root access to enable them. A package won't pass review if that's not the case.
The issue suddenly became much less of a big deal to me. In the end, it comes down to whether you trust the quality of Fedora packages and the security of their signing key. Either you do, in which case this isn't a problem, or you don't, in which case you shouldn't be using Fedora.
My biggest problem with KDE 4.3 is the fact that SSL is completely broken. I've stopped using Konqueror altogether because of this, and it causes annoyances in KMail as well. I can't believe they released with a bug that serious.
That is strange. It works fine for me on Fedora. Have you reported the bug to your distribution?
And how, exactly, would you propose these missing elements?
*cough* What I meant was, how would you propose to implement these missing elements?
The comments on this story give me the distinct impression that no matter what Google does w.r.t. the personal data they have to store on their users, it won't be enough.
Interesting idea of "control". There is no way to determine this is more than just pushing buttons in a UI. There is neither transparency and an element of verification that the functions were indeed performed, nor is there an element of validation to demonstrate the effective execution of the user selected functions.
And how, exactly, would you propose these missing elements?
Your suggestion: Place the app's binaries on the server for each architecture. Go around to each machine and set up environment modules. Write a script to start the app and put it in a directory on the server. Tell everybody "hey, run X by double clicking on it here."
My actual solution:
Place the app's binaries on the server for each architecture. Place the environment module scripts which choose which binaries to choose on the server as well.
Create a package containing the minimal environment modules code needed to get each machine to access the central server and pick up the main modules scripts. Place it in your local package repository (alongside your bandwidth-saving mirror of the distribution's package repository). Remote install it on every user machine with a couple of lines of shell. Tell users to run X just like they'd run any other application -- by selecting it from the "Applications" menu.
Go make coffee and grab a snack.
New version comes out? Install it, create new modules file, test it, then change default version to be used to new version once you're satisfied. All without touching a user workstation. Some users need to carry on using a particular old version? You can do that too, by adding one line of shell to their shell login script (which is easy because you're mounting their home directories from the NAS).
When you've got tens of users, all of whom need to run slightly different versions (or combinations of versions!) of software, and you want to manage all that in a way that, from the users' point of view, Just Works? "Hey, run X by double clicking on it here," is mediocrity.
To satisfy my personal curiosity: do you actual administer multi-machine Linux deployments? I don't, but I've been on the user end of several very competent and large organisations who have large numbers of Linux workstations, and I've never heard, "Hey, run X by double clicking on it here," in the way you describe.
Maybe Blizzard should go and beg iD Software for some advice, then. They've been shipping perfectly functioning universal Linux builds of their games for years now. Or perhaps 2D Boy? Or Introversion. If tiny indie studios and massive names in the industry can all manage it, Blizzard could too.
Your average desktop user does not want to go, 'Oh, well, I'm running on Processor X, with distribution Y, patch Z. I guess that means I need /this/ tarball (or this subdirectory of the big tarball).' Fat binaries solve this problem.
Your average desktop user doesn't do that though. He goes to his "Add/Remove Applications" applet in the system configuration tool, types the name of the application into the search field, clicks "Install" -- and the system takes care of working out which binaries need to be downloaded and installed for him.
Adobe's current installation instructions for the Flash plugin (on Fedora) are to manually install an architecture-independent package which enables the Adobe package repository, then install the Flash plugin by the normal "Add/Remove Applications" procedure. This ensures that the user gets the right architecture and library linkage, an installation layout suited to the distribution, and that the plugin is kept fully up-to-date using the normal package updating process. Adobe's website is even very reliable about detecting that I'm running Fedora and directing me to the correct instructions for enabling their repository.
I have a hazy recollection of the last time I was faced with the problem you describe, but I think it was probably while trying to install ATi graphics drivers on Fedora Core 3. In 2005. Yes, that would be FOUR YEARS AGO.
And that would be almost-excusable, except for the brain-dead "open source is king" approach for updates: "The whole-thing's free anyway, why not just re-send the whole thing?" binary patches are pretty-much unheard of. Of course, sending the whole thing is really just a work-around because-
Package managers generally do NOT bother to detect when they are about to clobber or alter "the wrong file". When they do, they don't bother to keep a record of what they /would/ consider to be "the right file", making "merging" impossible and difference examination a guessing game. That doesn't even matter, because the first step in an "Upgrade" is usually to just completely remove the existing package, which means...
Whoa there, chum. Let's get some facts in there.
I run Fedora, a well-known Linux distribution that practically has "open source is king" as its slogan. It uses RPM, a well-known package system. Funnily enough, I just updated my system, and, guess what, the update process downloaded binary patches for my existing packages. Well gosh.
And, even stranger, I have a file on my system called '/etc/dovecot.conf.rpmnew'. Believe it or not, it's there because when I last updated my Dovecot package, RPM detected that I had modified my configuration file and carefully didn't clobber it.
You clearly have no idea about the current state of Linux package management technology. Don't let that get in the way of your ignorance-fueled rant though!
Attempting this in a world where even an x86 binary wouldn't work on all x86-linux-pc boxes (static linking, yeah...yeah)
Laugh it up, but my Quake 4 binaries I downloaded in 2007 work absolutely flawlessly on my mid-2009 Linux distro.
True, but the ability to handle such things can come in handy. As an example, suppose you've got a setup where you're running apps off a server. You've got several different hardware platforms going, but you want your users to be able to double click the server hosted apps without worrying about picking the right one for the computer they happen to be sitting at. A fat binary is pretty much the only way to solve that problem.
The correct solution to this problem is environment modules. One of their many applications is setting up the scheme you describe -- totally transparently to the user, and in a easily maintainable way for the administrator, and I've seen them used successfully company-wide at a large semiconductor engineering corporation I worked for in the past.
Those of us who actually care about inode counts think such a scheme is an insanely bad idea. This means that for every binary with three architectures (say i386, i386+SSE3, x86_64), you now have three binary files and a script file instead of one file. You've just increased the number of inodes your OS takes by a significant amount.
Is this seriously an issue with 21st century filesystems?
The council is not a democratic institution, they conduct negotiations in secret, they advocate draconian measures, they frequently force the European Parliament, the only elected body of the EU, to bend down to it's will. We need to get rid of these people NOW! They are a very dangerous bunch of people.
The European Council is indeed a democratic institution: it's comprised of the heads of state or government of the member states, all of whom are elected (in the case of monarchies, the Prime Minister sits on the Council).
The European Commission is the non-democratic farce comprised of appointed, unelected bureaucrats who do things like try and push through software patents in a fisheries bill and ignore demands made by our elected representatives in the European Parliament.
I think you may have got the two confused.
Since there is no tangential velocity, unless the thing gets up to geo, there's going to have to be a big rocket to supply the additional deltav to reach orbit.
That's correct. The space elevator design calls for the elevator to stretch from the surface, to a large space station in GEO, to a point the same distance the other side of GEO. That way you can get a big bunch of the velocity needed for an interplanetary trajectory simply by going to the outer end of the space elevator and letting go!
And you're also quite right in saying that 5 m/s is too slow for human transit to GEO, but it's probably good enough for cargo payloads. One of the biggest problems, though, is that the elevator would travel through the van Allen belts, and you don't want to spend long there or the radiation will destroy your electronics.
The key word that's part of ICBM is "ballistic", from the Greek ballein, I throw. It's travelling through extremely thin gas, and its trajectory is therefore practically simple Newtonian dynamics. Its position from moment to moment should be extremely predictable.
That's why penetration aids were invented. Sure, it's easy to hit something, but picking out which of the 20-30 ballistic targets is the actual warhead that's trying to blow you away is hard.
The only power the US president has is to destory the world. In everything else he is powerless.
And even then, his orders must be confirmed by a Senate-approved official such as the Director of Central Intelligence.