BTC was a horribly designed currency from the getgo
Actually, much of it is really well designed -- as evidenced by the complete absence of Bitcoin counterfeiters, despite the fact that there is a huge financial incentive to counterfeit Bitcoins.
As far as the economic theory goes, you may be right... but if so, then BitCoin will fail and some other system will come along to replace it, hopefully taking its mistakes into account in the new design.
BitCoin is an impressive piece of distributed cryptogaphy and a big leap forward compared to, say, PayPal or (shudder) Flooz. It's not perfect, but then nothing is -- and so far it's held up a lot better than I would have predicted.
Well, if nothing else, the moon would make a good location for a moon base.;) If there was a practical way to mine rocket fuel on the moon, I think that could be a good refuelling/re-launching point for rockets bound for other parts of the solar system.
Also, I understand that the far side of the moon would be a good location for telescopes that want to minimize EM pollution from Earth.
Macintosh computers may be flawless when running the latest software on the latest version of OS X, but things quickly go awry when you want to run a newer application on an older version of OS X (where a.1 difference matters) or an older application
This is actually a good point. Apple and Microsoft have very different approaches to dealing with old software.
Microsoft's approach is "keep compatibility all the way back to MS-DOS 1.0, no matter what the cost!". Which is good, in that if you want to you can pretty much run any Windows or DOS software from the last three decades and expect it to work. But it's also bad, because maintaining all that backwards compatibility makes the OS so much more complicated to use (and, I'd imagine, to test) that the user experience suffers.
Apple, on the other hand, favors the "keep compatibility for two years or so, and after that take out the bits we decide we don't like and shoot them in the head. Users will just have to upgrade and like it." Which is good because the OS stays relatively simple, without too much cruft building up, so the user experience with is consistent... but if you want to run old software you're often simply out of luck (e.g. anything PowerPC or earlier).
That's against the Law of Land Warfare, landmines have to be either marked or under direct observation.
Great, but people who go around planting land mines don't necessarily spend a lot of time worrying about how well they are complying with the Law of Land Warfare.
This defeats one of the "selling points" of using a dll. When functionality improves, the library is updated and all consumers of that library benefit from it.
Yes, you're quite right, but that's a tradeoff that might be worth making. Upgrading a shared library that an application already is using is a risk, since after the upgrade you are running an application in a configuration that its developer never tested against. Better perhaps to have the developer upgrade his application to the new version of the shared library, let him test it thoroughly, and then when he has released his new app version, download it (at which point it would auto-download the new shared library version that it is linked against).
Locking in a specific version via hash would be functionally no different than just statically compiling the library into the binary.
True.
Then what is the point at all?
1) Avoid any chance of "DLL Hell" 2) Save disk space 3) Reduce download size 4) Allow the use of LGPL libraries in non-(L)GPL software
But mostly (1). Keep in mind this idea is an alternative to the previous poster's suggestion of packaging a copy of every shared library along with the application that uses it -- which would also be functionally equivalent to static linking, but without the benefits 2 and 3.
I understand the benefits of shared libraries, but storage space is dirt-cheap today and I think a lot of problems might be solved simply by letting lots of pieces of software bundle their favorite versions of dependent libraries.
Or, how about this: Instead of linking to shared libraries by their filenames, applications specify the shared libraries they'd like to link to via md5 hashes of the libraries' contents. The linker checks its shared-library database-index (which could just be a directory whose directory-entries are md5 hash codes) to see if it has a shared library with that md5 hash installed; if yes, it links the application process to it; if no, it auto-downloads the shared library with that hash from the web repository, installs it, and then links the application process to it.
The advantages would be:
No library collisions, ever (well, to the extent that md5 hashes are unique, anyway). No version mismatches, ever (each app will always run using the libraries it was built against, and no others). No mucking about with LD_LIBRARY_PATH (as all shared libraries are auto-stored for you No manually installed missing libraries (they will instead be installed as necesary, on demand) No space wasted by multiple copies of the same library present on your disk at once
Some possible disadvantages:
No way to "patch" behavior of multiple applications by upgrading only a shared library they link to (you'd have to upgrade each of the applications instead, so that they reference the new library version's md5 hash)
Possible security issues from auto-installing shared libraries with malicious code (although arguably you either trust a developer enough to install his program, or you don't; the mechanics of how different parts of the program are installed aren't necessarily relevant)
And yet between them have killed less people than most other major process catastrophies throughout history.
In the most literal sense, that's probably true. But immediate death isn't the only problem that comes from a radiation disaster. Uprooting entire communities on a few hours' notice is not pleasant for anyone, and results in all kinds of indirect social costs.
And of course there is the monetary cost. Belarus estimates its costs from the Chernobyl disaster at $235 billion, and to this day Chernobyl is still eating up 5-7% of the budget of the Ukraine.
Taking a look at the worlds largest solar power plant and scaling it from 300kWh to the 7.5GWh that Fukushima Daiichi generated, and it would use 72000 acres of land, permanently.
Land that nobody was living on. That's a key difference -- when a solar plant goes up, it does so in a controlled and planned manner. People aren't turned out of their houses in the middle of the night and told they can never go home again. Neighborhoods aren't torn apart. Lives aren't ruined.
Three Mile Island didn't "blow". I (and thousands of others) wouldn't be living within 20 miles of the place right now if it had.
... which is actually a pretty good indication of what's holding nuclear back. If things go sufficiently wrong, large swaths of valuable real estate and infrastructure become unlivable, and hundreds of thousands of people have to be permanently relocated.
This translates directly into the huge liability, ultra-conservative design, high expenses, and public paranoia we see regarding nuclear today. I don't see any clear way around it except avoiding the use of radioactive materials.
This is probably overly-obvious advice, but: stream music that you like while you work. That will give the non-verbal/non-analytical parts of your brain something to chew on while the analytical parts are working on your code; if they like it, they'll stop sending so many "I'm bored" interrupts up to your conscious mind.
Either that, or find a way to make your work more interesting. Bored with JavaScript? Recode your app in Brainf*ck;)
But it leads me to suspect that in the race for bragging rights about having the "fastest JavaScript", developers have prioritized execution speed over memory efficiency. Personally I'd be happy with a slower JavaScript that paid attention to memory use.
You can get 16GB of RAM these days for less than $100. In a couple of years you'll probably be able to get 32GB for that amount. CPU speeds, OTOH, aren't going to get a whole lot faster (more cores notwithstanding). So I think there is a good case to be made that trading memory for CPU cycles is a good strategy in 2013 (along with parallelizing whenever possible).
The notions of employment, investment and even concepts of ownership could be highly effected. After all, why bother to own a bicycle when a printer can whip one out for you as needed?
For the foreseeable future, anyway, the answer would be: because the bicycles available in the shops are both cheaper and higher quality than anything you could print out yourself.
3D printers are currently able to make plastic toys; maybe someday they'll be able to do more and cost less to operate, but that's only speculation at this point.
However, sending a human there might well be enough of an "Apollo 8" moment to reignite peoples interest in going to Mars - possibly even enough to fire up another space race.
Contrariwise, it might well end up as more of a "Challenger disaster" moment, with all hands lost and a corresponding loss of public confidence in the feasibility of manned space exploration. But I guess that's the risk you gotta take...
Isn't it obvious? Humans have such well demonstrated qualifications for 'floating around in irradiated hard vacuum doing not much of any particular interest'. Robots aren't nearly as good at that...
Sarcasm aside, I think that's the point -- to demonstrate that humans can survive the trip. (Of course, it might just as easily show that it can't be done, or at least that it shouldn't be done, depending on how the astronauts fare health-wise)
At least you get an 'Earthrise' on Mars, you can't do that s*** on the Moon.
Sure you can. Start on the "dark side" of the moon and start walking in a straight line. Eventually you will see the Earth rise. (As an added bonus, you can make the Earth sink back down again simply by retracing your steps -- what power!)
Slashdot Mirror
BTC was a horribly designed currency from the getgo
Actually, much of it is really well designed -- as evidenced by the complete absence of Bitcoin counterfeiters, despite the fact that there is a huge financial incentive to counterfeit Bitcoins.
As far as the economic theory goes, you may be right... but if so, then BitCoin will fail and some other system will come along to replace it, hopefully taking its mistakes into account in the new design.
BitCoin is an impressive piece of distributed cryptogaphy and a big leap forward compared to, say, PayPal or (shudder) Flooz. It's not perfect, but then nothing is -- and so far it's held up a lot better than I would have predicted.
Using "literally" to describe valuable data makes no fucking sense. It either is or isn't.
Usually "valuable data" is valuable because it provides its owner with a competitive advantage.
This "valuable data" is "literally valuable" because it is being used as a form of cash.
Hope that helps.
Apple's slice is clearly a core feature, as it allows them to stem losses caused by seedy individuals who would otherwise peel away their profit.
Well, if nothing else, the moon would make a good location for a moon base. ;) If there was a practical way to mine rocket fuel on the moon, I think that could be a good refuelling/re-launching point for rockets bound for other parts of the solar system.
Also, I understand that the far side of the moon would be a good location for telescopes that want to minimize EM pollution from Earth.
Macintosh computers may be flawless when running the latest software on the latest version of OS X, but things quickly go awry when you want to run a newer application on an older version of OS X (where a .1 difference matters) or an older application
This is actually a good point. Apple and Microsoft have very different approaches to dealing with old software.
Microsoft's approach is "keep compatibility all the way back to MS-DOS 1.0, no matter what the cost!". Which is good, in that if you want to you can pretty much run any Windows or DOS software from the last three decades and expect it to work. But it's also bad, because maintaining all that backwards compatibility makes the OS so much more complicated to use (and, I'd imagine, to test) that the user experience suffers.
Apple, on the other hand, favors the "keep compatibility for two years or so, and after that take out the bits we decide we don't like and shoot them in the head. Users will just have to upgrade and like it." Which is good because the OS stays relatively simple, without too much cruft building up, so the user experience with is consistent... but if you want to run old software you're often simply out of luck (e.g. anything PowerPC or earlier).
That's against the Law of Land Warfare, landmines have to be either marked or under direct observation.
Great, but people who go around planting land mines don't necessarily spend a lot of time worrying about how well they are complying with the Law of Land Warfare.
This defeats one of the "selling points" of using a dll. When functionality improves, the library is updated and all consumers of that library benefit from it.
Yes, you're quite right, but that's a tradeoff that might be worth making. Upgrading a shared library that an application already is using is a risk, since after the upgrade you are running an application in a configuration that its developer never tested against. Better perhaps to have the developer upgrade his application to the new version of the shared library, let him test it thoroughly, and then when he has released his new app version, download it (at which point it would auto-download the new shared library version that it is linked against).
Locking in a specific version via hash would be functionally no different than just statically compiling the library into the binary.
True.
Then what is the point at all?
1) Avoid any chance of "DLL Hell"
2) Save disk space
3) Reduce download size
4) Allow the use of LGPL libraries in non-(L)GPL software
But mostly (1). Keep in mind this idea is an alternative to the previous poster's suggestion of packaging a copy of every shared library along with the application that uses it -- which would also be functionally equivalent to static linking, but without the benefits 2 and 3.
I understand the benefits of shared libraries, but storage space is dirt-cheap today and I think a lot of problems might be solved simply by letting lots of pieces of software bundle their favorite versions of dependent libraries.
Or, how about this: Instead of linking to shared libraries by their filenames, applications specify the shared libraries they'd like to link to via md5 hashes of the libraries' contents. The linker checks its shared-library database-index (which could just be a directory whose directory-entries are md5 hash codes) to see if it has a shared library with that md5 hash installed; if yes, it links the application process to it; if no, it auto-downloads the shared library with that hash from the web repository, installs it, and then links the application process to it.
The advantages would be:
No library collisions, ever (well, to the extent that md5 hashes are unique, anyway).
No version mismatches, ever (each app will always run using the libraries it was built against, and no others).
No mucking about with LD_LIBRARY_PATH (as all shared libraries are auto-stored for you
No manually installed missing libraries (they will instead be installed as necesary, on demand)
No space wasted by multiple copies of the same library present on your disk at once
Some possible disadvantages:
No way to "patch" behavior of multiple applications by upgrading only a shared library they link to (you'd have to upgrade each of the applications instead, so that they reference the new library version's md5 hash)
Possible security issues from auto-installing shared libraries with malicious code (although arguably you either trust a developer enough to install his program, or you don't; the mechanics of how different parts of the program are installed aren't necessarily relevant)
Gretchen: That is so fetch!
Regina: Gretchen, stop trying to make "fetch" happen! It's not going to happen!
And yet between them have killed less people than most other major process catastrophies throughout history.
In the most literal sense, that's probably true. But immediate death isn't the only problem that comes from a radiation disaster. Uprooting entire communities on a few hours' notice is not pleasant for anyone, and results in all kinds of indirect social costs.
And of course there is the monetary cost. Belarus estimates its costs from the Chernobyl disaster at $235 billion, and to this day Chernobyl is still eating up 5-7% of the budget of the Ukraine.
Taking a look at the worlds largest solar power plant and scaling it from 300kWh to the 7.5GWh that Fukushima Daiichi generated, and it would use 72000 acres of land, permanently.
Land that nobody was living on. That's a key difference -- when a solar plant goes up, it does so in a controlled and planned manner. People aren't turned out of their houses in the middle of the night and told they can never go home again. Neighborhoods aren't torn apart. Lives aren't ruined.
Three Mile Island didn't "blow". I (and thousands of others) wouldn't be living within 20 miles of the place right now if it had.
... which is actually a pretty good indication of what's holding nuclear back. If things go sufficiently wrong, large swaths of valuable real estate and infrastructure become unlivable, and hundreds of thousands of people have to be permanently relocated.
This translates directly into the huge liability, ultra-conservative design, high expenses, and public paranoia we see regarding nuclear today. I don't see any clear way around it except avoiding the use of radioactive materials.
Both machine guns and landmines are pretty easy to avoid: Go where they are not.
Landmines have an annoying habit of being buried where you can't see them. This makes it difficult to ensure that you are going where they are not.
.... I'm confident that we have little to worry about. Asteroids will tend to avoid our planet out of sheer embarrassment.
This is probably overly-obvious advice, but: stream music that you like while you work. That will give the non-verbal/non-analytical parts of your brain something to chew on while the analytical parts are working on your code; if they like it, they'll stop sending so many "I'm bored" interrupts up to your conscious mind.
Either that, or find a way to make your work more interesting. Bored with JavaScript? Recode your app in Brainf*ck ;)
But it leads me to suspect that in the race for bragging rights about having the "fastest JavaScript", developers have prioritized execution speed over memory efficiency. Personally I'd be happy with a slower JavaScript that paid attention to memory use.
You can get 16GB of RAM these days for less than $100. In a couple of years you'll probably be able to get 32GB for that amount. CPU speeds, OTOH, aren't going to get a whole lot faster (more cores notwithstanding). So I think there is a good case to be made that trading memory for CPU cycles is a good strategy in 2013 (along with parallelizing whenever possible).
The notions of employment, investment and even concepts of ownership could be highly effected. After all, why bother to own a bicycle when a printer can whip one out for you as needed?
For the foreseeable future, anyway, the answer would be: because the bicycles available in the shops are both cheaper and higher quality than anything you could print out yourself.
3D printers are currently able to make plastic toys; maybe someday they'll be able to do more and cost less to operate, but that's only speculation at this point.
>What I really want is a potable computer, so I can drink it if I get thirsty.
What I really want is a pottable computer, so it can monitor my geraniums.
They specifically allow OS X Server to be virtualized.
... on Mac hardware only. Which brings us back to the matter at hand, needing Mac hardware in order to run Mac software.
Oh c'mon Pinky, you already know, you DMA'd it from me 250nS ago.
However, sending a human there might well be enough of an "Apollo 8" moment to reignite peoples interest in going to Mars - possibly even enough to fire up another space race.
Contrariwise, it might well end up as more of a "Challenger disaster" moment, with all hands lost and a corresponding loss of public confidence in the feasibility of manned space exploration. But I guess that's the risk you gotta take...
Isn't it obvious? Humans have such well demonstrated qualifications for 'floating around in irradiated hard vacuum doing not much of any particular interest'. Robots aren't nearly as good at that...
Sarcasm aside, I think that's the point -- to demonstrate that humans can survive the trip. (Of course, it might just as easily show that it can't be done, or at least that it shouldn't be done, depending on how the astronauts fare health-wise)
At least you get an 'Earthrise' on Mars, you can't do that s*** on the Moon.
Sure you can. Start on the "dark side" of the moon and start walking in a straight line. Eventually you will see the Earth rise. (As an added bonus, you can make the Earth sink back down again simply by retracing your steps -- what power!)
But we'd rather spend trillions enriching the very few via wars/police state crap to prevent fewer deaths than dog bites cause (*)
If only 15 Americans died from terrorism last year, doesn't that mean the prevention is working? ;^)
Go ahead, try to sneak-and-peek interrogate someone.
Hmm. Might be possible using rohypnol?
Never mind that; what if they hadn't wasted so much money on "stimulus" this cleanup would be paid for many times over.
Either that, or the recession would have been much longer and more severe, and we'd be much deeper in the hole now than we are.