Reducing what happened with Christian Marillat to only a single thread is deceptive. The issue with his repository breaking upgrades from one version of Debian to the next, and his constant refusal to work within Debian (even though he is a Debian Developer) is all but new.
The more popular the package is the better and more arcane the reasoning is the better, hence why Debian has iceweasel while virtually ever single other linux distro has Firefox.
I didn't comment the rest of, because that's silly enough, so I'll comment only that one. The problem with Firefox vs Iceweasel is located at the Mozilla foundation, which refuses that someone uses the name Firefox (and it's logo) if patches are added. Other distributions might just ignore that fact, but Debian cares about licenses and trademarks. If you want this to change, then you are welcome to ask Mozilla to change its trademark policy.
This is only your view, but not the one of the Debian Multimedia team within Debian. In many ways, d-m.o broke upgrades, disrespecting the version numbers and such.
They pointlessly demanded that he stop using debian in his domain name which achieved nothing.
Not what happened. We asked Christian Marilla (the old owner of debian-multimedia.org) to stop doing things separately, and work with the Debian Multimedia team. He was also asked to stop building packages which are constantly breaking upgrades from one Debian version to the next. But it seems he prefers doing things alone...
but all the volunteer distros like Debian use unencrypted repos so...
See what I wrote above. This is simply wrong. There's a Release.gpg file which is signed by the FTP masters, and which validates the repository.
1. The bad guys can refuse to tell you about a security update you actually needed, fooling you into thinking you're secure when actually they have an exploit that you were supposed to be updated against but you aren't.
2. The bad guys can trickle you a "bad" update that's been superseded, making your security worse. This is a genuine update, made by (in this case) Debian, but which happened to have some bug in it that you'd rather not have. Real repos may have held this update only for a few hours at some point, or even only on some testing server and not on their main repo at all, but if they're signed then you'll never know once the bad guy repo lies to you about how you ought to download the update.
Please don't spread such non-sense. This can't happen, unless the user choose to dismiss the warnings that apt is shouting...
If the individual packages in the repository are signed but the repository as a whole is not[...]
man apt-key...
I think here, you are mistaking Debian with RedHat... Packages are signed individually by their maintainer. But that is used only to validate an upload to the Debian repository. What is in use by Debian users, unlike on a RPM based system, is the Release.gpg file, which is the signature for the repository. This, in the official Debian repositories, is signed by the FTP masters (and the key used to sign the repository is signed by multiple Debian Developer, all in the web of trust).
It's not the role of Debian to back-hack the cruft of a sysadmin. If a sysadmin decided to add a non-official repository, it's his responsibility to maintain it. If the non-official repository goes away this way, Debian isn't to blame.
The Debian community is in fact very concerned by it, but there's very little that we can do. Intrusively hacking the sources.list isn't a nice thing to do. The one to blame is the old owner of debian-multimedia.org, not Debian itself. debian-multimedia.org (and deb-multimedia.org by the way) was non-official anyway, and not supported (and in fact, disliked by the Debian Multimedia team (notice the space instead of the dash...)).
I would have say that 8 months ago. Now, with the latest release (code name Grizzly, version 2013.1.x), we are up to a very good level, with quantum finally working correctly. For storage, I would suggest Ceph rather than Swift + Cinder.
Thomas
As for users managing switches, I have no clue and good luck there. IMHO, I would VLAN and let OpenStack manage it.
VLAN used to be the common solution for networking with OpenStack. Though there are major drawbacks with that (limitation in the number of VLAN, hardware needs to support it, etc.), so these days, mostly everyone (me included) prefer the GRE tunnel solution.
The recent consensus on how much we are contributing range from 80% to 120% due primarily to GHGs.
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.
And the result of the survey of the current science (not people) show almost all of them agree that we are causing the change.
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.
and the conclusions so far are that humans cause a lot of CO2 to get dumped into the atmosphere and that causes the temperature to warm.
But the question is: by how much is it caused by humans. And that's a very difficult question to answer.
Still don't believe it is a problem? Let's ask the tropical coral, the ones still alive because the oceans are becoming more acidic due to increased CO2 in the atmosphere.
Yes, the acidic waters are a big problem which should be addressed. Yet I fail to see how this is related to temperatures.
I wonder who put all that CO2 in the atmosphere. Maybe you could get back to us on that?
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.
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.
I can imagine, that in some cases this scenario happen, but it would be rare.
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.
There will be far more likely a security problem in the application itself.
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).
It really doesn't matter that much. Many developers write their software, test it and release it. They don't test it again when a new version of library appears (it costs them money). If the developer has more applications to maintain and the user base isn't big enough (many small but great application fall in this category) and compatibility problem appears, it could stay unfixed for long time, even forever. I'm talking from my own experiences - not making things up.
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.
I understand your skepticism, but this makes it far easier for both app store managers AND developers who want to do an end-run around Canonical by offering direct downloads. Its the independant developers and users who win... and if the app developers want to make a buck who are Canonical to stop them?
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.
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.
Actually, the "shitload of bloat duplicate binaries" is quite good. Nobody gives a damn about 10 MB of their disk space because the program takes it's libraries with it.
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.
However, everyone gives ten tones of damn when they can't install new application because of "dependency problem".
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.
Solving dependency problems costs time and hence money.
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).
Disk space is cheap.
But phone flash are usually very slow.
Disclaimer: I'm not saying, that new Ubuntu does that, I'm just arguing against the philosophy of bad duplicate binaries.
This makes a lot of sense and I hope it catches on with app developers.
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.
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.
Slashdot Mirror
Reducing what happened with Christian Marillat to only a single thread is deceptive. The issue with his repository breaking upgrades from one version of Debian to the next, and his constant refusal to work within Debian (even though he is a Debian Developer) is all but new.
The more popular the package is the better and more arcane the reasoning is the better, hence why Debian has iceweasel while virtually ever single other linux distro has Firefox.
I didn't comment the rest of, because that's silly enough, so I'll comment only that one. The problem with Firefox vs Iceweasel is located at the Mozilla foundation, which refuses that someone uses the name Firefox (and it's logo) if patches are added. Other distributions might just ignore that fact, but Debian cares about licenses and trademarks. If you want this to change, then you are welcome to ask Mozilla to change its trademark policy.
break something that's working well.
This is only your view, but not the one of the Debian Multimedia team within Debian. In many ways, d-m.o broke upgrades, disrespecting the version numbers and such.
They could easily uphold trademark by licensing the name to d-m.o.
And by that, supporting a website which provides packages that breaks upgrades in Debian? Thanks but no thanks.
They pointlessly demanded that he stop using debian in his domain name which achieved nothing.
Not what happened. We asked Christian Marilla (the old owner of debian-multimedia.org) to stop doing things separately, and work with the Debian Multimedia team. He was also asked to stop building packages which are constantly breaking upgrades from one Debian version to the next. But it seems he prefers doing things alone...
Since apt doesn't validate that the domain is held by a trusted source/known private key before accepting it
Stop the non-sense, and read the man page for apt-key and how the Release.gpg file works.
but all the volunteer distros like Debian use unencrypted repos so...
See what I wrote above. This is simply wrong. There's a Release.gpg file which is signed by the FTP masters, and which validates the repository.
1. The bad guys can refuse to tell you about a security update you actually needed, fooling you into thinking you're secure when actually they have an exploit that you were supposed to be updated against but you aren't. 2. The bad guys can trickle you a "bad" update that's been superseded, making your security worse. This is a genuine update, made by (in this case) Debian, but which happened to have some bug in it that you'd rather not have. Real repos may have held this update only for a few hours at some point, or even only on some testing server and not on their main repo at all, but if they're signed then you'll never know once the bad guy repo lies to you about how you ought to download the update.
Please don't spread such non-sense. This can't happen, unless the user choose to dismiss the warnings that apt is shouting...
If the individual packages in the repository are signed but the repository as a whole is not[...]
man apt-key ...
... Packages are signed individually by their maintainer. But that is used only to validate an upload to the Debian repository. What is in use by Debian users, unlike on a RPM based system, is the Release.gpg file, which is the signature for the repository. This, in the official Debian repositories, is signed by the FTP masters (and the key used to sign the repository is signed by multiple Debian Developer, all in the web of trust).
I think here, you are mistaking Debian with RedHat
It's not the role of Debian to back-hack the cruft of a sysadmin. If a sysadmin decided to add a non-official repository, it's his responsibility to maintain it. If the non-official repository goes away this way, Debian isn't to blame.
The Debian community is in fact very concerned by it, but there's very little that we can do. Intrusively hacking the sources.list isn't a nice thing to do. The one to blame is the old owner of debian-multimedia.org, not Debian itself. debian-multimedia.org (and deb-multimedia.org by the way) was non-official anyway, and not supported (and in fact, disliked by the Debian Multimedia team (notice the space instead of the dash...)).
(a) Why is that? Why can't package management fix a security problem?
For this, we have apt-key. If you blindly trust a non-signed source, that's your fault.
Others (like getting something as basic as sound to work reliably), I consider a major shortcoming.
How many centuries ago did you last try Linux? If there's something that works these days, it really is sound.
OpenStack is new, but still relatively immature.
I would have say that 8 months ago. Now, with the latest release (code name Grizzly, version 2013.1.x), we are up to a very good level, with quantum finally working correctly. For storage, I would suggest Ceph rather than Swift + Cinder. Thomas
As for users managing switches, I have no clue and good luck there. IMHO, I would VLAN and let OpenStack manage it.
VLAN used to be the common solution for networking with OpenStack. Though there are major drawbacks with that (limitation in the number of VLAN, hardware needs to support it, etc.), so these days, mostly everyone (me included) prefer the GRE tunnel solution.
The recent consensus on how much we are contributing range from 80% to 120% due primarily to GHGs.
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.
And the result of the survey of the current science (not people) show almost all of them agree that we are causing the change.
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.
and the conclusions so far are that humans cause a lot of CO2 to get dumped into the atmosphere and that causes the temperature to warm.
But the question is: by how much is it caused by humans. And that's a very difficult question to answer.
Still don't believe it is a problem? Let's ask the tropical coral, the ones still alive because the oceans are becoming more acidic due to increased CO2 in the atmosphere.
Yes, the acidic waters are a big problem which should be addressed. Yet I fail to see how this is related to temperatures.
I wonder who put all that CO2 in the atmosphere. Maybe you could get back to us on that?
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.
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.
I can imagine, that in some cases this scenario happen, but it would be rare.
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.
There will be far more likely a security problem in the application itself.
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).
It really doesn't matter that much. Many developers write their software, test it and release it. They don't test it again when a new version of library appears (it costs them money). If the developer has more applications to maintain and the user base isn't big enough (many small but great application fall in this category) and compatibility problem appears, it could stay unfixed for long time, even forever. I'm talking from my own experiences - not making things up.
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.
I understand your skepticism, but this makes it far easier for both app store managers AND developers who want to do an end-run around Canonical by offering direct downloads. Its the independant developers and users who win... and if the app developers want to make a buck who are Canonical to stop them?
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.
Actually, the "shitload of bloat duplicate binaries" is quite good. Nobody gives a damn about 10 MB of their disk space because the program takes it's libraries with it.
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.
However, everyone gives ten tones of damn when they can't install new application because of "dependency problem".
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.
Solving dependency problems costs time and hence money.
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).
Disk space is cheap.
But phone flash are usually very slow.
Disclaimer: I'm not saying, that new Ubuntu does that, I'm just arguing against the philosophy of bad duplicate binaries.
You are arguing very poorly, IMO.
This makes a lot of sense and I hope it catches on with app developers.
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.
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.