The strength of a currency has nothing to do with the issuing body's military and diplomatic power. What jellomizer was saying was that while the printing of the US dollar is controlled by a government institution that could print arbitrary amounts of money, bitcoins cannot be arbitrarily created.
But a bitcoin's value is also arbitrary, it is based on the faith of those who hold it. Arbitrary creation is just a talking point. A more stable supply did not constrain the skyrocketing from $60 to $1,000 nor did it prevent the crash from $1,000 to $200. Faith drove both.
Development teams and advocates can make up rationales for their theory of value, i.e. the value is equivalent to the mining expense, but such statement are just salesmanship, marketing, they have no force. Virtually currency value is entire faith based. If there is sufficient and constant faith it could work but that doesn't change its underlying faith based nature.
Because thats an awesome idea, make it easy for some organization to artificially inflate the value of a currency by running ads on TV and the internet about how you should invest in some precious metal, creating fake demand.
No, not at all. When the currency represents an amount of gold there is no such speculation or hedging. You already have gold, that US Dollar represents a certain amount of gold sitting in the US Treasury.
Tying currency to a physical substance (gold) only makes it easier for outside organizations to manipulate that currency since they can play with the values and availability of stockpiles of said substance outside of your control.
No. When the currency is gold based then the gold is typically under the control of the government, physically possessed by the government. Private stockpiles would be dwarfed by the government treasury and would only exist at the government's pleasure. At any time a government could seize a private stockpile and leave behind an equivalent pile of dollars. For example United States Gold Reserve Act of 1934.
That said I'm not advocating a return to the gold standard. I'm just point out that some scams are specific to certain financial models, that they do not universally apply.
A medium that doesn't deflate value by randomly printing more paper.
Does it matter if the value deflates due to printing as in the dollar case, or a lack of interest or lack of faith as in the bitcoin case? Last year's $1,000 bitcoin is this years $200 bitcoin. Why would the public care about the cause rather than the result?
That said I agree that bitcoin is useful as a mechanism to transfer value, as a transaction method, but as a store of value it currently fails. Its totally subject to consumer (goods/service buyer) and investor sentiment, merchant (goods/service seller) sentiment is irrelevant since merchants accepting bitcoins generally immediate convert them to dollars, euros, etc to avoid holding risks.
"raising alarm about its future viability" To whom?
The public at large. A bitcoin recipient needs to take no risk, they can immediately convert to dollars, euros, etc. This is how many merchants touted by the bitcoin community operate. They do their accounting and pricing in dollars or euros, when offered bitcoins they calculate an amount based on the real-time exchange rate, accept the coins and immediate sell the coins for dollars or euros. Technically a 3rd party, a bitcoin exchange, actually does much of this so the merchant never actually sees or touches a bitcoin. Which keeps their accounting simple and avoids tax complications, yet another deterrent the public is just about to learn about.
Now on the public side, the sender side, the bitcoins are generally "stored" in a "wallet" for a time frame longer than minutes. "Spending money" for some number of days? The senders are more exposed to volatility since they are generally holding bitcoins.
Transaction fees are already in use. The amount can vary based on demand and supply, so no reason why those would kill bitcoin.
The attraction of bitcoin as a transaction service is linked to its low fees. If mining must be supported by fees and fees rise to appreciable levels then bitcoin loses its competitive advantage against other services.
The public at large is not part of the "movement", it isn't buying into the politics as a justification to use bitcoin. The public at large is very different from the enthusiasts, the public must have an immediate tangible benefit to use bitcoins.
At least Apple gives a pretty decent support life of most of products.
Apple has also released some critical security fixes for obsolete no-longer-supported versions of iOS, so their concept of "no longer supported" has exceptions. Not all obsolete versions, but those that represent the final version that a particular line of hardware can upgrade to.
Google doesn't support phones they support android. This is fixed in the latest version of android.
Which would have compatibility and performance problems for some 4.3 based phones.
Basically you are wrong in your premise that google supports android. In fact they only partially support android. To fully support it there needs to be more reasonable timeframes for patching older OS versions. Especially for security related patches. Even Apple will occasionally release critical security patches for iOS versions that are officially no longer supported.
Not googles fault that device makers are too damned lazy to compile and deliver updated OS images to it's customers.
No, manufacturers have no update that they could distribute. You can't blame them for not distributing something that does not exist. Nor can you expect them to update to a newer OS. There will be compatibility problems for some customers so such an update must be optional not a necessary security patch.
When google releases updated source code then and only then does it become the manufacturer's problem.
As it is manufacturers have the perfect excuse for not updating customers, there is no update from google. The fact that manufacturers have not released updates in the past does not excuse google and allow google to adopt their policy of abandonment.
How about having to change your email password in three places in order to get things working again. Email app preferences, in account info and in smtp setting, and in system preferences, internet accounts. Helped a family member with that one last night. Still, a vast improvement compared to when they were on MS Windows.
An MBA is *not* the accounting/financial person that you seem to be suggesting.
MBAs are whatever they were before business school. That might be an accounting or financial person but it also might be a scientist or engineer. When I went to business school a few years ago the finance and accounting people were a minority, there were more scientists and engineers.
An MBA is not like other graduate programs. You do not focus on a particular field and delve deeply into it. An MBA program is an overview of all the major fields/components of an organization. Accounting and finance are a small part of a program. Marketing, consumer behavior, strategy, operations, new product development, organization behavior (psychology of individuals and groups), management, economics, statistics, law, entrepreneurship, etc are all part of the overview.
The point of this overview is so that you can understand other people's perspective, their needs and concerns. This allows you to more effectively communicate with them and to be more persuasive in your discussion with them.
That's it, that's all an MBA is. An overview of the major components of a business/organization and major topics related to its operation. This overview facilitates are broader understanding and better communication. It does not turn an engineer into an accountant, a marketing person, etc. It turns an engineer into an engineer that can more effectively communicate and be more persuasive when talking to an accountant, marketing person, etc.
Having a C implementation as a reference is a good thing. Even if the assembly code was well implemented on the original architecture the hot spots needing attention might be different on the second architecture. The C code is pretty useful for profiling and testing.
Also the algorithm is always the place to start. There is little point in optimizing the C code or going to assemble language until you are sure the algorithm is right. Fewer and wider memory accesses is a pretty good direction to explore as you found out. I think last time I touched something like a bresenham I also worked on eliminating branches, maybe some sneaky code to do x = (condition) ? a : b
in branchless PowerPC code but its been quite a while and maybe that was for something else.
But yeah if your C code is fast enough why redo it in assembly? I like programming in assembly but I'm not a zealot. Although I do recommend taking something like the algorithm you mentioned all the way to assembly as a way to learn a given architecture. I also suggest revisiting the code as one learns more. Truly understanding the architecture helps one write better C code.
Not just every architecture. In general, you may need to write it for every major revision of every architecture. As CPU pipelines and instruction sets change, the hand-crafted assembler may no longer be optimal.
(Exercise: Write an optimal memcpy/memmove.)
I have some math code that I optimized in assembly for Pentium Pro (686) back in the day. The performance improvements vs C are getting smaller and smaller but they are still positive. At least through Core Duo, which was the last time I had access to that code. Whenever we upgraded compilers, or we upgraded our development systems, I would test my old assembly code against the reference C code.
Regarding a case like your memcpy example. An assembly version may still be warranted. A piece of software may need to optimize for the low end computers out there. So if the assembly is a win for the low end and neutral or a slight loss for the high end then it may still be the way to go. The low end is where the attention is needed to expand the pool of computers included in the minimum system requirement, think video games. You have to optimize for the three year old computer, its the one having performance problems, not the new computer. And if it does matter on the high end its simple enough to have earlier generations of an architecture use the assembly and later generations use the reference C code. Fear of future systems is no reason to leave current systems hobbled.
Sorry, proprietary code of a past employer. It was in the domain of low level bitmapped graphics.
Its been quite a while but one method that I recall involved branch prediction. That if the condition to be used for a branch is known sufficiently far in advance then a branch on the PowerPC has no penalty. An inner loop had numerous branches whose conditions could be determined quite early. I recall doing so and storing things in extra condition registers. The result was that the inner loop no longer had any branch penalties. Myself and the Apple engineers just couldn't get the various compilers to do anything comparable.
This was just one of several things that I did but I don't really recall the others. Well, except that the rotate and mask instructions can be amazingly useful.
sure thing, if you want to rewrite your code for every cpu architecture...
Nope. I only need to write assembly for the architectures I care about, all other architectures can have the reference C code implementation.
... (and preferably also every generation of said architecture)
Probably not. Performance tuning may only be necessary for the older architectures in order to lower required/recommended system requirements so the potential market is larger.
Also assembly is often more durable, more long lived, than you might imagine. I have some math code that I wrote in assembly targeting the Pentium Pro (686) back in the day. Every once and a while I compare it against the reference C code when I have a new architecture and/or new compiler. Its still faster. The percentage improvement is getting smaller but its still a win, that original investment made in Pentium Pro days has not become counterproductive. YMMV.
And if the day arrives where the assembly becomes counterproductive then newer generations of an architecture of interest can just use the reference C code like the architectures one never cared about.
The real problem is you need to be expert in the target processor(s)...
Not really. Being an expert in assembly language in general may be required but not necessarily an expert on the target architecture. Transitioning from one target architecture to another is not like starting over from scratch. Part of becoming a good assembly language programmer is recognizing things in algorithms that can't quite be stated in a high level language, information or suggestions that can't be given to the compiler. Specific computer architectures provide the toolboxes to address such shortcomings. So a bit of the work is common regardless of the architecture and the rest is determining how to accomplish something with the architecture specific toolbox.
Circa 2000 I was beating PowerPC compilers on my first attempt. Now I had a lot of experience with x86 and some with 68K, 8051, 8048, 6502 and Z80. At the university I had taken undegrad and grad computer architecture classes, the later focused on Alpha. Before writing the "commercial" PowerPC code referred to earlier I spent a couple of weeks reading PowerPC manuals and writing little pieces of test code.
Being new to PowerPC I was concerned that I had missed something or done something wrong despite seriously beating the compiler. I was able to go to Apple and spend a couple days with their engineers. Their PowerPC people thought the assembly code was fine and couldn't really improve upon it, their compiler people couldn't improve the original C code.
That said, assembly language is unnecessary much of the time. Contrary to popular belief C code can be written in a manner that favors one architecture over another. By understanding the given architecture and its assembly language I've been able to rewrite C code and not have to go all the way to assembly. Having two C implementation of some code, one for x86 vs one for PowerPC, or more generally one for CISC vs one for RISC.
Modern wallets allow a super-backup whre you memorize some password e.g. in form of 20 words, and all future addresses you will ever generate in that wallet are always recoverable from theses words.
As comfortable as it can get.
There can be a war that will burn your home, all your backups, your servers and half of the world, and still if you remembered the words you have your bitcoins.
I know, but I thought I'd keep the problem list short. Now go tell the average user they can only have access to their coins if they remember 20 words and their order exactly. And to not use passages from books and such because the bad guys could generate their wallet/keys. I think the history of passwords may suggest how well that will work with the general public.
If 51% attack would happen even, that does not affect your BTC account at all, you have the same amoutnt of BTC.
Except for the loss of faith and trust that would cause the price to crash. Its not the number of coins in the account that matters, it the faith and trust in the system that supports the price that matter.
As for BTC price, there are various ideas to invest or not long term, but looking at it's short last 4 years, it grown over thousand times.
Only because it was starting virtually from nothing. Look at the last year, its value is less than 1/3 of where it started. 1,000'ish to 300'ish.
And neither of this is needed for successful short term payments.
True, but that limits its role to a transaction system. Which is fine, its just not what advocates claim it is. Merchants are generally doing the safe thing. Using an exchange to accept coins on their behalf and pay them in fiat. Some never even seeing or touching a bitcoin, which makes their accounting much simpler. However even as a short term payment system there are problems in jurisdictions, like the U.S. where bitcoins are an asset not a currency. Purchasing a coffee now has all the paperwork requirements of buying/selling stock. See http://slashdot.org/comments.p... to avoid redundancy.
Transactions aren't stored in the wallet. A wallet is basically a set of secret keys that allow you to transfer bitcoins. The actual transactions are stored in the blockchain on the network.
The wallet also contains a pool of addresses to be used for upcoming transactions, lets say a pool of 100. If you restore your wallet to a backup made 150 transactions ago you lost the most recent 50 transactions. If any of those represented incoming coins then these coins are lost.
Only when given certain assumptions, such as a diverse community verifying and updating the blockchain. A problem exists in that "ordinary" users are becoming increasingly priced out of engaging in "mining", which is where blockchain verification and updates occur. Increasingly mining is being dominated by commercial entities that can develop, or get early access too, the latest generation of ASIC hardware. This trend makes 51% attacks more plausible than many assume.
There are also problems in jurisdictions, like the U.S., where bitcoins are an asset.
A recent U.S. IRS advisory said virtual currency is to be treated as an assent not a currency. So lets say you receive some bitcoins. At some future date you spend these bitcoins. Since these bitcoins are an asset you have to account for their gain or loss in value for the days that you held them and declare a loss or gain on your taxes. In short spending bitcoins has the paperwork overhead of selling stocks, its not like spending dollars at all.
Ex. You buy one coin at $500 and another at $600. Coins are priced at $800 at the time of a future purchase. You buy something for $1,200, 1.5 coins. Using LIFO (last in first out) your basis for the outgoing 1.5 coins is $600 + $250 = $850, and the basis for the returning 0.5 coins is still $250. You experienced a gain of $350 on the 1.5 coins at the time of the sale and that $350 would seem to be taxable income. Apologies if I botched the math, hopefully the point gets across.
Wallet problems are not just related to compromises. Day to day file management and backup can be a problem. Don't backup your wallet often enough, restore a wallet that is too old, transactions will be lost. "Too old" has to do with frequency of use, higher usage requires more frequent backups.
The problem with bitcoin and widespread adoption is that it is essentially a system built by techies for techies. Non-technical users will occasionally have catastrophic failures, these rare events will probably dominate bitcoin's reputation among the general public and deter use.
As an atheist, I have to say that I respect this Pope for trying to drag the church, with many kicking and screaming, into the 21st century.
Actually you are off by a century (maybe more). In the 1920s a Catholic priest at a Catholic university proposed the currently accepted theory regarding the origin of the universe, the big bang. In the 1960s (or earlier ?) the Catholic church accepted the biological evolution of life including man. The church stated last century that the language of Genesis is figurative not literal. It also stated last century that scientific discovery is not in conflict with faith.
If you want to look at earlier centuries much early research was done by members of the clergy, ex genetics. And various bishops were key in establishing the modern western tradition of the scientific method in Europe.
Saw one place where the workstations were wired and their network had a whitelist of technical and business related sites. It was quickly updated upon reasonable request. There was also a wifi network for personal use, BYOD. People just used their own devices for personal stuff. I was just there for a short contract but I didn't hear any grumbling and there was no rolling of the eyes when peers explained the policy. They developed stuff for the Windows platform and I was there to do a few small iOS and Android apps. When I went by IT and asked for some iOS and Android development related sites to be added to the whitelist it was done in a few minutes.
Working on the factory floor or a sweat shop is not the same as doing a job that involves person to person interaction.
For intellectual activities like programming you don't always need that second person. At my favorite previous employer we each had our own small office but two chairs for each. When useful two would pair up to accomplish something but usually we were in our own offices concentrating on different tasks. When stuck or needing a second pair of eyes one would invite someone over.
Of my dozen or so teammates we all preferred this arrangement. We visited a company we were acquiring and they had an open floor plan with lower partitions. Our manager thought it wonderful. We noticed nearly everyone had headphones to dampen the noise. The manager of the company we were visiting told us how they provide employees with the headphones of their choice. I thought how uncomfortable wearing headphones all day must be. I checked with colleagues later, they too thought them uncomfortable after an hour or two from gaming experience.
Our manager kept offering us the chance to move into a central area with bullpens. It was currently unused in our section of the building. We declined, he couldn't understand why. He had read a book and thought it a wonderful idea. I pointed out that when he was a developer he would work very early or very late to have some quality programming time when no one else was around. At the time he thought those hours his most productive.
Next job was in a big open bullpen. I enjoyed the interaction with others, I was very fortunate to work with talented people and I understand how rare this was. Still I thought it distracting and it reduced my focus and productivity. A lot less "getting into the zone" while coding. If I had not enjoyed and respected those I worked with I imagine it would have been painful.
Long ago I had a job where we were on an open floor but we had full height cubicles. That helped with noise and distraction. Not as nice as offices but I think it was much better than low walls.
I've seen cubicles with transparent upper portions that allow visibility but with full height to reduce noise. I expect that would be an improvement on low walls.
I think the art and architecture that is admired from one generation to the next, from one culture to another, is heavily based in the math and science of human perception and preferences (Symmetries, ratios and proportions).
Can some particular piece of art become popular for some other reason -- message, politics, etc -- but do they tend to be fads rather than enduring? I think usually the former.
Slashdot Mirror
The strength of a currency has nothing to do with the issuing body's military and diplomatic power. What jellomizer was saying was that while the printing of the US dollar is controlled by a government institution that could print arbitrary amounts of money, bitcoins cannot be arbitrarily created.
But a bitcoin's value is also arbitrary, it is based on the faith of those who hold it. Arbitrary creation is just a talking point. A more stable supply did not constrain the skyrocketing from $60 to $1,000 nor did it prevent the crash from $1,000 to $200. Faith drove both.
Development teams and advocates can make up rationales for their theory of value, i.e. the value is equivalent to the mining expense, but such statement are just salesmanship, marketing, they have no force. Virtually currency value is entire faith based. If there is sufficient and constant faith it could work but that doesn't change its underlying faith based nature.
Because thats an awesome idea, make it easy for some organization to artificially inflate the value of a currency by running ads on TV and the internet about how you should invest in some precious metal, creating fake demand.
No, not at all. When the currency represents an amount of gold there is no such speculation or hedging. You already have gold, that US Dollar represents a certain amount of gold sitting in the US Treasury.
Tying currency to a physical substance (gold) only makes it easier for outside organizations to manipulate that currency since they can play with the values and availability of stockpiles of said substance outside of your control.
No. When the currency is gold based then the gold is typically under the control of the government, physically possessed by the government. Private stockpiles would be dwarfed by the government treasury and would only exist at the government's pleasure. At any time a government could seize a private stockpile and leave behind an equivalent pile of dollars. For example United States Gold Reserve Act of 1934.
That said I'm not advocating a return to the gold standard. I'm just point out that some scams are specific to certain financial models, that they do not universally apply.
A medium that doesn't deflate value by randomly printing more paper.
Does it matter if the value deflates due to printing as in the dollar case, or a lack of interest or lack of faith as in the bitcoin case? Last year's $1,000 bitcoin is this years $200 bitcoin. Why would the public care about the cause rather than the result?
That said I agree that bitcoin is useful as a mechanism to transfer value, as a transaction method, but as a store of value it currently fails. Its totally subject to consumer (goods/service buyer) and investor sentiment, merchant (goods/service seller) sentiment is irrelevant since merchants accepting bitcoins generally immediate convert them to dollars, euros, etc to avoid holding risks.
"raising alarm about its future viability" To whom?
The public at large. A bitcoin recipient needs to take no risk, they can immediately convert to dollars, euros, etc. This is how many merchants touted by the bitcoin community operate. They do their accounting and pricing in dollars or euros, when offered bitcoins they calculate an amount based on the real-time exchange rate, accept the coins and immediate sell the coins for dollars or euros. Technically a 3rd party, a bitcoin exchange, actually does much of this so the merchant never actually sees or touches a bitcoin. Which keeps their accounting simple and avoids tax complications, yet another deterrent the public is just about to learn about.
Now on the public side, the sender side, the bitcoins are generally "stored" in a "wallet" for a time frame longer than minutes. "Spending money" for some number of days? The senders are more exposed to volatility since they are generally holding bitcoins.
Transaction fees are already in use. The amount can vary based on demand and supply, so no reason why those would kill bitcoin.
The attraction of bitcoin as a transaction service is linked to its low fees. If mining must be supported by fees and fees rise to appreciable levels then bitcoin loses its competitive advantage against other services.
The public at large is not part of the "movement", it isn't buying into the politics as a justification to use bitcoin. The public at large is very different from the enthusiasts, the public must have an immediate tangible benefit to use bitcoins.
At least Apple gives a pretty decent support life of most of products.
Apple has also released some critical security fixes for obsolete no-longer-supported versions of iOS, so their concept of "no longer supported" has exceptions. Not all obsolete versions, but those that represent the final version that a particular line of hardware can upgrade to.
Google doesn't support phones they support android. This is fixed in the latest version of android.
Which would have compatibility and performance problems for some 4.3 based phones.
Basically you are wrong in your premise that google supports android. In fact they only partially support android. To fully support it there needs to be more reasonable timeframes for patching older OS versions. Especially for security related patches. Even Apple will occasionally release critical security patches for iOS versions that are officially no longer supported.
Not googles fault that device makers are too damned lazy to compile and deliver updated OS images to it's customers.
No, manufacturers have no update that they could distribute. You can't blame them for not distributing something that does not exist. Nor can you expect them to update to a newer OS. There will be compatibility problems for some customers so such an update must be optional not a necessary security patch.
When google releases updated source code then and only then does it become the manufacturer's problem.
As it is manufacturers have the perfect excuse for not updating customers, there is no update from google. The fact that manufacturers have not released updates in the past does not excuse google and allow google to adopt their policy of abandonment.
How about having to change your email password in three places in order to get things working again. Email app preferences, in account info and in smtp setting, and in system preferences, internet accounts. Helped a family member with that one last night. Still, a vast improvement compared to when they were on MS Windows.
An MBA is *not* the accounting/financial person that you seem to be suggesting.
MBAs are whatever they were before business school. That might be an accounting or financial person but it also might be a scientist or engineer. When I went to business school a few years ago the finance and accounting people were a minority, there were more scientists and engineers.
An MBA is not like other graduate programs. You do not focus on a particular field and delve deeply into it. An MBA program is an overview of all the major fields/components of an organization. Accounting and finance are a small part of a program. Marketing, consumer behavior, strategy, operations, new product development, organization behavior (psychology of individuals and groups), management, economics, statistics, law, entrepreneurship, etc are all part of the overview.
The point of this overview is so that you can understand other people's perspective, their needs and concerns. This allows you to more effectively communicate with them and to be more persuasive in your discussion with them.
That's it, that's all an MBA is. An overview of the major components of a business/organization and major topics related to its operation. This overview facilitates are broader understanding and better communication. It does not turn an engineer into an accountant, a marketing person, etc. It turns an engineer into an engineer that can more effectively communicate and be more persuasive when talking to an accountant, marketing person, etc.
Having a C implementation as a reference is a good thing. Even if the assembly code was well implemented on the original architecture the hot spots needing attention might be different on the second architecture. The C code is pretty useful for profiling and testing.
Also the algorithm is always the place to start. There is little point in optimizing the C code or going to assemble language until you are sure the algorithm is right. Fewer and wider memory accesses is a pretty good direction to explore as you found out. I think last time I touched something like a bresenham I also worked on eliminating branches, maybe some sneaky code to do
x = (condition) ? a : b
in branchless PowerPC code but its been quite a while and maybe that was for something else.
But yeah if your C code is fast enough why redo it in assembly? I like programming in assembly but I'm not a zealot. Although I do recommend taking something like the algorithm you mentioned all the way to assembly as a way to learn a given architecture. I also suggest revisiting the code as one learns more. Truly understanding the architecture helps one write better C code.
Not just every architecture. In general, you may need to write it for every major revision of every architecture. As CPU pipelines and instruction sets change, the hand-crafted assembler may no longer be optimal.
(Exercise: Write an optimal memcpy/memmove.)
I have some math code that I optimized in assembly for Pentium Pro (686) back in the day. The performance improvements vs C are getting smaller and smaller but they are still positive. At least through Core Duo, which was the last time I had access to that code. Whenever we upgraded compilers, or we upgraded our development systems, I would test my old assembly code against the reference C code.
Regarding a case like your memcpy example. An assembly version may still be warranted. A piece of software may need to optimize for the low end computers out there. So if the assembly is a win for the low end and neutral or a slight loss for the high end then it may still be the way to go. The low end is where the attention is needed to expand the pool of computers included in the minimum system requirement, think video games. You have to optimize for the three year old computer, its the one having performance problems, not the new computer. And if it does matter on the high end its simple enough to have earlier generations of an architecture use the assembly and later generations use the reference C code. Fear of future systems is no reason to leave current systems hobbled.
This is interesting. Do you have any examples?
Sorry, proprietary code of a past employer. It was in the domain of low level bitmapped graphics.
Its been quite a while but one method that I recall involved branch prediction. That if the condition to be used for a branch is known sufficiently far in advance then a branch on the PowerPC has no penalty. An inner loop had numerous branches whose conditions could be determined quite early. I recall doing so and storing things in extra condition registers. The result was that the inner loop no longer had any branch penalties. Myself and the Apple engineers just couldn't get the various compilers to do anything comparable.
This was just one of several things that I did but I don't really recall the others. Well, except that the rotate and mask instructions can be amazingly useful.
sure thing, if you want to rewrite your code for every cpu architecture ...
Nope. I only need to write assembly for the architectures I care about, all other architectures can have the reference C code implementation.
... (and preferably also every generation of said architecture)
Probably not. Performance tuning may only be necessary for the older architectures in order to lower required/recommended system requirements so the potential market is larger.
Also assembly is often more durable, more long lived, than you might imagine. I have some math code that I wrote in assembly targeting the Pentium Pro (686) back in the day. Every once and a while I compare it against the reference C code when I have a new architecture and/or new compiler. Its still faster. The percentage improvement is getting smaller but its still a win, that original investment made in Pentium Pro days has not become counterproductive. YMMV.
And if the day arrives where the assembly becomes counterproductive then newer generations of an architecture of interest can just use the reference C code like the architectures one never cared about.
The real problem is you need to be expert in the target processor(s) ...
Not really. Being an expert in assembly language in general may be required but not necessarily an expert on the target architecture. Transitioning from one target architecture to another is not like starting over from scratch. Part of becoming a good assembly language programmer is recognizing things in algorithms that can't quite be stated in a high level language, information or suggestions that can't be given to the compiler. Specific computer architectures provide the toolboxes to address such shortcomings. So a bit of the work is common regardless of the architecture and the rest is determining how to accomplish something with the architecture specific toolbox.
Circa 2000 I was beating PowerPC compilers on my first attempt. Now I had a lot of experience with x86 and some with 68K, 8051, 8048, 6502 and Z80. At the university I had taken undegrad and grad computer architecture classes, the later focused on Alpha. Before writing the "commercial" PowerPC code referred to earlier I spent a couple of weeks reading PowerPC manuals and writing little pieces of test code.
Being new to PowerPC I was concerned that I had missed something or done something wrong despite seriously beating the compiler. I was able to go to Apple and spend a couple days with their engineers. Their PowerPC people thought the assembly code was fine and couldn't really improve upon it, their compiler people couldn't improve the original C code.
That said, assembly language is unnecessary much of the time. Contrary to popular belief C code can be written in a manner that favors one architecture over another. By understanding the given architecture and its assembly language I've been able to rewrite C code and not have to go all the way to assembly. Having two C implementation of some code, one for x86 vs one for PowerPC, or more generally one for CISC vs one for RISC.
Modern wallets allow a super-backup whre you memorize some password e.g. in form of 20 words, and all future addresses you will ever generate in that wallet are always recoverable from theses words. As comfortable as it can get. There can be a war that will burn your home, all your backups, your servers and half of the world, and still if you remembered the words you have your bitcoins.
I know, but I thought I'd keep the problem list short. Now go tell the average user they can only have access to their coins if they remember 20 words and their order exactly. And to not use passages from books and such because the bad guys could generate their wallet/keys. I think the history of passwords may suggest how well that will work with the general public.
If 51% attack would happen even, that does not affect your BTC account at all, you have the same amoutnt of BTC.
Except for the loss of faith and trust that would cause the price to crash. Its not the number of coins in the account that matters, it the faith and trust in the system that supports the price that matter.
As for BTC price, there are various ideas to invest or not long term, but looking at it's short last 4 years, it grown over thousand times.
Only because it was starting virtually from nothing. Look at the last year, its value is less than 1/3 of where it started. 1,000'ish to 300'ish.
And neither of this is needed for successful short term payments.
True, but that limits its role to a transaction system. Which is fine, its just not what advocates claim it is. Merchants are generally doing the safe thing. Using an exchange to accept coins on their behalf and pay them in fiat. Some never even seeing or touching a bitcoin, which makes their accounting much simpler. However even as a short term payment system there are problems in jurisdictions, like the U.S. where bitcoins are an asset not a currency. Purchasing a coffee now has all the paperwork requirements of buying/selling stock. See http://slashdot.org/comments.p... to avoid redundancy.
Transactions aren't stored in the wallet. A wallet is basically a set of secret keys that allow you to transfer bitcoins. The actual transactions are stored in the blockchain on the network.
The wallet also contains a pool of addresses to be used for upcoming transactions, lets say a pool of 100. If you restore your wallet to a backup made 150 transactions ago you lost the most recent 50 transactions. If any of those represented incoming coins then these coins are lost.
Bitcoin itself is secure ...
Only when given certain assumptions, such as a diverse community verifying and updating the blockchain. A problem exists in that "ordinary" users are becoming increasingly priced out of engaging in "mining", which is where blockchain verification and updates occur. Increasingly mining is being dominated by commercial entities that can develop, or get early access too, the latest generation of ASIC hardware. This trend makes 51% attacks more plausible than many assume.
There are also problems in jurisdictions, like the U.S., where bitcoins are an asset.
A recent U.S. IRS advisory said virtual currency is to be treated as an assent not a currency. So lets say you receive some bitcoins. At some future date you spend these bitcoins. Since these bitcoins are an asset you have to account for their gain or loss in value for the days that you held them and declare a loss or gain on your taxes. In short spending bitcoins has the paperwork overhead of selling stocks, its not like spending dollars at all.
Ex. You buy one coin at $500 and another at $600. Coins are priced at $800 at the time of a future purchase. You buy something for $1,200, 1.5 coins. Using LIFO (last in first out) your basis for the outgoing 1.5 coins is $600 + $250 = $850, and the basis for the returning 0.5 coins is still $250. You experienced a gain of $350 on the 1.5 coins at the time of the sale and that $350 would seem to be taxable income. Apologies if I botched the math, hopefully the point gets across.
Wallet problems are not just related to compromises. Day to day file management and backup can be a problem. Don't backup your wallet often enough, restore a wallet that is too old, transactions will be lost. "Too old" has to do with frequency of use, higher usage requires more frequent backups. The problem with bitcoin and widespread adoption is that it is essentially a system built by techies for techies. Non-technical users will occasionally have catastrophic failures, these rare events will probably dominate bitcoin's reputation among the general public and deter use.
As an atheist, I have to say that I respect this Pope for trying to drag the church, with many kicking and screaming, into the 21st century.
Actually you are off by a century (maybe more). In the 1920s a Catholic priest at a Catholic university proposed the currently accepted theory regarding the origin of the universe, the big bang. In the 1960s (or earlier ?) the Catholic church accepted the biological evolution of life including man. The church stated last century that the language of Genesis is figurative not literal. It also stated last century that scientific discovery is not in conflict with faith.
If you want to look at earlier centuries much early research was done by members of the clergy, ex genetics. And various bishops were key in establishing the modern western tradition of the scientific method in Europe.
Saw one place where the workstations were wired and their network had a whitelist of technical and business related sites. It was quickly updated upon reasonable request. There was also a wifi network for personal use, BYOD. People just used their own devices for personal stuff. I was just there for a short contract but I didn't hear any grumbling and there was no rolling of the eyes when peers explained the policy. They developed stuff for the Windows platform and I was there to do a few small iOS and Android apps. When I went by IT and asked for some iOS and Android development related sites to be added to the whitelist it was done in a few minutes.
Working on the factory floor or a sweat shop is not the same as doing a job that involves person to person interaction.
For intellectual activities like programming you don't always need that second person. At my favorite previous employer we each had our own small office but two chairs for each. When useful two would pair up to accomplish something but usually we were in our own offices concentrating on different tasks. When stuck or needing a second pair of eyes one would invite someone over.
Of my dozen or so teammates we all preferred this arrangement. We visited a company we were acquiring and they had an open floor plan with lower partitions. Our manager thought it wonderful. We noticed nearly everyone had headphones to dampen the noise. The manager of the company we were visiting told us how they provide employees with the headphones of their choice. I thought how uncomfortable wearing headphones all day must be. I checked with colleagues later, they too thought them uncomfortable after an hour or two from gaming experience.
Our manager kept offering us the chance to move into a central area with bullpens. It was currently unused in our section of the building. We declined, he couldn't understand why. He had read a book and thought it a wonderful idea. I pointed out that when he was a developer he would work very early or very late to have some quality programming time when no one else was around. At the time he thought those hours his most productive.
Next job was in a big open bullpen. I enjoyed the interaction with others, I was very fortunate to work with talented people and I understand how rare this was. Still I thought it distracting and it reduced my focus and productivity. A lot less "getting into the zone" while coding. If I had not enjoyed and respected those I worked with I imagine it would have been painful.
Long ago I had a job where we were on an open floor but we had full height cubicles. That helped with noise and distraction. Not as nice as offices but I think it was much better than low walls.
I've seen cubicles with transparent upper portions that allow visibility but with full height to reduce noise. I expect that would be an improvement on low walls.
I think the art and architecture that is admired from one generation to the next, from one culture to another, is heavily based in the math and science of human perception and preferences (Symmetries, ratios and proportions).
Can some particular piece of art become popular for some other reason -- message, politics, etc -- but do they tend to be fads rather than enduring? I think usually the former.