The problem isn't so much the bargain introductory rates, we've had them in Australia for decades.
The problem was this was the first time America had been introduced to them, and a HUGE volume of them were done in a single 2 year period (unlike here, where they spread out naturally).
So the problem of the introductory rates expiring and people defaulting came in a huge single wave, far higher than in countries that have had them for a long time.
There's a couple of great economics texts which boil down World War II to the following.
1. Germany's economy imported food and exported manufactured goods.
2. Economic limitations placed on Germany were leading to an inevitable foreign exchange crisis in which they would no longer be able to fund the "importing food" part of that relationship.
3. The only way to resolve this was to remove the limitations and then expand their resource base so that they wouldn't need foreign currency to buy food with. Thus, World War II (grossly simplified of course).
4. At no point during the war did the Germans ever exceed 25% of the wartime GDP of the combined allies, making ultimate defeat inevitable once they lost their initial technological advantage, which was also inevitable (because of the 25% thing).
Especially if that game was something awesome like Tony Hawk's Skate'n'BASE Jumparama, where you have to do rad skate tricks off of buildings, cliffs and other high structures.
Did you see that demo with the invert 720 low-deploy with the sports chute? I can't wait to try it for real off the radio mast down the road!
What I liked about this ruling was just how much they won it.
The judge said that Safe Harbour provisions did apply to the ISP... but they weren't needed because they only applied if the ISP explicit approved that user activity (which they do not)... and any infringement notices from the studios didn't need to be sent to consumers due to the Privacy Act (iiNet sends all infringement notices to the police instead)... and in any case the sending of infringement notices and subsequent banning etc was not considered a valid copyright prevention mechanism.
Step 3 China stops making the basics of life for Americans and starts making killbots instead.
Step 4 Wallmarts all over America close as they run out of goods to sell, only to be repurposed shortly afterwards as regional killbot distribution and maintenance hubs.
If I worry about whether you will ever finish the book, why would I bother paying for the first chapter (or even bother starting to read the story at all)
Perl dependencies are specified by class name, not by distribution package name. So (theoretically) as long as there's a way to resolve a class to a file (which is standard) and thence to an operating system package ("which package contains file X" shouldn't be that hard) then there's no reason that Perl package dependencies can't be mapped down into distro package space.
As for the versions, 1.30 is more correctly more recent than 1.2437, because the CPAN turns multi-part versions 1.23.1 into decimals using an admittedly icky triplet system where each part of the multi-part is normalised into three digits.
1.2437 is a normalised version of 1.243.7. Downstream distos have implementations of this logic available to them in places like CPAN::Version. But yes, it is a bit weird for the newcomer. It's the price of 5-10 year back-compatibility, alas.
As for Perl 5.10, almost nothing on the CPAN will depend on it. The current recommended back-compatibility targets are Perl 5.6.2 for low-level or toolchainy stuff that needs a decade of back-compatibility, or Perl 5.8.5ish (around 5 years) for regular things (which is the first version where Unicode became bug free and universally usable).
So Perl 5.10 is having almost no impact on compatibility, and won't for at least another couple of years.
I offered to port the CPAN to Python about 6 years ago as a gift from the Perl community, and I repeat the offer every now and then.
It usually goes down as well as you might expect when someone from Python people hear the word "Perl" anywhere in a coversation:)
In the mean time, we've quite successfully ported and adapted the CPAN model for JavaScript with OpenJSAN and (more recently) for C with The CCAN (run by Rusty Russel).
Both of these are arguably more sophisticated than Python's packaging, although of course both of them are still down in the range of 100 packages.
> Half right. A programmer's job is to take an idea and express it in a way that both computers and humans can understand. If only a computer can understand it, you might be a Haskell programmer.
There, fixed that for you.
That every sysadmin on the planet pretty can learn Perl means there must be humans in that group somewhere.
Now a language you have to be a mathematician to learn on the other hand...:)
Many authors of open source software (particularly smaller cases) will only ever experience a limited range of situations, which will influence the design.
People who have only ever worked in large corporations will make things overly complex to configure, people who only work in startups may undervalue documentation and reporting (I'm making hugely vast generalisations here).
One valuable thing you can contribute is your experience using that software in government. You understand the nature of government and its priorities probably a lot better than the original developers.
Contribute bug reports, feature requests, and commentary (ideally into proper bug/feature tracking systems) that address specific areas of interest to government.
Open Source developers love it when they hear their work is being used in interesting real-world scenarios, and your experience with government can suggest directions they might otherwise not have considered, or have underprioritised in the past.
Slashdot Mirror
... Facebook is running an open call data science competition to win an interview/job on their data science team.
(Disclosure: My work is running the competition for them)
The problem isn't so much the bargain introductory rates, we've had them in Australia for decades.
The problem was this was the first time America had been introduced to them, and a HUGE volume of them were done in a single 2 year period (unlike here, where they spread out naturally).
So the problem of the introductory rates expiring and people defaulting came in a huge single wave, far higher than in countries that have had them for a long time.
Messenger is a great name, perfectly respectable with a sort of a cute "ZOMG HI Mercury! LUV Earth!" edge to it.
And then you just had to go and fucking ruin it with a horrendous backronym didn't you.
iiNet won - good
But they can send notices now - bad
But they have to pay all the ISPs costs - good (cause it will suppress the volume they send and limit spamming)
"The total eventual circulation of Bitcoins will be 21,000,000 coins. There will never be more coins than that."
Riiiiight, because THAT's going to scale...
Strawberry Perl has been doing betas all the way through the 5.12.0 RC process, so the production release should be out in a week or so.
What the summary doesn't mention is that there's some stuff in 5.12 that allows Strawberry to add:
GCC-based 64-bit support for Windows servers
Strawberry Portable (flash drive) stuff finally works in a first-class manner (with separate core/vendor/site installation targets).
Morality aside, it was economically necessary.
There's a couple of great economics texts which boil down World War II to the following.
1. Germany's economy imported food and exported manufactured goods.
2. Economic limitations placed on Germany were leading to an inevitable foreign exchange crisis in which they would no longer be able to fund the "importing food" part of that relationship.
3. The only way to resolve this was to remove the limitations and then expand their resource base so that they wouldn't need foreign currency to buy food with. Thus, World War II (grossly simplified of course).
4. At no point during the war did the Germans ever exceed 25% of the wartime GDP of the combined allies, making ultimate defeat inevitable once they lost their initial technological advantage, which was also inevitable (because of the 25% thing).
Especially if that game was something awesome like Tony Hawk's Skate'n'BASE Jumparama, where you have to do rad skate tricks off of buildings, cliffs and other high structures.
Did you see that demo with the invert 720 low-deploy with the sports chute? I can't wait to try it for real off the radio mast down the road!
"the people"?
That was last month.
Now days it would be "paid for by Doritos, the crunchtastic taste experience"
... but this exact same thing was a demonstration project at the University Open day ... in 1997
What I liked about this ruling was just how much they won it.
The judge said that Safe Harbour provisions did apply to the ISP... but they weren't needed because they only applied if the ISP explicit approved that user activity (which they do not)... and any infringement notices from the studios didn't need to be sent to consumers due to the Privacy Act (iiNet sends all infringement notices to the police instead)... and in any case the sending of infringement notices and subsequent banning etc was not considered a valid copyright prevention mechanism.
So yeah, they wiped the floor with them.
Step 3 China stops making the basics of life for Americans and starts making killbots instead.
Step 4 Wallmarts all over America close as they run out of goods to sell, only to be repurposed shortly afterwards as regional killbot distribution and maintenance hubs.
Supply, meet Demand.
Moon rocks are $2000 a gram because they are astonishly rare, something you'll happily be taking care of for us.
Your income isn't the price now, it's the area under the curve of the price as your 200 kilograms of rock drives the price down.
No. The first time it was equal parts arms race, chest-beating nationalism, and 100 billion dollars.
Last time my project got mentioned on Slashdot, I saw around 50,000 additional downloads for that release.
So even if it's one-shot, that one-shot can still be big.
If I worry about whether you will ever finish the book, why would I bother paying for the first chapter (or even bother starting to read the story at all)
The people that create the language aren't the same people that look after the packaging system.
We've found that the sanest mix is to install the core OS packages that don't suck, then do a CPAN install of the rest to some /opt/project-cpan path.
That stack of 10 or 20 dependencies turns into a single project-cpan RPM/Deb, and the application just adds the /opt/project-cpan to it's include path.
Now granted, there's no standard tools for doing that... yet.
Ah! The workaround is...
1. Use CPAN to upgrade itself.
2. Install everything else.
Or, more recently, just
cpan App::SVN::Bisect
Is the parent a bad post, or a good troll?
Some responses if I may...
Perl dependencies are specified by class name, not by distribution package name. So (theoretically) as long as there's a way to resolve a class to a file (which is standard) and thence to an operating system package ("which package contains file X" shouldn't be that hard) then there's no reason that Perl package dependencies can't be mapped down into distro package space.
As for the versions, 1.30 is more correctly more recent than 1.2437, because the CPAN turns multi-part versions 1.23.1 into decimals using an admittedly icky triplet system where each part of the multi-part is normalised into three digits.
1.2437 is a normalised version of 1.243.7. Downstream distos have implementations of this logic available to them in places like CPAN::Version. But yes, it is a bit weird for the newcomer. It's the price of 5-10 year back-compatibility, alas.
As for Perl 5.10, almost nothing on the CPAN will depend on it. The current recommended back-compatibility targets are Perl 5.6.2 for low-level or toolchainy stuff that needs a decade of back-compatibility, or Perl 5.8.5ish (around 5 years) for regular things (which is the first version where Unicode became bug free and universally usable).
So Perl 5.10 is having almost no impact on compatibility, and won't for at least another couple of years.
The CPAN installer hasn't had the Perl auto-upgrade bug in several years...
I offered to port the CPAN to Python about 6 years ago as a gift from the Perl community, and I repeat the offer every now and then.
It usually goes down as well as you might expect when someone from Python people hear the word "Perl" anywhere in a coversation :)
In the mean time, we've quite successfully ported and adapted the CPAN model for JavaScript with OpenJSAN and (more recently) for C with The CCAN (run by Rusty Russel).
Both of these are arguably more sophisticated than Python's packaging, although of course both of them are still down in the range of 100 packages.
> Half right. A programmer's job is to take an idea and express it in a way that both computers and humans can understand. If only a computer can understand it, you might be a Haskell programmer.
There, fixed that for you.
That every sysadmin on the planet pretty can learn Perl means there must be humans in that group somewhere.
Now a language you have to be a mathematician to learn on the other hand... :)
Many authors of open source software (particularly smaller cases) will only ever experience a limited range of situations, which will influence the design.
People who have only ever worked in large corporations will make things overly complex to configure, people who only work in startups may undervalue documentation and reporting (I'm making hugely vast generalisations here).
One valuable thing you can contribute is your experience using that software in government. You understand the nature of government and its priorities probably a lot better than the original developers.
Contribute bug reports, feature requests, and commentary (ideally into proper bug/feature tracking systems) that address specific areas of interest to government.
Open Source developers love it when they hear their work is being used in interesting real-world scenarios, and your experience with government can suggest directions they might otherwise not have considered, or have underprioritised in the past.