You would spend any coins that you bought at a higher price first (report a loss for a tax deduction).
Not necessarily. If they are aged enough to be long term one may want to hold on to them. Spending long term assets may be something that you want to occur as an exceptional case, a manual selection, not a default automatic policy. Timing the loss is sometimes a strategic decision.
Plus if they are approaching an age where they will convert from short to long term assets one may want to hold on to them.
Then you'd spend coins that are already old enough to be taxed as an investment (lower rate),...
Again, possibly best to be a manual selection not an automatic default. For example it would be regrettable to see a long term gain offset a short term loss. Better to use a short term gain to offset a short term loss.
... and then you'd spend recently bought coins (newest to oldest) that are taxed as speculation (higher rate). Nobody in their right mind would spend the new coins first, unless something that can offset the gains is about to expire.
There are no one-size-fits-all rules as to when to spend a particular asset. There are always external and strategic circumstances to consider.
FIFO or LIFO is to simple when dealing with taxable transactions. The sell priority goes Losses > Long-term gains > Short-term gains.
Its not really that simple either. For example LIFO (last in first out) has the advantage that it helps accumulate long term gains. So applying LIFO within the current short term gains helps a particular coin age and move from the short term to long term. Also one might want to be selective about when long term gains are spent. Again, LIFO is useful in this respect in that it prefers to spend short term.
In short LIFO may be a good default policy, maximizing and preserving the long term gains. A policy that can be overridden on that special day when one wants to cash in the long term gains.
That's because the act of spending a BitCoin is really the act of selling it for "real" money and then spending the real money. Everything I've seen seems to be treating them very much the same way stocks are treated for taxing purposes.
In common scenarios the merchant uses a bitcoin exchange as an intermediary, as a payment processor. The customer never sees or touches a fiat currency (dollars, euros, etc), they only see bitcoins. The merchant never sees or touches a bitcoin, they only see fiat currency. Its only the exchange, a third party, that sells the bitcoins for fiat. The exchange accepts bitcoins from the customer and sends fiat to the merchant.
You buy 0.1 BTC at $500/BTC. Later you buy 0.2 BTC at $550/BTC. Later you buy 0.2 BTC at $560/BTC. Your client will say you have 0.5 BTC, but internally there actually are 3 separate accounts that it'll handle transparently. If you pay 0.3 BTC to somebody, it'll have to issue payments from at least two of them.
So, you wait a month, now it's $570/BTC, and sell 0.05 BTC.
My understanding is that it's perfectly possible that your client will decide to source bitcoins from all 3 accounts in some random quantities that add to 0.05. So how much have you gained? Hard to tell, since the standard client won't directly tell you what accounts it used, and doesn't know how much you bought each part of your balance for, it doesn't do banking at all.
Software could automatically apply a LIFO or FIFO scheme to the coins and calculate their basis when coins are spent or sold. See http://yro.slashdot.org/commen....
Tax-wise it seems tricky. It seems (you're nuts if you take advice from a random stranger on this) that it's considered an asset, and if bitcoin gains in value you have to pay tax on that
Like most assets, don't you (in the US) just pay tax on it when you sell it and realize a profit? Just like stock? That doesn't seem tricky at all.
If I understand things correctly, the tricky part is that you realize a taxable gain when you spend your bitcoins. Not merely when you sell them. Buy a coffee, remember to calculate and report your gain.
A recent 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 you held them an 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 FIFO (first in first out) your basis for the outgoing 1.5 coins is $500 + $300 = $800, and the basis for the returning 0.5 coins is still $300. You experienced a gain of $400 on the 1.5 coins at the time of the sale and that $400 would seem to be taxable income.
Using LIFO (last in first out) your basis for the 1.5 outgoing is $600 + $250 = $850. You experienced a gain of $350.
Apologies if I botched the math, hopefully the point gets across.
A possible advantage of LIFO is that you are spending "newer" coins first. Letting your "older" coins continue to age. If you hold these "older" coins for a year or more then they may have an advantage of being taxed at a lower rate when spent or sold.
And of course you can use any scheme to determine which coins are being used in a transaction, you are not limited to LIFO/FIFO. They are just convenient examples.
though I doubt it'll ever support my platform of choice
Really? What platform would you be referring too, I'm genuinely curious.
My understanding is that LLVM is skipping various "legacy" platforms. 16-bit x86 came to mind but when I googled it I found that Intel is actually working on 16-bit x86 support. Some boot loaders and emulators apparently use 16-bit code.
I was going to make a snarky Z80 comment but when reading the 16-bit Intel thread I found another potential snarker discovered that a Z80 backend for LLVM exists.
Where the LLVM devs may have no interest it seems the legacy communities or other parties may step in.
While there is no technical reason not to use LLVM I expect it won't be very popular with the GNU Hurd users.
Now what could we possibly have done in such a short time, should it have been heading directly towards us?
Evacuate 20 miles from the expected point of impact. Its not a dinosaur-killer, its much smaller than the meteor crater object. https://solarsystem.nasa.gov/s...
The meteor crater impact (160 foot object) is believed to have killed everything within about 2 miles, killed half of everything out to about 8 miles,... https://solarsystem.nasa.gov/s...
I believe that in general water impacts are considered more dangerous. Unlike air, water will transmit the energy over greater distances and the tsunami can do more damage than an impact itself.
Thermite grenades, small amounts of ordinary plastic explosives, even pistols for electronics... sometimes the old ways are best.
Forget the James Bond movie gizmos, that only works in Hollywood.
My Dad spent some time in armored cavalry as both a blacksmith/welder and as a driver. I'm going to have to ask him how much damage he could do with a mechanic's ball been hammer and a couple of minutes.
In the case of ISIS, the US had plenty of time to bomb this hardware before it became an issue.
It might be better to bomb it after capture. These vehicles are status symbols. Let the leadership, politicians and such climb in and start to use it. Then bomb it. Then bomb the most raggedy assed looking Toyota pickup trucks nearby, ones without even a heavy weapon mounted in the truck bed. That's where the experienced cadre are riding, trying to maintain a low profile.
Lets not forget the gov't research labs -- it would be nice if the U.S. gov't didn't shut down such research to appease an ill-informed political interest group.
Otherwise known as "the electorate".
No. Otherwise known as one particular political party's minority that has disproportionate power during primary season. Something very far from the electorate at large. Not to suggest the electorate is well informed on matters of science and engineering, but those few with deeply held political beliefs take scientific denial and misinformation to a new level.
Both political parties have their respective science deniers who will "primary" candidates who don't tow their line. Deniers have their respective articles of faith and all science and engineering to the contrary be damned. The two sets of deniers, each on their respective political extremes, are in fact so similar in their methods and circular belief systems its amazing. They truly are opposite sides of the same coin.
The problem with being self taught, having only experience, is that the experience tends to be only in what was necessary or what was interesting. Very few aspiring developers have the ambition and discipline to study and learn all the topics that one will be "forced" into studying in a formal degree program. For most aspiring developers the formal degree program will give them a broader set of knowledge and tools to build upon. The purely self taught that have such a broad set of knowledge are exceptionally rare. Most of us need someone to push us to do a little more than we think is necessary.
That said, being very good at software development is not simply a matter of having the correct broad set of knowledge to build upon. A person absolutely needs some inherent curiosity and interest in the field. To be truthful, many in college have no such curiosity/interest. They are just in college to get their "ticket punched", to meet some requirement on a HR checklist. This includes some in computer science and related programs.
The problem is that theory persists over time far far better than practical applications. And the truth of the matter is that the practical applications that most student complain about are really implementation details. Operating systems, programming languages, hardware architectures,... these things change.
My undergrad CS program was Unix based. Many students complained about wanting practical experience coding under MS Windows. That is where the jobs were. The way the dean explained it at a faculty/student meeting was that the university's job was to teach the more persistent theoretical and conceptual knowledge. The theory and concepts of a compiler, operating system, of algorithms and data structures, the theory, concepts and mathematics of computer graphics, etc. Things that are largely relevant regardless of whether you are coding under Unix or MS Windows, OpenGL or Direct3D. That things like a particular editor or IDE, C++ rather than C, Windows API rather than Unix,... these are implementation details for you to learn on your own time. Labs with Windows based PCs are available, you are free to use them for personal development and independent study. If and when appropriate, and only with the consent of the instructor, you might ask to do a particular class project on these PCs. However do not expect the instructor or TA to teach you the Windows environment and coding for it. That's your responsibility to figure out if you want to go down that alternate path.
The preceding seemed reasonable and fair to me but some still complained. They literally wanted an elective class to teach Win32 programming. To get university credit for working their way through the earlier chapters of the Petzold book I suppose.
I think I agree with the dean and professors. The University classes are to teach you the persistent stuff like theories and concepts. The more practical stuff is for you to figure out on your own time, although the University will make resources (ex Windows PC) available to you.
Will these new elements have significantly shorter half-lives?
In general the waste from a 4th gen reactor design is cited as being hazardous for a few hundred years. Something manageable, unlike the current situation where we are looking at tens of thousands of years.
Fukushima's error was that they didn't raise the sea wall like many recommendations had told them too. They whole design is different, it's not really comparable.
Not just the design but many other relevant circumstances too. I drove past San Onofre yesterday, currently inoperative. Noticed the really big hills immediately behind it. Putting backup generators and such on that higher ground might be useful too. I'm not 100% sure but I think backup generators were stored at the nearby US Marine Base, Camp Pendleton, and the Marines would helicopter them in if and when needed. If so on high ground, secured and mobile. Might be a better idea than more walls. Other coastal sites can probably take advantage of advantageous local conditions as well.
Lets not forget the gov't research labs -- it would be nice if the U.S. gov't didn't shut down such research to appease an ill-informed political interest group.
Worksheets are too complex to use. The navigation isn't intuitive. First off worksheets should open in edit mode.
Yeah, we've changed our minds about edit mode too.
The sample values in grey shouldn't be zeros but rather something like a valid sample calculation or the manual should have a walk through for each worksheet and when the user hits manual it goes to that page with a sample.
The built-in manual does have samples for the traditional UI, the buttons. Another set for worksheets makes sense, and an in-worksheet button that goes to the manual page is a great suggestion.
I'm a pretty smart guy whose been using advanced calculators for a quarter century and I can't figure out how to use most of the worksheets.
Thank you so much. This sort of feedback is great. Although we do apologize for our failing that made it necessary.
BTW I'm a user of your app, replaced pcalc as my primary calculator. So thanks!.
Thank you. Suggestions and criticisms via our support email address are always welcome. That is how products get better. Hearing what we did wrong is more useful than hearing about what we got right.
Curious, one of the items in the pineight link is that you can't ask for email address as a customer identifier. So if you can't id a user by any characteristics of the phone either (like device id or phone#), how can you create an external unique key to id the user in case he reinstalls? i.e. you effectively can't build an app that references your external server to provide data to that app?
(obviously not an Apple dev here...)
When the app runs you can "receipts" for the app purchase and any in-app purchases. This allows you to configure the app as it was before the re-install. Basically the purchases, storage used on iCloud, etc is all tied to the Apple App Store account.
As for your server, I believe Apple lets users create accounts on your server. Don't recall the details
With respect to he VLC media player... Apple didn't care it was GPL, the developer was OK with the App Store, but a 3rd party threatened to sue Apple so Apple pulled the app.
"The iOS VLC app was created by Applidium, a French mobile software company. In an Ars Technica interview, Applidium co-founder Romain Goyet said "The way I see it, we're not violating anyone's freedom. We worked for free, opened all our source code, and the app is available for free for anyone to download. People are enjoying a nice free and open source video player on the AppStore, and some people are trying to ruin it in the name of 'freedom.'"... In a follow-up VideoLAN mailing list post, VideoLAN association president Jean-Baptiste Kempf wrote, "With 'friends' like you, we don't need any enemies. If I understand correctly, the FSF new policy is to blow up communities?"" http://www.zdnet.com/blog/open...
The FSF argues that Apple prohibits modifying and/or redistributing the app. That is a somewhat bogus argument. The binary is digitally signed, it won't run if modified or transferred to another device lacking the appropriate key. However the source code is available. A user is free to modify and distribute in terms of source code. They can submit their modified alternative binary to the app store. They can give a few friends binaries via ad hoc distribution. Yes, this costs money. The GPL doesn't prohibit things costing money, you can charge for distribution if you like and people are free to ignore your distribution and go to the source code. Nor does the GPL doesn't mandate a free developer environment.
Its seems the FSF has far more to do with GPL apps not being on iOS than Apple.
Or the governments are trying to find ways to tax the transactions done in Bitcoin.
The US already found a way to tax Bitcoins, as an asset. They announced this earlier this year.
I believe that miners have to record income on the day they received coins from mining operations and that sellers have to record a gain/or loss at they time they sell/trade coins. This means that when you buy that cup of coffee you have to note the price difference between when you acquired the coins and when you bought the coffee, and report that gain/loss.
Does this mean that cryptocurrencies are getting succesful?
No. Wall Street will speculate on anything that can possibly be sold at a profit. Intrinsic value and low risk are not required, read up on the origins of the recent banking crisis.
All this means is that there is a short term potential for profit by trading in crypto. Any actual value or utility in crypto would be irrelevant to Wall Street.
Slashdot Mirror
You would spend any coins that you bought at a higher price first (report a loss for a tax deduction).
Not necessarily. If they are aged enough to be long term one may want to hold on to them. Spending long term assets may be something that you want to occur as an exceptional case, a manual selection, not a default automatic policy. Timing the loss is sometimes a strategic decision.
Plus if they are approaching an age where they will convert from short to long term assets one may want to hold on to them.
Then you'd spend coins that are already old enough to be taxed as an investment (lower rate), ...
Again, possibly best to be a manual selection not an automatic default. For example it would be regrettable to see a long term gain offset a short term loss. Better to use a short term gain to offset a short term loss.
... and then you'd spend recently bought coins (newest to oldest) that are taxed as speculation (higher rate). Nobody in their right mind would spend the new coins first, unless something that can offset the gains is about to expire.
There are no one-size-fits-all rules as to when to spend a particular asset. There are always external and strategic circumstances to consider.
FIFO or LIFO is to simple when dealing with taxable transactions. The sell priority goes Losses > Long-term gains > Short-term gains.
Its not really that simple either. For example LIFO (last in first out) has the advantage that it helps accumulate long term gains. So applying LIFO within the current short term gains helps a particular coin age and move from the short term to long term. Also one might want to be selective about when long term gains are spent. Again, LIFO is useful in this respect in that it prefers to spend short term.
In short LIFO may be a good default policy, maximizing and preserving the long term gains. A policy that can be overridden on that special day when one wants to cash in the long term gains.
That's because the act of spending a BitCoin is really the act of selling it for "real" money and then spending the real money. Everything I've seen seems to be treating them very much the same way stocks are treated for taxing purposes.
In common scenarios the merchant uses a bitcoin exchange as an intermediary, as a payment processor. The customer never sees or touches a fiat currency (dollars, euros, etc), they only see bitcoins. The merchant never sees or touches a bitcoin, they only see fiat currency. Its only the exchange, a third party, that sells the bitcoins for fiat. The exchange accepts bitcoins from the customer and sends fiat to the merchant.
Yes, but:
You buy 0.1 BTC at $500/BTC. Later you buy 0.2 BTC at $550/BTC. Later you buy 0.2 BTC at $560/BTC. Your client will say you have 0.5 BTC, but internally there actually are 3 separate accounts that it'll handle transparently. If you pay 0.3 BTC to somebody, it'll have to issue payments from at least two of them.
So, you wait a month, now it's $570/BTC, and sell 0.05 BTC.
My understanding is that it's perfectly possible that your client will decide to source bitcoins from all 3 accounts in some random quantities that add to 0.05. So how much have you gained? Hard to tell, since the standard client won't directly tell you what accounts it used, and doesn't know how much you bought each part of your balance for, it doesn't do banking at all.
Software could automatically apply a LIFO or FIFO scheme to the coins and calculate their basis when coins are spent or sold. See http://yro.slashdot.org/commen....
Like most assets, don't you (in the US) just pay tax on it when you sell it and realize a profit? Just like stock? That doesn't seem tricky at all.
If I understand things correctly, the tricky part is that you realize a taxable gain when you spend your bitcoins. Not merely when you sell them. Buy a coffee, remember to calculate and report your gain.
A recent 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 you held them an 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 FIFO (first in first out) your basis for the outgoing 1.5 coins is $500 + $300 = $800, and the basis for the returning 0.5 coins is still $300. You experienced a gain of $400 on the 1.5 coins at the time of the sale and that $400 would seem to be taxable income.
Using LIFO (last in first out) your basis for the 1.5 outgoing is $600 + $250 = $850. You experienced a gain of $350.
Apologies if I botched the math, hopefully the point gets across.
A possible advantage of LIFO is that you are spending "newer" coins first. Letting your "older" coins continue to age. If you hold these "older" coins for a year or more then they may have an advantage of being taxed at a lower rate when spent or sold.
And of course you can use any scheme to determine which coins are being used in a transaction, you are not limited to LIFO/FIFO. They are just convenient examples.
though I doubt it'll ever support my platform of choice
Really? What platform would you be referring too, I'm genuinely curious.
My understanding is that LLVM is skipping various "legacy" platforms. 16-bit x86 came to mind but when I googled it I found that Intel is actually working on 16-bit x86 support. Some boot loaders and emulators apparently use 16-bit code.
I was going to make a snarky Z80 comment but when reading the 16-bit Intel thread I found another potential snarker discovered that a Z80 backend for LLVM exists.
Where the LLVM devs may have no interest it seems the legacy communities or other parties may step in.
While there is no technical reason not to use LLVM I expect it won't be very popular with the GNU Hurd users.
DNA is good for exonerating people, not convicts them.
With respect to a single match.
Now if his DNA shows up on multiple ripper victims then DNA can be good for determining culpability.
Now what could we possibly have done in such a short time, should it have been heading directly towards us?
Evacuate 20 miles from the expected point of impact. Its not a dinosaur-killer, its much smaller than the meteor crater object. https://solarsystem.nasa.gov/s...
That is a lot of energy. Has anyone studied using the energy for space travel?
Unless you are converting ice to fuel what energy is that? Kinetic energy, a glancing impact sending you off on some vector (pool table physics)?
The meteor crater impact (160 foot object) is believed to have killed everything within about 2 miles, killed half of everything out to about 8 miles, ...
https://solarsystem.nasa.gov/s...
I believe that in general water impacts are considered more dangerous. Unlike air, water will transmit the energy over greater distances and the tsunami can do more damage than an impact itself.
Thermite grenades, small amounts of ordinary plastic explosives, even pistols for electronics ... sometimes the old ways are best.
Forget the James Bond movie gizmos, that only works in Hollywood.
My Dad spent some time in armored cavalry as both a blacksmith/welder and as a driver. I'm going to have to ask him how much damage he could do with a mechanic's ball been hammer and a couple of minutes.
In the case of ISIS, the US had plenty of time to bomb this hardware before it became an issue.
It might be better to bomb it after capture. These vehicles are status symbols. Let the leadership, politicians and such climb in and start to use it. Then bomb it. Then bomb the most raggedy assed looking Toyota pickup trucks nearby, ones without even a heavy weapon mounted in the truck bed. That's where the experienced cadre are riding, trying to maintain a low profile.
Lets not forget the gov't research labs -- it would be nice if the U.S. gov't didn't shut down such research to appease an ill-informed political interest group.
Otherwise known as "the electorate".
No. Otherwise known as one particular political party's minority that has disproportionate power during primary season. Something very far from the electorate at large. Not to suggest the electorate is well informed on matters of science and engineering, but those few with deeply held political beliefs take scientific denial and misinformation to a new level.
Both political parties have their respective science deniers who will "primary" candidates who don't tow their line. Deniers have their respective articles of faith and all science and engineering to the contrary be damned. The two sets of deniers, each on their respective political extremes, are in fact so similar in their methods and circular belief systems its amazing. They truly are opposite sides of the same coin.
The problem with being self taught, having only experience, is that the experience tends to be only in what was necessary or what was interesting. Very few aspiring developers have the ambition and discipline to study and learn all the topics that one will be "forced" into studying in a formal degree program. For most aspiring developers the formal degree program will give them a broader set of knowledge and tools to build upon. The purely self taught that have such a broad set of knowledge are exceptionally rare. Most of us need someone to push us to do a little more than we think is necessary.
That said, being very good at software development is not simply a matter of having the correct broad set of knowledge to build upon. A person absolutely needs some inherent curiosity and interest in the field. To be truthful, many in college have no such curiosity/interest. They are just in college to get their "ticket punched", to meet some requirement on a HR checklist. This includes some in computer science and related programs.
The problem is that theory persists over time far far better than practical applications. And the truth of the matter is that the practical applications that most student complain about are really implementation details. Operating systems, programming languages, hardware architectures, ... these things change.
... these are implementation details for you to learn on your own time. Labs with Windows based PCs are available, you are free to use them for personal development and independent study. If and when appropriate, and only with the consent of the instructor, you might ask to do a particular class project on these PCs. However do not expect the instructor or TA to teach you the Windows environment and coding for it. That's your responsibility to figure out if you want to go down that alternate path.
My undergrad CS program was Unix based. Many students complained about wanting practical experience coding under MS Windows. That is where the jobs were. The way the dean explained it at a faculty/student meeting was that the university's job was to teach the more persistent theoretical and conceptual knowledge. The theory and concepts of a compiler, operating system, of algorithms and data structures, the theory, concepts and mathematics of computer graphics, etc. Things that are largely relevant regardless of whether you are coding under Unix or MS Windows, OpenGL or Direct3D. That things like a particular editor or IDE, C++ rather than C, Windows API rather than Unix,
The preceding seemed reasonable and fair to me but some still complained. They literally wanted an elective class to teach Win32 programming. To get university credit for working their way through the earlier chapters of the Petzold book I suppose.
I think I agree with the dean and professors. The University classes are to teach you the persistent stuff like theories and concepts. The more practical stuff is for you to figure out on your own time, although the University will make resources (ex Windows PC) available to you.
Will these new elements have significantly shorter half-lives?
In general the waste from a 4th gen reactor design is cited as being hazardous for a few hundred years. Something manageable, unlike the current situation where we are looking at tens of thousands of years.
Fukushima's error was that they didn't raise the sea wall like many recommendations had told them too. They whole design is different, it's not really comparable.
Not just the design but many other relevant circumstances too. I drove past San Onofre yesterday, currently inoperative. Noticed the really big hills immediately behind it. Putting backup generators and such on that higher ground might be useful too. I'm not 100% sure but I think backup generators were stored at the nearby US Marine Base, Camp Pendleton, and the Marines would helicopter them in if and when needed. If so on high ground, secured and mobile. Might be a better idea than more walls. Other coastal sites can probably take advantage of advantageous local conditions as well.
Can we get more companies doing these please?
Lets not forget the gov't research labs -- it would be nice if the U.S. gov't didn't shut down such research to appease an ill-informed political interest group.
Oh OK well if you want criticisms:
Worksheets are too complex to use. The navigation isn't intuitive. First off worksheets should open in edit mode.
Yeah, we've changed our minds about edit mode too.
The sample values in grey shouldn't be zeros but rather something like a valid sample calculation or the manual should have a walk through for each worksheet and when the user hits manual it goes to that page with a sample.
The built-in manual does have samples for the traditional UI, the buttons. Another set for worksheets makes sense, and an in-worksheet button that goes to the manual page is a great suggestion.
I'm a pretty smart guy whose been using advanced calculators for a quarter century and I can't figure out how to use most of the worksheets.
Thank you so much. This sort of feedback is great. Although we do apologize for our failing that made it necessary.
BTW I'm a user of your app, replaced pcalc as my primary calculator. So thanks!.
Thank you. Suggestions and criticisms via our support email address are always welcome. That is how products get better. Hearing what we did wrong is more useful than hearing about what we got right.
Curious, one of the items in the pineight link is that you can't ask for email address as a customer identifier. So if you can't id a user by any characteristics of the phone either (like device id or phone#), how can you create an external unique key to id the user in case he reinstalls? i.e. you effectively can't build an app that references your external server to provide data to that app?
(obviously not an Apple dev here...)
When the app runs you can "receipts" for the app purchase and any in-app purchases. This allows you to configure the app as it was before the re-install. Basically the purchases, storage used on iCloud, etc is all tied to the Apple App Store account.
As for your server, I believe Apple lets users create accounts on your server. Don't recall the details
Also if they're free as in freedom.
With respect to he VLC media player ... Apple didn't care it was GPL, the developer was OK with the App Store, but a 3rd party threatened to sue Apple so Apple pulled the app.
... In a follow-up VideoLAN mailing list post, VideoLAN association president Jean-Baptiste Kempf wrote, "With 'friends' like you, we don't need any enemies. If I understand correctly, the FSF new policy is to blow up communities?""
"The iOS VLC app was created by Applidium, a French mobile software company. In an Ars Technica interview, Applidium co-founder Romain Goyet said "The way I see it, we're not violating anyone's freedom. We worked for free, opened all our source code, and the app is available for free for anyone to download. People are enjoying a nice free and open source video player on the AppStore, and some people are trying to ruin it in the name of 'freedom.'"
http://www.zdnet.com/blog/open...
The FSF argues that Apple prohibits modifying and/or redistributing the app. That is a somewhat bogus argument. The binary is digitally signed, it won't run if modified or transferred to another device lacking the appropriate key. However the source code is available. A user is free to modify and distribute in terms of source code. They can submit their modified alternative binary to the app store. They can give a few friends binaries via ad hoc distribution. Yes, this costs money. The GPL doesn't prohibit things costing money, you can charge for distribution if you like and people are free to ignore your distribution and go to the source code. Nor does the GPL doesn't mandate a free developer environment.
Its seems the FSF has far more to do with GPL apps not being on iOS than Apple.
RISC came out when Intel was only doing tiny microchips, the RISC market was not competing with it.
The reference CISC platform, the "competition", at the time was the VAX. Same arguments, different target.
Or the governments are trying to find ways to tax the transactions done in Bitcoin.
The US already found a way to tax Bitcoins, as an asset. They announced this earlier this year.
I believe that miners have to record income on the day they received coins from mining operations and that sellers have to record a gain/or loss at they time they sell/trade coins. This means that when you buy that cup of coffee you have to note the price difference between when you acquired the coins and when you bought the coffee, and report that gain/loss.
Does this mean that cryptocurrencies are getting succesful?
No. Wall Street will speculate on anything that can possibly be sold at a profit. Intrinsic value and low risk are not required, read up on the origins of the recent banking crisis.
All this means is that there is a short term potential for profit by trading in crypto. Any actual value or utility in crypto would be irrelevant to Wall Street.