The other way of looking at it are that the ISO is naturally really, really slow and these appeals are the appropriate first step in showing that there was a problem.
Sure, you can talk about assigning a value to your time - but make sure you're doing it accurately.
Finding a good source for high quality downloads of the type you're looking for (music, movies, whatever) probably takes an hour or two at the absolute most. Once you've done that, you get unlimited downloads for free (search & click with less hassle than your average store interface).
If you're a music fan, it doesn't take that many albums for the pirate site to be a strictly better deal *even considering the time investment* - unless you're Donald Trump or something. Then you should have your personal assistant do it.
I've got 30minutes to chill and play a game, just work for fucks sake.
If you're gaming time comes in 30 minute blocks, consoles are just as useless to you as a gaming PC would be. You'll do just fine with any old computer by navigating your web browser to crappyjavagames.com or whatever - that's pretty much all you have time for.
On the other hand, pretty much any comments that anyone outside Red Hat about possible future business decisions would necessarily involve a number of pretty big assumptions - and that includes Wieers' article.
Just like Wieers mentions, one of the key problems is new driver support for already-released distro versions. That means a frozen kernel version, which means that any new drivers are backports. If the major distro vendors standardize on specific release kernels, that would mean that upstream can maintain one "stable-for-backports" kernel version.
You seem to be assuming that having a consistent kernel version only matters for binary drivers. That's false. Only having to test against one kernel version is also valuable for vendors developing F/OSS drivers.
That might very well increase vendor cooperation - even to a sufficient extent that Red Hat would get better hardware support than they have now with less investment.
If coordinated releases made "supporting Linux" easier for hardware vendors, Red Hat would be able to support more hardware with no special effort on their part. Red Hat, like every other distro developer, is much better off pulling functionality automatically from upstream than committing a bunch of resources to providing that functionality themselves.
Shhh Stallman real world people are talking here. Not all companies are going to publish open source drivers.
Stop trying to be cool by ripping on Stallman. It just makes you look like an idiot.
There's no practical reason for Linus or any of the distributors to take any action that actively supports binary drivers. That'd just get everyone into the mess that Microsoft has with Windows - where vendors release drivers for some weird OS version and never update them because they weren't interested in supporting their hardware to begin with.
There are major vendors of every type of hardware who are already releasing specs or F/OSS drivers. Anyone who isn't is just lagging behind. There's no reason not to just let the market force them into line. When I say "the market", I mean "Dell, HP, and Lenovo" who have publicly announced that they will favor hardware with in-kernel (= F/OSS) Linux support.
Yes. Shuttleworth would benefit from synchronized releases. If there wasn't some advantage for his project, he wouldn't have suggested it. What he's suggesting is that everyone else would benefit too.
Sure, Red Hat puts a lot of effort into hardware support backports. But if Ubuntu, Debian, Novel and Red Hat all standardized on the same kernel releases for their six-month release cycles then hardware vendors would have one platform to target instead of four. That might very well increase vendor cooperation - even to a sufficient extent that Red Hat would get better hardware support than they have now with less investment.
I mean, if you're going to write code that basically looks like a duck, walks like a duck and quacks like a duck, and which you know is going to head downstream toward a huge bunch of duck-hunters, it's really a good idea to add a big visible note saying THIS IS NOT A DUCK.
If the Debian developer had submitted the patch upstream, that would have been the whole story. A couple people would have had to regenerate keys for their debian unstable boxes, and the OpenSSL developers would have had a good laugh at the Debian guy screwing up.
The fact that this was in stable for 2 years makes this completely different. The Debian packager and the Debian security team both screwed up royally - the latter perhaps simply by having a poor security-critical patch policy.
Nothing should ever depend on the value of uninitialized memory
Great heuristic. Like any such rule of thumb though, there are occasional times when it doesn't apply. It's easy to argue that this is one of them. Adding arbitrary system-dependent data to an XOR / Hash managed random pool has no negative security effects (even if the attacker controls the arbitrary data - this can be proven mathematically), costs no computation time, and potentially provides a security benefit (making any PRNG explot platform dependent).
The packager absolutely should have challenged the OpenSSH developers over this - and even submitted a patch to fix it - but you don't go making random "clean ups" to secure code that you're about to ship out to millions of users unless you are 100% sure you know what you're doing.
I was wondering, as soon as I read the GP, what you do if a system doesn't have/dev/random?
What relevant modern operating system doesn't support/dev/random these days? I know Solaris didn't used to, but it seems wildly unlikely that they haven't fixed that yet.
The best response to that is probably to engage in conversation and ask for details - that way the discussion thread can be made to contain more depth, which will allow the people reading it to have more understanding.
I already said it in this story, but the greatest trick every played on the American people is convincing them that they government is the way it is because they want it to be that way.
As an American, I absolutely agree.
But "we're not perfect, therefore we can't criticize anyone else" is an invalid argument. Any government that violates human rights deserves criticism.
Shouldn't we give credit where it's due, instead of beating a dead horse?
Complaining about active and/or recent human rights violations will never be "beating a dead horse". Some issues get old and boring - this one never does.
That's not to say that we shouldn't give the Chinese government full credit for effective disaster response, probably with a reference to how much better they did than the US did for Hurricane Katrina. But just because they did a good job at one thing today doesn't magically mean that something bad they've been doing for years has gone away.
It is also not appropriate to rally against your dictator, military junta or totalitarian government for a limited period when they are using all their resources for combating a genuine emergency.
That's absurd. Not only is it time to rally against a totalitarian government, it may be the perfect time to start an active rebellion. Any government that is repressing its populace is implicitly asking to be overthrown - when to do it is simply a question of tactics, and "when they're distracted" tends to be a good tactical choice.
C'mon, guys, people are dying there and please, have a heart, wilya ??
People dying somehow make human rights stop being an issue?
If that's what you think, you're absolutely wrong. Human rights don't stop mattering because people die. They don't stop mattering if an earthquake hits. Or for a terrorist attack. Or even in an active war zone.
In this case, the news is good - China's notoriously problematic censorship system hasn't noticeably hurt people's ability to communicate vital information during a natural disaster. For many people, that means that China is measurably less repressive than they had feared. This fact is a perfectly valid topic for discussion in this thread.
The emotional link and the strength of my hopes and dreams for my kid would be the reasons my own baby would be more important to me than my own dog.
This, by itself, is enough to justify treating infants with mothers as people from a legal perspective. If the legal system didn't value emotional damage, then rape with a condom would simply be "battery".
Yes, but it would logically be the same kind of murder as if you killed my dog.
We should absolutely be using logic to analyze legal questions, but when you make statements like that with oversimplified logic you make it look like anyone who values rationality is a psychopath (which is absurd - psychopath make irrational decisions all the time).
Slashdot Mirror
Simple heuristic: If it produces a ballot that goes in a ballot box, it's good. Otherwise, it's trash.
This isn't the whole story, but it's a good enough approximation that your case isn't the exception.
Have you read any other free software licenses?
Check out the Apache license. Or maybe the IBM Public License, if the Apache foundation are too anti-commercial for your tastes.
That's one way of looking at it.
The other way of looking at it are that the ISO is naturally really, really slow and these appeals are the appropriate first step in showing that there was a problem.
Sure, you can talk about assigning a value to your time - but make sure you're doing it accurately.
Finding a good source for high quality downloads of the type you're looking for (music, movies, whatever) probably takes an hour or two at the absolute most. Once you've done that, you get unlimited downloads for free (search & click with less hassle than your average store interface).
If you're a music fan, it doesn't take that many albums for the pirate site to be a strictly better deal *even considering the time investment* - unless you're Donald Trump or something. Then you should have your personal assistant do it.
Or you pay current market value, 0 cents, and download the whole album in a lossless format.
So... you've identified a required feature for the phone you buy. That doesn't mean that you can't buy whatever phone you want that has that feature.
If you're gaming time comes in 30 minute blocks, consoles are just as useless to you as a gaming PC would be. You'll do just fine with any old computer by navigating your web browser to crappyjavagames.com or whatever - that's pretty much all you have time for.
No. You're getting modded up due to the "there are too many Linux distros" groupthink (that you're completely participating in).
True enough.
On the other hand, pretty much any comments that anyone outside Red Hat about possible future business decisions would necessarily involve a number of pretty big assumptions - and that includes Wieers' article.
Just like Wieers mentions, one of the key problems is new driver support for already-released distro versions. That means a frozen kernel version, which means that any new drivers are backports. If the major distro vendors standardize on specific release kernels, that would mean that upstream can maintain one "stable-for-backports" kernel version.
You seem to be assuming that having a consistent kernel version only matters for binary drivers. That's false. Only having to test against one kernel version is also valuable for vendors developing F/OSS drivers.
Like I said in my initial post:
If coordinated releases made "supporting Linux" easier for hardware vendors, Red Hat would be able to support more hardware with no special effort on their part. Red Hat, like every other distro developer, is much better off pulling functionality automatically from upstream than committing a bunch of resources to providing that functionality themselves.
Stop trying to be cool by ripping on Stallman. It just makes you look like an idiot.
There's no practical reason for Linus or any of the distributors to take any action that actively supports binary drivers. That'd just get everyone into the mess that Microsoft has with Windows - where vendors release drivers for some weird OS version and never update them because they weren't interested in supporting their hardware to begin with.
There are major vendors of every type of hardware who are already releasing specs or F/OSS drivers. Anyone who isn't is just lagging behind. There's no reason not to just let the market force them into line. When I say "the market", I mean "Dell, HP, and Lenovo" who have publicly announced that they will favor hardware with in-kernel (= F/OSS) Linux support.
Yes. Shuttleworth would benefit from synchronized releases. If there wasn't some advantage for his project, he wouldn't have suggested it. What he's suggesting is that everyone else would benefit too.
Sure, Red Hat puts a lot of effort into hardware support backports. But if Ubuntu, Debian, Novel and Red Hat all standardized on the same kernel releases for their six-month release cycles then hardware vendors would have one platform to target instead of four. That might very well increase vendor cooperation - even to a sufficient extent that Red Hat would get better hardware support than they have now with less investment.
If the Debian developer had submitted the patch upstream, that would have been the whole story. A couple people would have had to regenerate keys for their debian unstable boxes, and the OpenSSL developers would have had a good laugh at the Debian guy screwing up.
The fact that this was in stable for 2 years makes this completely different. The Debian packager and the Debian security team both screwed up royally - the latter perhaps simply by having a poor security-critical patch policy.
Great heuristic. Like any such rule of thumb though, there are occasional times when it doesn't apply. It's easy to argue that this is one of them. Adding arbitrary system-dependent data to an XOR / Hash managed random pool has no negative security effects (even if the attacker controls the arbitrary data - this can be proven mathematically), costs no computation time, and potentially provides a security benefit (making any PRNG explot platform dependent).
Wow. You're so wrong it isn't even funny.
The packager absolutely should have challenged the OpenSSH developers over this - and even submitted a patch to fix it - but you don't go making random "clean ups" to secure code that you're about to ship out to millions of users unless you are 100% sure you know what you're doing.
What relevant modern operating system doesn't support /dev/random these days? I know Solaris didn't used to, but it seems wildly unlikely that they haven't fixed that yet.
Excellent point.
The best response to that is probably to engage in conversation and ask for details - that way the discussion thread can be made to contain more depth, which will allow the people reading it to have more understanding.
As an American, I absolutely agree.
But "we're not perfect, therefore we can't criticize anyone else" is an invalid argument. Any government that violates human rights deserves criticism.
I vehemently disagree. It's always the time to make a stand for political freedoms and human rights.
If there were ever a circumstance (say, war) that would make it "not the time", tyrants would make damn sure that that circumstance were always true.
Complaining about active and/or recent human rights violations will never be "beating a dead horse". Some issues get old and boring - this one never does.
That's not to say that we shouldn't give the Chinese government full credit for effective disaster response, probably with a reference to how much better they did than the US did for Hurricane Katrina. But just because they did a good job at one thing today doesn't magically mean that something bad they've been doing for years has gone away.
That's absurd. Not only is it time to rally against a totalitarian government, it may be the perfect time to start an active rebellion. Any government that is repressing its populace is implicitly asking to be overthrown - when to do it is simply a question of tactics, and "when they're distracted" tends to be a good tactical choice.
People dying somehow make human rights stop being an issue?
If that's what you think, you're absolutely wrong. Human rights don't stop mattering because people die. They don't stop mattering if an earthquake hits. Or for a terrorist attack. Or even in an active war zone.
In this case, the news is good - China's notoriously problematic censorship system hasn't noticeably hurt people's ability to communicate vital information during a natural disaster. For many people, that means that China is measurably less repressive than they had feared. This fact is a perfectly valid topic for discussion in this thread.
This, by itself, is enough to justify treating infants with mothers as people from a legal perspective. If the legal system didn't value emotional damage, then rape with a condom would simply be "battery".
We should absolutely be using logic to analyze legal questions, but when you make statements like that with oversimplified logic you make it look like anyone who values rationality is a psychopath (which is absurd - psychopath make irrational decisions all the time).