What the article was about was fooling the reader into believing there's a consensus. Truth is, there is none, and it is extremely hard to know how much human activity plays a role. Anyone who pretend that WE KNOW is a fool. Making a model of the entire earth isn't an easy task.

The problem is not the change, but what change. As I wrote, everyone agrees that human activity has consequences. By how much, nobody agrees. Which is why asking such question has very little importance.

But the question is: by how much is it caused by humans. And that's a very difficult question to answer.

Yes, the acidic waters are a big problem which should be addressed. Yet I fail to see how this is related to temperatures.

Maybe you could start by reading my post before answering. I haven't taken such side.

Yeah! It's like saying that 97% of priest believe in god anyway. Plus that number means nothing, it would be foolish to say that human activity has no consequence, though what matters is how much.

Also, science isn't about democracy. More than 60% of the scientists didn't believe in the movements of continents in the 50ies, yet it is admitted now.

This is not what the history of security shows in platforms such as Windows. The multiplication of DLLs everywhere in the system, with many apps embedding their own version of the DLL really is a security nightmare. And it's far from being rare.

Well, if an application has a security problem, that is only one occurrence of an issue. If a popular library that ends up being included in hundreds of apps, you have hundreds of packages to upgrade, and that may be simply doomed to be impossible to fix (contacting everyone, making sure they upgrade, etc. is not an easy task).

Which is why such piuparts tests should be automated before reaching the app store. Easy to implement, and the problem is fixed forever. Don't tell me that developers will not want to comply, they do already comply to so many stupid rules from Apple, I don't see why they would refuse a QA rule (which make sense) from Canonical.

Sure, that's easier for the developers and Canonical. No doubt for that. Though that doesn't mean that this is better for the end user. My opinion is that it makes it a very inferior system, with duplication of libraries and security problems, with potentially very bad safety consequences.

Probably we have to link to his QA page: http://qa.debian.org/developer.php?login=cjwatson

root@host>_ ~# apt-get remove sysv-rc
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
file-rc
The following packages will be REMOVED:
sysv-rc sysvinit
The following NEW packages will be installed:
file-rc
WARNING: The following essential packages will be removed.
This should NOT be done unless you know exactly what you are doing!
sysvinit sysv-rc (due to sysvinit)
0 upgraded, 1 newly installed, 2 to remove and 0 not upgraded.
Need to get 40.2 kB of archives.
After this operation, 329 kB disk space will be freed.
You are about to do something potentially harmful.
To continue type in the phrase 'Yes, do as I say!'

The fact that their are so many kinds of DLLs all around is one of the reason why Windows is unsafe, and probably one of the reason I will never trust it. If all this crap is brought to GNU/Linux, then it's time to find another platform.

However, a lot of people cares about security, and it's really bad if we have 10 versions of the same library with a security hole, and have no way to know if a given app developer will care updating that lib.

This is called "Q/A". In Debian, there is "piuparts" which can be used for this kind of check, and it would be trivial for Canonical to do such testings when an app is submitted.

That's the role of the developer to do that kind of checks. With the proper tools, it's easy to do, so it doesn't cost so much time (and hence money).

But phone flash are usually very slow.

You are arguing very poorly, IMO.

No, it doesn't make sense to have N versions of the same library. This is pure crap, only driven by the commercial interest of having an app store where people make money. My n900 works pretty well with .deb files and real dependencies, there's absolutely no technical reasons why a phone would be different from any other kind of operating system.

Now, the words from Shuttleworth are even more lies if they implement this shit. It will not be like the desktop OS. And definitively, I don't want such crap.

You fool... Traceroute can use ICMP, TCP or UDP. It depends what the client chooses... By default, if I'm not mistaking, traceroute from netkit uses UDP.

While the implementation (eg: the distribution packages and the code behind it) are moving a lot, and in a very rapid way (and I quite know it, since I'm the Debian Developer working on Openstack packaging), the API clients stays and is quite stable. And that is what counts for a user: you would always use either the python-client modules, or the shell command line tools associated with it.

First of all, what you are talking about already exists, and some people already do that (eg: migrating to the cheapest). There is even a market place to trade compute workload, with future market and all, just like with Enron!!! Though considering only price for a hosting provider is a big mistake IMO. There are lots of other parameters that comes into consideration, like quality of the support, bandwidth, overcommitting of the compute nodes, etc.

What you are asking for is the default in Openstack. I have just finished writing a howto about Openstack networking in here:
https://wiki.debian.org/OpenStackHowto/Quantum

So, basically, you first add a virtual router with a NIC on a public IP address, and the other NIC on your virtual LAN. Then if you need a public IP address for a VM, you just add a "floating IP address", which basically means that you will have NAT port redirections going to that IP in the LAN.

All this is completely standard in Openstack, if your provider is using Nova and Quantum in a normal setup. The problem is that Rackspace is half in the past (with their own previous implementation which they want to stay compatible with), and half in the future (with implementations of things which aren't in the mainstream project yet because this takes time, cells is a very good example that turned out very well since it is now integrated). As for HP, it is a very different story. They decided to stick with the Diablo release for a long time, and basically forked it, also working on features away from the project (eg: healthmon).

Finally, I strongly believe that both Rackspace and HP are committed to have these problems solved, as this is very problematic for them also (eg: maintaining their own branch means a big loss in terms of human hours of development). So I am convinced that in the long run, these problems will go away.

You are talking about tempest here! :)