BnB seems to be a regular troll, but in this case is factually correct. Works licensed under a permissive license such as MIT, Apache, BSD, etc are free software. They meet all the conditions of free software. The FSF goes to great pains to point this out. They encourage people to use more permissive licenses where it makes sense. For example, for a library that needs to work interoperably in a lot of situations. This was why the LGPL was created.
The in cases where there is no advantage to choosing a more permissive license from a free software perspective, the FSF would like people to choose a copyleft license like the GPL. The reason is that it guarantees that downstream users continue to enjoy the benefits of the free software.
There is no question that copyleft licenses have more restrictions for developers than more permissive licenses. To deny that is obviously false and is precisely what BnB is trolling for. If she "catches you in a lie" she can claim that free software supporters are liars, pointing to you. She chooses the term "more free" to push your buttons. If certain freedoms are a moral imperitive according to the FSF, then *more* freedoms should be better, right?
The truth is that the goal of free software is "software freedom" as defined by the 4 freedoms. This is the goal. To say that another license offers other freedoms is beside the point (at least for free software advocates). I might write a license that allows people to smack me over the head with a herring. That is arguably more permissive than even public domain, which offers no such freedom. But normal people aren't concerned with their freedom to whack me with herring and so it is irrelevant.
There are times when I really do value the ability for writers of non-free software to use my code in their products. In those cases I will choose a more permissive license. In cases where I do not value that ability, I will not offer it. Some freedoms are more important than others. I value software freedom (as defined by the 4 freedoms) -- especially for downstream users -- more than I value the freedom of downstream developers to distribute the code in any way they wish. There are times when I choose one over the other. This is only rational.
I already replied to you previously, but now I have a better idea what you're on about. MS Paint can't do the kinds of things that I use the GIMP for. If you want MS Paint, the GIMP is not what you are looking for. A quick google search gave me: http://pinta-project.com/
Neither the GIMP nor Photoshop is designed with that kind of simplicity in mind. They are designed for far more sophisticated uses. I don't think you are trolling. I think you are honestly pointing out what you see as a gap in available software. But just because you personally can figure out Photoshop doesn't mean it is intuitive. I have a friend who is a graphics designer who had a terrible time learning how to use it. Software designed for complex problems is rarely ideal for simple problems.
I'm not a photo editing specialist, but I was able to use the GIMP to do quite a lot. I didn't even use any GIMP tutorials. I used Photoshop tutorials and looked in the GIMP UI until I found things that looked similar. While there were historically a few workflow issues (especially with the text tool), I have found *nothing* in the GIMP that stops you from using it casually. Personally, I wouldn't use it for simply touching up photos (red eye reduction, color balance, etc) because there are much simpler tools for that. But, for instance, I need to create worksheets that utilize pictures from a printed textbook. The book won't lay flat in the scanner, so I usually just take a picture with my digital camera. Then I use the GIMP to stretch the images so that the pictures are square again, decolorize the pictures, mask them and create transparency where the picture is white. Also if there is a hash pattern in the picture I may need to get rid of the moire pattern. Like I said, I didn't know how to do any of this before I started and I learned using Photoshop tutorials. It was not difficult in the least, so I just can't understand where you are coming from.
My reply to "Why isn't it all in one window" has always been, "Why should every single application implement a tiling window manager?" It's a crazy idea. If you have information that needs to be separated, it should be in separate windows. Then I can resize, reposition, restack any way that I want.
I think where we're falling down is that many people want a semi-tiled window manager. By that I mean they want to group certain windows and have them tiled, but leave other windows floating. Then they want to be able to resize the group of tiled windows together, maximize them as a group, or minimize them as a group. And they want to be able to remember from session to session how those windows are grouped and tiled. But they don't want windows to be tiled all the time.
None of the popular window managers has this functionality. I know there were a few several years ago that had some of those features, but I'm not aware of anything that has all of those features. I honestly don't think it's a lot of work for some enterprising person. It's kind of strange. Even though I see the utility of a tiling window manager, I like seeing my background peeking out from behind my windows. I don't think I'm alone on that front.
What's worse is that if you base all currencies on the same finite resource, the rich countries corner the market in that resource. If you want to bolster your currency, you have to buy the resource, but nobody is selling. This raises the price of the resource, strengthening the rich country's position and weakening the poor country's position. This actually happened and it led to the abandonment of the gold standard.
I suspect the OP was mistakenly thinking about the devaluation of the US dollar against several other currencies (or perhaps against gold). At least that's how I interpreted it. Of course, that's not really inflation because you are measuring against a moving baseline, but it's a relatively easy mistake to make.
Actually, it's a little different. Current fiat currencies create money through debt. They don't create money at a constant, predictable rate. If someone wants to borrow money and the bank approves it: bam; new money is poofed into existence.
But you are completely right. This is the major problem with Bitcoin *as a standard currency*. One of the most imporant things in a funcitonal currency is that it is easy to get it into the hands of people who don't have it. This facilitates production. If people are blocked because they need to buy a boat, or buy fertilizer, or whatever, then they can't produce. If they can't produce, there is a scarcity and other people can't produce. It ripples right through society. Society works best when everyone has enough to do what they want. This maximizes production and hence true wealth.
Bitcoin limits the speed that bitcoins can be brought into existence. It also limits the total number of bitcoins in existence. This is antithetical to the issue above. Bitcoin proponents argue that because there are no fixed units for bitcoin (you can divide them up almost infinitely), this limit to the total number is a non issue. If everyone only has 1 bitcoin, they can trade in 1/1000 of a bitcoin. The other advantage of Bitcoin is that it is arguably more fair than our current banking system, which has "special" players (banks) who are allowed to poof money into existence and hence become very rich by doing precisely nothing.
IMHO, there is still a major problem, though. The first is that it doesn't matter how much you can divide bitcoins up, if you have 0, there is nothing you can do. You need to get *some*. The second problem is the way new bitcoins are distributed. It's better now with mining pools, but at first people were receiving bitcoins in 50 BTC increments. So either you had lots of bitcoins or no bitcoins. The number of people with fractional bitcoins was small. Trading was/is done in large increments even though bitcoins are scarce.
Finally, while it is downplayed, deflation is a major problem for Bitcoin as a standard currency. If you increase the value of bitcoins by dividing them up into smaller and smaller increments (so that more people can participate), you can't have loans. Nobody will be stupid enough to borrow 10 bitcoins when the value increases over time. If I can make 2 BTC the first year, 0.2 BTC the second year, and 0.02 BTC the third year (ie the value of BTC rising 10x per year), I will never make enough money to pay back the 10 BTC loan. Of course 10x deflation is exagerrated, but you get the point. Inflation is a feature of standard currencies, not a bug.
But, Bitcoin does not have to be a standard currency. It works well as an exchange mechanism on the internet. Not that many people accept it right now, but looking at the trading graphs, volume seems to be relatively strong trading against the US dollar. As long as it is liquid, it is a viable exchange mechanism.
Sorry for typing a book. Hope you found it interesting.
P.S. I don't think a company getting most of the new BTC will be a major problem because they will be selling them for USD as fast as they can. If they horded them, then it would lead to deflation. But as long as it is possible to buy and sell with USD it will still work fine as an exchange mechanism.
I got modded down in another thread saying the same thing, but I'll try again. Conventional farming is about highest yield *per dollar*. There are ways to increase yield without the use of a lot of external inputs, but they are labor intensive.
I'm not really a big fan of "organic". You're still locked into the thinking of using external input (fertilizers, pesticides, etc). You're just changing the ones you are using. To take an extreme, you could actually stand over your crops and pick weeds by hand as they emerge, or squash bugs with your fingers. I do it on my plants all the time, because I like hanging out in my garden. Fertilization of crops is a matter of getting the correct nutrients to the plants at the right time. There is more than one way to do this. The conventional way is to practically drown the plants in nutrients, to the point where we get large amounts of run off. IMHO, current organic practices are not a lot better. We're just changing where we're getting the nutrients from.
Our biggest problem is the low price of food. Wheat is currently $300 per metric ton. That's 30 cents per kg. Along the supply chain, this gets multiplied up to incredible levels. How much do you pay for flour? How much for a loaf of bread? We squeeze our farmers down to the point where a single person must grow a crop for hundreds or thousands of people. They are forced to use conventional techniques due to cost.
Fix the cost of distribution and suddenly farmers have more options. We should be pursuing as many as we can. Like you say, vertical farming is promising. There's nothing wrong with closed looped hydroponics. But as we put the vice on farmers by constantly reducing (in real dollar terms) the price they receive for their product, we reduce our options.
No. Organic farming is unsustainable *at present prices* for our population levels. You can easily get the same yield (or even higher) with "organic" farming. If you want to control pests, just have tons of guys standing around killing them by hand (well, that's really overkill).
Current "conventional" farming practices are geared towards economics, not yield. But why? 1 kilogram of barley is sold for about 23 cents a kg. That kg of barley will make about 4 liters of beer and represents at least half of the cost in terms of ingredients. Why is 23 cents of barley costing $10 as beer? Who is receiving that money? (hint: it is not the brewers nor the maltsters nor the truck drivers receiving the bulk of it). What are the implications if we pay farmers 10 times as much for barley. Will beer increase in price by about $2.30 per gallon? Why not?
Alternative forms of farming are very viable, but it's possible they will require more labor. The question is if we will stop forking money over to certain people who are making it too expensive.
I wish I could mod you up. You are exactly right, I think. There is a big difference between a "good" API and a "bad" API that has nothing to do with functionality. They could both accomplish the same thing, but there is a value in creatively designing the expression of the API. I think it is probably even a better candidate for copyright than other collections that are already recognized as having copyright. However, as a programmer, I do not want APIs to be copyright-able. It destroys interoperability and tilts the balance too far towards large companies being given a perpetual monopoly. All the have to do is write a standard and then change the API every 90+ years...
How this got modded up to 5, Insightful, I just can't understand. It demonstrates a complete lack of understanding of Bitcoin.
The crypto behind bitcoin is trivial. If you don't believe me, go ahead and read the code. There is really nothing to it. It hashes numbers. That's it.
The insight in Bitcoin is that you can get people to calculate difficult problems and put the answers in a chain. A chain of correct answers is "valid". You use a one way hash so that it is easy to determine if the chain is valid, but hard to calculate answers to create a chain. You publish the chains and the longest one (the one that was the most costly to produce) is the "real", "valid" one. To make your own chain the "real" and "valid" chain (i.e. cheat), you have to create a longer chain faster than everyone else in the system working together. This is a really insightful idea, but I wouldn't call it "crypto".
The *really* smart idea, though, is that you measure the speed at which the chain is growning. If the chain is growning quickly (there is more horsepower out there), you add restrictions to the problem (only certain hashes are valid) to make it more difficult to make the chain. The more people calculating the chain, the more hardware you need to create your own chain (i.e. cheat).
And then the *really, really* smart idea is to provide incentive for people to work together to calculate the chain. By devaluing the currency slightly and awarding a prize, they make it financially better to cooperate than to cheat.
So in summary, to the extent that you value Bitcoins (and some people do), the value comes from the cooperation in calculating the block chain (i.e. mining). The more people who do this, the more secure the system is. This literally supports the value. The insightful way that incetive was provided to make this work is obviously valuable as well. The crypto (calling a hash function over and over again until you get an answer lower than a certain target) is practically non-existent.
VCs usually look for a potential ROI of 20:1. Investing $500K means that they see a potential of extracting $10 million over a period of possibly 5 years. Blocks are generated at a rate of 52560 a year. Each block will pay 50 BTC at the moment. Assuming they could sell BTC at $5 each, they need to sell 400000 per year to get $2 million in revenue. That's 8000 blocks or a little less than one in 6 blocks. I don't think they will be able to do that simply by harvesting cycles from gamers playing free to play games. They won't get enough GPU to do it.
I haven't RTFA, but they must either have some other ideas, or they are counting on the value of bitcoins to rise. IMHO, I think it is a risky strategy. By selling 1/6th of all new bitcoins they will also put pressure on liquidity. I'm not sure there is that much demand, so I would expect the value to drop. VC is inherently risky, but my bet is that they haven't really done their homework on this one.
My biggest problem with the system is that if the system becomes popular, the incentive to cheat becomes greater (as the currency becomes more liquid, the value you can extract is higher). So you need to have enough economic incentive to keep the algorithmic complexity high enough to prevent cheating. I did some back of the envelope calculations to try to estimate what vlaue they are going to need, and it seemed to me that it will be a substantial percentage of the transaction (IIRC a few percent). I suspect that this will end up being higher than people want ot pay.
The prices on Pottormore are even quite reasonable. I would easily pay double for the Japanese version of the e-book, but alas it doesn't seem to be for sale. E-books let me look up words in the dictionary very quickly so they are much more convenient than paper for studying. I hope they figure it out. As strange as it sounds, they probably don't own the copyright for the Japanese version... sigh.
To paraphrase Karl Lagerfeld, "People who buy knockoffs of my product are not my customers". In the same way, people who do not pay for ebooks are not customers of the publishers. I can understand the frustration people have when they see someone take their product without paying for it. But if they concentrate on the people who *will* pay for it, (i.e. their actual customers) they will be better off.
I don't see anything that supports this claim. Hopefully you know better than I do. If so, please post something. The Berkeley vs. AT&T case clearly established that *those* APIs could be implemented. I have been unable to find references, but based on my memory of the time (which is likely faulty), I think there was an explicit statement before the split that the API would be open. This may actually have been before source code was considered copyrightable so they would not have really referenced copyright. In the settlement of the lawsuit, I believe that they agreed to allow implementation of the API, but I don't think they discussed copyright of the API per se. Unfortunately I can't locate a good link.
Linux is written to the POSIX standard. The POSIX standard is copyright IEEE and the Open Group. They have been clear that they won't sue people for implementing the standard (though, they also own a trademark which is a separate issue...). Additionally, the ability to implement this was pretty much covered by the BSD lawsuits in the 80s, which said that *this* API could be implemented (not that *all* APIs could be implemented).
I don't know for sure, but I don't think that the issue of blocking the implementation of APIs has been tested. POSIX is a special case. SCO was *clearly* full of shit. It is much less clear wrt to Oracle and Java from my position. The strange thing is (as others have mentioned) that Oracle seems not to be pushing the API copyright issue and are instead claiming that Google needed a TCK license. Things may change later, though.
I'm equally puzzled. They may actually have a case if they say that the API is copyrighted. Yes, it is a collection of facts, but I think there's a strong argument that it is a creative collection. The API was actually designed with an asthetic purpose. Like you say, whether or not reimplementing the API is fair use would seem to be the key issue (I hope to hell that it is, or even better that APIs can't be copyrighted).
But they are confusing the issue with this TCK stuff which seems blantantly obvious that they can't win. Probably they know something I don't. It is possible that it is simply a FUD attach (i.e., a long drawn out period of uncertainty wrt to the legality of Android causing people to develop for alternatives). In other words, they don't expect to win, but just want to confuse stuff as much as possible for as long as possible. I'd be looking for a money trail from MS in that case, though...
Ah, you see, they can't really verify that you aren't carrying anything dangerous. So, instead, they try to keep people with a long history of suicide bombings off the plane. I mean, if they've blown themselves up on 4 of their last 5 trips, there's a good chance that they will do it again.
It's not so hard to understand. You just have to start thinking like the TSA.
At least I haven't seen Google claim that Davlik etc. are derivavtive works of the GPLv2 release of Java.
Actually, this is the most insightful comment I've seen on this topic. Dalvik is indeed not (intended to be) a derivative work of the GPLv2 release of Java. It is licensed under the Apache license. You are allowed to make a derivative work under the GPL, but there is nothing allowing you to make a derivative work under a different license.
The key at this point is whether or not a re-implementation of the API is considered a derived work. If it is, then Dalvik is infringing since it is not licensed under the GPL.
I can tell you my preference with regard to whether implementation of an API is a derived work, but I have no idea what a ruling would be on it. The question put to Ellison is asking if the Java programming language is free. It is not asking whether or not the GPL implementation is free (which is obviously is). As much as I really hate to say it, I don't think he *can* know. This is what this trial is going to determine. Scary.
Meanwhile I'm learning that the teacher and the test creator are idiots, and can't be trusted to teach me anything useful or accurate. Ever.
This is useful information. Every student should take control of their own learning. It is a mistake to implicitly trust one source of information, because as hard as we all try, even the best of us are biased in some way (or just plain wrong).
The problem with the school system is not that students lose faith that the information flowing from their teachers is correct. The problem is that students are expected to unquestioningly believe it in the first place. In fact, they are punished for questioning. If your accademic success is dependent upon you parroting what the teacher has told you regardless of its truth, you have significant problems that go far beyond the teachers.
A "teacher" should not be a shoveller of facts. They should be a mediator in a student's discovery of knowledge. Whether the teacher knows the answer or not, the important part is that you should be able to discover it. If you can, the teacher has succeeded. Not understanding this point is the main problem with education today, IMHO.
I've lived in a few Canadian cities which "tried" roundabouts. The problem is that they completely screwed up (and I've seen this in both Winnipeg and Ottawa so I wouldn't be surprised if this has happened other places in NA). They gave the right of way to those entering the roundabout rather than those exiting the roundabout. This, of course, make the roundabout worse than useless. As soon as there is any significant traffic, everything grinds to a halt. To this day I don't know what possessed them to be so stupid, but the result is that everybody in those areas hates roundabouts with a passion.
I'm experimenting with something that seems promising now. I think you're right about the test vs. comment issue. If you have code testing a boundary condition, you can pretty much say "This tests a boundary condition", but you might end up writing 3 or 4 tests to actually make sure that all the boundary conditions are satisfied. So what I've done is separate TDD unit tests from BDD acceptance tests.
My process at the moment is to create a new test directory at the beginning of an iteration. In that directory, I create a test file for each story in the iteration and place the contents of each story in a comment. When I start a story, I write a behaviour oriented test and show that it fails. If I get to a point (it doesn't always happen) where the code necessary to satisfy the behaviour oriented test is more than what the test covers, I write a unit test. This usually happens if I create a new class, for instance. These unit tests are organized in the same way that the code is organized.
When I'm refactoring, the unit tests are usually hit harder than the behavioural tests because they are more highly coupled. But I keep track of the code coverage. When I'm refactoring the unit tests, if I notice that a unit test is already covered by a behavioural test, I actually delete the unit test. This keeps the coupling to a minimum. Similarly, when I'm writing a new story, if I have behavioural requirements that are the same as a previous story, I will move the test into the new story.
What I end up with is a directory tree containing unit tests that are organized like the production code. As I refactor code, these tests tend to be replaced by behavioural tests and the only thing that remains are minor details or assumptions that probably don't need to be pointed out explicitly when reviewing the code.
I also have one directory for every iteration, containing tests organized by story. As the functionality changes, the old test files get smaller and smaller. If they become empty, I remove them. This gives you a pretty good idea of the functionality in the application ordered by the date that the functionality was added. So far this has been easier for me to search when I'm looking for something. You could potentially create a new directory containing symlinks to the behavioural code that presents everying in a different order, but so far I haven't felt the need for it.
The other cool thing that I've experimented with is modifiying the test framework so that a burndown chart is created automatically from the behavioural tests. Originally, each story has no tests in it, just comments. This means the story hasn't been started. As soon as a test is added, the story is started. The story has an effort estimation, which I find is often indicative of the number of tests I will need. Thus, you can estimate how much effort is left in the story by the number of tests written. When the story is finished, it is marked as such. When all the stories are finished (and the tests pass) the iteration is completed. You can also compare the effort vs the number of tests and identify areas where the testing/documentation is not as complete as you might expect.
I've only been doing this for a little while, so I'm not sure how well it will work out, but like I said it looks promising so far.
Slashdot Mirror
BnB seems to be a regular troll, but in this case is factually correct. Works licensed under a permissive license such as MIT, Apache, BSD, etc are free software. They meet all the conditions of free software. The FSF goes to great pains to point this out. They encourage people to use more permissive licenses where it makes sense. For example, for a library that needs to work interoperably in a lot of situations. This was why the LGPL was created.
The in cases where there is no advantage to choosing a more permissive license from a free software perspective, the FSF would like people to choose a copyleft license like the GPL. The reason is that it guarantees that downstream users continue to enjoy the benefits of the free software.
There is no question that copyleft licenses have more restrictions for developers than more permissive licenses. To deny that is obviously false and is precisely what BnB is trolling for. If she "catches you in a lie" she can claim that free software supporters are liars, pointing to you. She chooses the term "more free" to push your buttons. If certain freedoms are a moral imperitive according to the FSF, then *more* freedoms should be better, right?
The truth is that the goal of free software is "software freedom" as defined by the 4 freedoms. This is the goal. To say that another license offers other freedoms is beside the point (at least for free software advocates). I might write a license that allows people to smack me over the head with a herring. That is arguably more permissive than even public domain, which offers no such freedom. But normal people aren't concerned with their freedom to whack me with herring and so it is irrelevant.
There are times when I really do value the ability for writers of non-free software to use my code in their products. In those cases I will choose a more permissive license. In cases where I do not value that ability, I will not offer it. Some freedoms are more important than others. I value software freedom (as defined by the 4 freedoms) -- especially for downstream users -- more than I value the freedom of downstream developers to distribute the code in any way they wish. There are times when I choose one over the other. This is only rational.
I already replied to you previously, but now I have a better idea what you're on about. MS Paint can't do the kinds of things that I use the GIMP for. If you want MS Paint, the GIMP is not what you are looking for. A quick google search gave me: http://pinta-project.com/
Neither the GIMP nor Photoshop is designed with that kind of simplicity in mind. They are designed for far more sophisticated uses. I don't think you are trolling. I think you are honestly pointing out what you see as a gap in available software. But just because you personally can figure out Photoshop doesn't mean it is intuitive. I have a friend who is a graphics designer who had a terrible time learning how to use it. Software designed for complex problems is rarely ideal for simple problems.
I'm not a photo editing specialist, but I was able to use the GIMP to do quite a lot. I didn't even use any GIMP tutorials. I used Photoshop tutorials and looked in the GIMP UI until I found things that looked similar. While there were historically a few workflow issues (especially with the text tool), I have found *nothing* in the GIMP that stops you from using it casually. Personally, I wouldn't use it for simply touching up photos (red eye reduction, color balance, etc) because there are much simpler tools for that. But, for instance, I need to create worksheets that utilize pictures from a printed textbook. The book won't lay flat in the scanner, so I usually just take a picture with my digital camera. Then I use the GIMP to stretch the images so that the pictures are square again, decolorize the pictures, mask them and create transparency where the picture is white. Also if there is a hash pattern in the picture I may need to get rid of the moire pattern. Like I said, I didn't know how to do any of this before I started and I learned using Photoshop tutorials. It was not difficult in the least, so I just can't understand where you are coming from.
My reply to "Why isn't it all in one window" has always been, "Why should every single application implement a tiling window manager?" It's a crazy idea. If you have information that needs to be separated, it should be in separate windows. Then I can resize, reposition, restack any way that I want.
I think where we're falling down is that many people want a semi-tiled window manager. By that I mean they want to group certain windows and have them tiled, but leave other windows floating. Then they want to be able to resize the group of tiled windows together, maximize them as a group, or minimize them as a group. And they want to be able to remember from session to session how those windows are grouped and tiled. But they don't want windows to be tiled all the time.
None of the popular window managers has this functionality. I know there were a few several years ago that had some of those features, but I'm not aware of anything that has all of those features. I honestly don't think it's a lot of work for some enterprising person. It's kind of strange. Even though I see the utility of a tiling window manager, I like seeing my background peeking out from behind my windows. I don't think I'm alone on that front.
What's worse is that if you base all currencies on the same finite resource, the rich countries corner the market in that resource. If you want to bolster your currency, you have to buy the resource, but nobody is selling. This raises the price of the resource, strengthening the rich country's position and weakening the poor country's position. This actually happened and it led to the abandonment of the gold standard.
I suspect the OP was mistakenly thinking about the devaluation of the US dollar against several other currencies (or perhaps against gold). At least that's how I interpreted it. Of course, that's not really inflation because you are measuring against a moving baseline, but it's a relatively easy mistake to make.
Actually, it's a little different. Current fiat currencies create money through debt. They don't create money at a constant, predictable rate. If someone wants to borrow money and the bank approves it: bam; new money is poofed into existence.
But you are completely right. This is the major problem with Bitcoin *as a standard currency*. One of the most imporant things in a funcitonal currency is that it is easy to get it into the hands of people who don't have it. This facilitates production. If people are blocked because they need to buy a boat, or buy fertilizer, or whatever, then they can't produce. If they can't produce, there is a scarcity and other people can't produce. It ripples right through society. Society works best when everyone has enough to do what they want. This maximizes production and hence true wealth.
Bitcoin limits the speed that bitcoins can be brought into existence. It also limits the total number of bitcoins in existence. This is antithetical to the issue above. Bitcoin proponents argue that because there are no fixed units for bitcoin (you can divide them up almost infinitely), this limit to the total number is a non issue. If everyone only has 1 bitcoin, they can trade in 1/1000 of a bitcoin. The other advantage of Bitcoin is that it is arguably more fair than our current banking system, which has "special" players (banks) who are allowed to poof money into existence and hence become very rich by doing precisely nothing.
IMHO, there is still a major problem, though. The first is that it doesn't matter how much you can divide bitcoins up, if you have 0, there is nothing you can do. You need to get *some*. The second problem is the way new bitcoins are distributed. It's better now with mining pools, but at first people were receiving bitcoins in 50 BTC increments. So either you had lots of bitcoins or no bitcoins. The number of people with fractional bitcoins was small. Trading was/is done in large increments even though bitcoins are scarce.
Finally, while it is downplayed, deflation is a major problem for Bitcoin as a standard currency. If you increase the value of bitcoins by dividing them up into smaller and smaller increments (so that more people can participate), you can't have loans. Nobody will be stupid enough to borrow 10 bitcoins when the value increases over time. If I can make 2 BTC the first year, 0.2 BTC the second year, and 0.02 BTC the third year (ie the value of BTC rising 10x per year), I will never make enough money to pay back the 10 BTC loan. Of course 10x deflation is exagerrated, but you get the point. Inflation is a feature of standard currencies, not a bug.
But, Bitcoin does not have to be a standard currency. It works well as an exchange mechanism on the internet. Not that many people accept it right now, but looking at the trading graphs, volume seems to be relatively strong trading against the US dollar. As long as it is liquid, it is a viable exchange mechanism.
Sorry for typing a book. Hope you found it interesting.
P.S. I don't think a company getting most of the new BTC will be a major problem because they will be selling them for USD as fast as they can. If they horded them, then it would lead to deflation. But as long as it is possible to buy and sell with USD it will still work fine as an exchange mechanism.
I got modded down in another thread saying the same thing, but I'll try again. Conventional farming is about highest yield *per dollar*. There are ways to increase yield without the use of a lot of external inputs, but they are labor intensive.
I'm not really a big fan of "organic". You're still locked into the thinking of using external input (fertilizers, pesticides, etc). You're just changing the ones you are using. To take an extreme, you could actually stand over your crops and pick weeds by hand as they emerge, or squash bugs with your fingers. I do it on my plants all the time, because I like hanging out in my garden. Fertilization of crops is a matter of getting the correct nutrients to the plants at the right time. There is more than one way to do this. The conventional way is to practically drown the plants in nutrients, to the point where we get large amounts of run off. IMHO, current organic practices are not a lot better. We're just changing where we're getting the nutrients from.
Our biggest problem is the low price of food. Wheat is currently $300 per metric ton. That's 30 cents per kg. Along the supply chain, this gets multiplied up to incredible levels. How much do you pay for flour? How much for a loaf of bread? We squeeze our farmers down to the point where a single person must grow a crop for hundreds or thousands of people. They are forced to use conventional techniques due to cost.
Fix the cost of distribution and suddenly farmers have more options. We should be pursuing as many as we can. Like you say, vertical farming is promising. There's nothing wrong with closed looped hydroponics. But as we put the vice on farmers by constantly reducing (in real dollar terms) the price they receive for their product, we reduce our options.
No. Organic farming is unsustainable *at present prices* for our population levels. You can easily get the same yield (or even higher) with "organic" farming. If you want to control pests, just have tons of guys standing around killing them by hand (well, that's really overkill).
Current "conventional" farming practices are geared towards economics, not yield. But why? 1 kilogram of barley is sold for about 23 cents a kg. That kg of barley will make about 4 liters of beer and represents at least half of the cost in terms of ingredients. Why is 23 cents of barley costing $10 as beer? Who is receiving that money? (hint: it is not the brewers nor the maltsters nor the truck drivers receiving the bulk of it). What are the implications if we pay farmers 10 times as much for barley. Will beer increase in price by about $2.30 per gallon? Why not?
Alternative forms of farming are very viable, but it's possible they will require more labor. The question is if we will stop forking money over to certain people who are making it too expensive.
I wish I could mod you up. You are exactly right, I think. There is a big difference between a "good" API and a "bad" API that has nothing to do with functionality. They could both accomplish the same thing, but there is a value in creatively designing the expression of the API. I think it is probably even a better candidate for copyright than other collections that are already recognized as having copyright. However, as a programmer, I do not want APIs to be copyright-able. It destroys interoperability and tilts the balance too far towards large companies being given a perpetual monopoly. All the have to do is write a standard and then change the API every 90+ years...
How this got modded up to 5, Insightful, I just can't understand. It demonstrates a complete lack of understanding of Bitcoin.
The crypto behind bitcoin is trivial. If you don't believe me, go ahead and read the code. There is really nothing to it. It hashes numbers. That's it.
The insight in Bitcoin is that you can get people to calculate difficult problems and put the answers in a chain. A chain of correct answers is "valid". You use a one way hash so that it is easy to determine if the chain is valid, but hard to calculate answers to create a chain. You publish the chains and the longest one (the one that was the most costly to produce) is the "real", "valid" one. To make your own chain the "real" and "valid" chain (i.e. cheat), you have to create a longer chain faster than everyone else in the system working together. This is a really insightful idea, but I wouldn't call it "crypto".
The *really* smart idea, though, is that you measure the speed at which the chain is growning. If the chain is growning quickly (there is more horsepower out there), you add restrictions to the problem (only certain hashes are valid) to make it more difficult to make the chain. The more people calculating the chain, the more hardware you need to create your own chain (i.e. cheat).
And then the *really, really* smart idea is to provide incentive for people to work together to calculate the chain. By devaluing the currency slightly and awarding a prize, they make it financially better to cooperate than to cheat.
So in summary, to the extent that you value Bitcoins (and some people do), the value comes from the cooperation in calculating the block chain (i.e. mining). The more people who do this, the more secure the system is. This literally supports the value. The insightful way that incetive was provided to make this work is obviously valuable as well. The crypto (calling a hash function over and over again until you get an answer lower than a certain target) is practically non-existent.
VCs usually look for a potential ROI of 20:1. Investing $500K means that they see a potential of extracting $10 million over a period of possibly 5 years. Blocks are generated at a rate of 52560 a year. Each block will pay 50 BTC at the moment. Assuming they could sell BTC at $5 each, they need to sell 400000 per year to get $2 million in revenue. That's 8000 blocks or a little less than one in 6 blocks. I don't think they will be able to do that simply by harvesting cycles from gamers playing free to play games. They won't get enough GPU to do it.
I haven't RTFA, but they must either have some other ideas, or they are counting on the value of bitcoins to rise. IMHO, I think it is a risky strategy. By selling 1/6th of all new bitcoins they will also put pressure on liquidity. I'm not sure there is that much demand, so I would expect the value to drop. VC is inherently risky, but my bet is that they haven't really done their homework on this one.
My biggest problem with the system is that if the system becomes popular, the incentive to cheat becomes greater (as the currency becomes more liquid, the value you can extract is higher). So you need to have enough economic incentive to keep the algorithmic complexity high enough to prevent cheating. I did some back of the envelope calculations to try to estimate what vlaue they are going to need, and it seemed to me that it will be a substantial percentage of the transaction (IIRC a few percent). I suspect that this will end up being higher than people want ot pay.
The prices on Pottormore are even quite reasonable. I would easily pay double for the Japanese version of the e-book, but alas it doesn't seem to be for sale. E-books let me look up words in the dictionary very quickly so they are much more convenient than paper for studying. I hope they figure it out. As strange as it sounds, they probably don't own the copyright for the Japanese version... sigh.
To paraphrase Karl Lagerfeld, "People who buy knockoffs of my product are not my customers". In the same way, people who do not pay for ebooks are not customers of the publishers. I can understand the frustration people have when they see someone take their product without paying for it. But if they concentrate on the people who *will* pay for it, (i.e. their actual customers) they will be better off.
I don't see anything that supports this claim. Hopefully you know better than I do. If so, please post something. The Berkeley vs. AT&T case clearly established that *those* APIs could be implemented. I have been unable to find references, but based on my memory of the time (which is likely faulty), I think there was an explicit statement before the split that the API would be open. This may actually have been before source code was considered copyrightable so they would not have really referenced copyright. In the settlement of the lawsuit, I believe that they agreed to allow implementation of the API, but I don't think they discussed copyright of the API per se. Unfortunately I can't locate a good link.
Linux is written to the POSIX standard. The POSIX standard is copyright IEEE and the Open Group. They have been clear that they won't sue people for implementing the standard (though, they also own a trademark which is a separate issue...). Additionally, the ability to implement this was pretty much covered by the BSD lawsuits in the 80s, which said that *this* API could be implemented (not that *all* APIs could be implemented).
I don't know for sure, but I don't think that the issue of blocking the implementation of APIs has been tested. POSIX is a special case. SCO was *clearly* full of shit. It is much less clear wrt to Oracle and Java from my position. The strange thing is (as others have mentioned) that Oracle seems not to be pushing the API copyright issue and are instead claiming that Google needed a TCK license. Things may change later, though.
I'm equally puzzled. They may actually have a case if they say that the API is copyrighted. Yes, it is a collection of facts, but I think there's a strong argument that it is a creative collection. The API was actually designed with an asthetic purpose. Like you say, whether or not reimplementing the API is fair use would seem to be the key issue (I hope to hell that it is, or even better that APIs can't be copyrighted).
But they are confusing the issue with this TCK stuff which seems blantantly obvious that they can't win. Probably they know something I don't. It is possible that it is simply a FUD attach (i.e., a long drawn out period of uncertainty wrt to the legality of Android causing people to develop for alternatives). In other words, they don't expect to win, but just want to confuse stuff as much as possible for as long as possible. I'd be looking for a money trail from MS in that case, though...
Ah, you see, they can't really verify that you aren't carrying anything dangerous. So, instead, they try to keep people with a long history of suicide bombings off the plane. I mean, if they've blown themselves up on 4 of their last 5 trips, there's a good chance that they will do it again.
It's not so hard to understand. You just have to start thinking like the TSA.
At least I haven't seen Google claim that Davlik etc. are derivavtive works of the GPLv2 release of Java.
Actually, this is the most insightful comment I've seen on this topic. Dalvik is indeed not (intended to be) a derivative work of the GPLv2 release of Java. It is licensed under the Apache license. You are allowed to make a derivative work under the GPL, but there is nothing allowing you to make a derivative work under a different license.
The key at this point is whether or not a re-implementation of the API is considered a derived work. If it is, then Dalvik is infringing since it is not licensed under the GPL.
I can tell you my preference with regard to whether implementation of an API is a derived work, but I have no idea what a ruling would be on it. The question put to Ellison is asking if the Java programming language is free. It is not asking whether or not the GPL implementation is free (which is obviously is). As much as I really hate to say it, I don't think he *can* know. This is what this trial is going to determine. Scary.
Meanwhile I'm learning that the teacher and the test creator are idiots, and can't be trusted to teach me anything useful or accurate. Ever.
This is useful information. Every student should take control of their own learning. It is a mistake to implicitly trust one source of information, because as hard as we all try, even the best of us are biased in some way (or just plain wrong).
The problem with the school system is not that students lose faith that the information flowing from their teachers is correct. The problem is that students are expected to unquestioningly believe it in the first place. In fact, they are punished for questioning. If your accademic success is dependent upon you parroting what the teacher has told you regardless of its truth, you have significant problems that go far beyond the teachers.
A "teacher" should not be a shoveller of facts. They should be a mediator in a student's discovery of knowledge. Whether the teacher knows the answer or not, the important part is that you should be able to discover it. If you can, the teacher has succeeded. Not understanding this point is the main problem with education today, IMHO.
This actually reminds me of a question I put on an English test (for Japanese students):
Mary doesn't each meat, fish or eggs. Mary only eats plants. What is Mary?
My student answered "cow". I think I gave him bonus points.
I've lived in a few Canadian cities which "tried" roundabouts. The problem is that they completely screwed up (and I've seen this in both Winnipeg and Ottawa so I wouldn't be surprised if this has happened other places in NA). They gave the right of way to those entering the roundabout rather than those exiting the roundabout. This, of course, make the roundabout worse than useless. As soon as there is any significant traffic, everything grinds to a halt. To this day I don't know what possessed them to be so stupid, but the result is that everybody in those areas hates roundabouts with a passion.
I figured it out :-) What I find hilarious is that my original post was actually modded down, probably due to the strong reaction of the AC.
I'm experimenting with something that seems promising now. I think you're right about the test vs. comment issue. If you have code testing a boundary condition, you can pretty much say "This tests a boundary condition", but you might end up writing 3 or 4 tests to actually make sure that all the boundary conditions are satisfied. So what I've done is separate TDD unit tests from BDD acceptance tests.
My process at the moment is to create a new test directory at the beginning of an iteration. In that directory, I create a test file for each story in the iteration and place the contents of each story in a comment. When I start a story, I write a behaviour oriented test and show that it fails. If I get to a point (it doesn't always happen) where the code necessary to satisfy the behaviour oriented test is more than what the test covers, I write a unit test. This usually happens if I create a new class, for instance. These unit tests are organized in the same way that the code is organized.
When I'm refactoring, the unit tests are usually hit harder than the behavioural tests because they are more highly coupled. But I keep track of the code coverage. When I'm refactoring the unit tests, if I notice that a unit test is already covered by a behavioural test, I actually delete the unit test. This keeps the coupling to a minimum. Similarly, when I'm writing a new story, if I have behavioural requirements that are the same as a previous story, I will move the test into the new story.
What I end up with is a directory tree containing unit tests that are organized like the production code. As I refactor code, these tests tend to be replaced by behavioural tests and the only thing that remains are minor details or assumptions that probably don't need to be pointed out explicitly when reviewing the code.
I also have one directory for every iteration, containing tests organized by story. As the functionality changes, the old test files get smaller and smaller. If they become empty, I remove them. This gives you a pretty good idea of the functionality in the application ordered by the date that the functionality was added. So far this has been easier for me to search when I'm looking for something. You could potentially create a new directory containing symlinks to the behavioural code that presents everying in a different order, but so far I haven't felt the need for it.
The other cool thing that I've experimented with is modifiying the test framework so that a burndown chart is created automatically from the behavioural tests. Originally, each story has no tests in it, just comments. This means the story hasn't been started. As soon as a test is added, the story is started. The story has an effort estimation, which I find is often indicative of the number of tests I will need. Thus, you can estimate how much effort is left in the story by the number of tests written. When the story is finished, it is marked as such. When all the stories are finished (and the tests pass) the iteration is completed. You can also compare the effort vs the number of tests and identify areas where the testing/documentation is not as complete as you might expect.
I've only been doing this for a little while, so I'm not sure how well it will work out, but like I said it looks promising so far.