Slashdot videos: Now with more Slashdot!
We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).
Link to Original Source
This is why you can choose between a permissive license (such as the Apache license) and a restrictive one (like the copyleft GPL). I personally don't know why you should care that someone took your code and sold it to someone else. You contributed to the open source software in the world, making it better for everyone, including that company who was able to then make some money out of it. Why do you begrudge them that? They used that to pay their marketing people, developers, support, etc. And so the world goes around.
If on the other hand, you wanted to keep that right to yourself and prevent anyone except you from making money selling your code, you could contribute under the GPL. That is a very useful license for companies who want to exclude other companies using their code to make money from (a good example is mysql). There are other ways to commercialise this software, but not the obvious path of improving it and selling it.
I speak from experience. I have one GPL project which I hope to commercialise myself one day (and so I try to exclude others from the game by making it GPL). And I am a member of the Apache Foundation where my contributions might be used by companies to make money. Good luck to them...
Since banks regularly charge even small customers less than this, I don't see the attraction. I have customers who turnover as little as $2m per year and with merchant rates down to 0.8% for Visa/MC. I don't understand why any merchant would be paying such high rates. Amex of course is much higher, but in Australia that's easily solved: very few retail merchants accept Amex.
The biggest improvement that happened in Australia was when retailers were allowed by law to charge a surcharge to the customer for processing credit cards. That has been very successful in keeping the merchant rate low since banks are not only competing with each other on credit card fees, but also with other forms of payment such as debit cards, EFT or cash.
Actually the latency from Australia to Amazon's Singapore datacentre is quite a bit higher than to the US West coast datacentre. If you look at a map of undersea cable runs, you'll see that Australia has actually quite a bit more low latency and high bandwidth connections to the USA via Hawaii and Guam than through south-east Asia.
With significant new cable coming online later this year, connectivity to the USA is only going to get better.
No. Point to point microwave technology is not helpful to get connectivity out to lots of people. The dishes need to be perfectly aligned to each other since the signal is deliberately kept within a very narrow beam. Microwave doesn't bounce off things like the lower frequencies used for wifi.
I will not comment on your superior art knowledge and ability to price artwork over the internet. However I rather like his work. This one is particularly interesting: http://www.milanigallery.com.au/artwork/little-johnny (although the context is probably not obvious to anyone outside Australia).
However, you are wrong about the way legal fees are calculated by Australian courts. They have a schedule of fees which can be claimed by the victor in a case. This schedule is fixed and has little to do with the actual costs incurred. Typically 30-50% of actual costs will be recoverable, and in this case I can imagine that he may have engaged specialist international contract and intellectual property lawyers with knowledge of US law.
A large number of companies I know about have policies of not allowing GPLv3 within their organisations, mainly because of the extremely aggressive patent invalidation clauses which are part of GPLv3. Whether you believe it is correct or not, the FreeBSD developers have rejected GPLv3 because many important downstream users of FreeBSD would have difficulty with using it had GPLv3 been allowed in, even in the compiler toolchain.
It actually is complicated. You may wish to believe that many corporations are just wrong in their concern about the GPLv3. A developer far removed from a legal department need only write a small compiler plugin to solve a problem they are having, and suddenly the company is mired in legal problems and have potentially given away a large swathe of their patent portfolio.
So, I've been modded down to troll because I disagree with the prevailing Slashdot opinion that the GPLv3 solves all the world's software licensing problems. Even the FSF explicitly states that "Developing nonfree software is not good for society, and we have no obligation to make it easier." Since GCC is their flagship product, and they have made it slightly harder for people to use it for commercial software, I still believe it is wise to be rather cautious of the post 4.2 license changes.
No, it is not as simple as this. The GCC GPL exceptions are quite complicated. Just outputting some intermediate builds from your computer (flicking a switch in the compile arguments) suddenly makes your entire proprietary product GPLv3. That is a very scary thought for any corporate legal department. http://www.gnu.org/licenses/gcc-exception-faq.html
"Oh, you mean we accidentally released a GPL version of Microsoft Exchange server because of a toolchain change in our developer workflow. Oops...."
The FreeBSD project has already declined to upgrade its GCC implementation to the GPL version 3 release. That is one of the driving forces behind the move to clang/llvm within that community. So this really isn't quite so simple... The GPL v3 is quite scary to many corporations (as it was intended to be) and so they refuse to have anything GPLv3 installed on their machines at any level. I manage a 5 person development team and would always avoid anything GPLv3 without serious consideration of the implications.
The only reason they do instant strep tests at MD offices is that they want to know the results before you walk out the door. The same goes for rapid STD tests: If you walk out the door and have to come back to get the results later, there's a chance you won't return.
A DNA test is the ultimate in non-urgent tests, and is going to remain something you head off to the phlebotomist to get done... right up until the day where they are done routinely at birth and you leave the hospital jugging a baby, birth certificate, and a flash drive containing its DNA sequence.
FreeBSD 9.0-RELEASE machine images for Amazon EC2 are available for m1.large and larger instance types: http://www.daemonology.net/freebsd-on-ec2/
Link to Original Source
A few weeks ago, in the wake of stories about Dropbox's poor security, a user of my Tarsnap online backup service mentioned that he had heard Jungle Disk recommended as a secure alternative. This surprised me, since I remembered from the early days on the Amazon Web Services developers forums that JungleDave — as the author called himself — was always far more concerned with ease of use than with security. Had things improved? I decided to investigate, and I wasn't impressed with what I found.
Unlike most online backup / storage companies, Jungle Disk has released source code, here and here. They did this because in the early days of Jungle Disk, people wanted some assurance that they could get their data back if Jungle Disk went out of business; since the Jungle Disk client stores data directly to Amazon S3 and Rackspace Cloud Files, it is also possible to read files directly from those services. (This is also a feature which Tarsnap users frequently request, but the design of Tarsnap — including amortizing S3 PUT costs across blocks uploaded from multiple users — makes it impossible to provide such a mechanism for Tarsnap.)
Now, this code is not the code used in the actual Jungle Disk client — like most other online backup services all you get is a binary, and you have to trust that it isn't doing anything wrong (either due to intentional mis-features or accidental bugs) — but the fact that the published source code can interoperate with the Jungle Disk client code does at least provide us with some information about what Jungle Disk does cryptographically."
Link to Original Source
Tarsnap's snapshotting model is a bit more sophisticated than how duplicity works, and its separate keys for writing/reading/deleting archives makes it possible to do some things you can't do with rsync.net (e.g., you can have a server which does daily backups with Tarsnap while still making it impossible for someone who roots the server to tamper with said backups).
But yes, tarsnap and duplicity+rsync.net are certainly more similar than, say, tarsnap and dropbox.