Since Ubuntu is based on Debian, its success is contingent upon that of Debian. Ubuntu isn't a fork from Debian; according to one of the other responders, they pull new changes up from Debian every 6 months. According to Netcraft, Debian is the fastest growing distro:
Is the "having a good patch or two ignored" statement from personal experience? I've never submitted anything to them, so I have no experience to compare it to... but it seems to me that you don't need a priority to be assigned to a bug for a patch to be created, submitted, and approved.
I'm sure if someone submits a good patch for any of said "large, obvious, and reviled" bugs, they'll get fixed. I seriously doubt that the Firefox team is would the reparation of any bugs for which a good patch is submitted. However, I don't think you can expect them to always make every important bug a priority.
This story is about security; obviously, bugs that pose security threats are of primary importance. Security bugs could inhibit the growth, yes. But you can't blame module owners for choosing certain bugs over others; for most open source contributors, the work they do is voluntary and they can't do everything themselves. They must choose to respond to certain bugs and not to others. Since the comment is about Microsoft's security patching procedures as compared to Mozilla's, that's what we should consider. The information is out there, in the open; if the FF team shirked the duty of fixing security related bugs, the project would flop.
So, what of the non security related bugs? If something is truly so annoying to a great majority of users, someone needs to step up and fix it. As an end user, I don't encounter any bugs that annoy me to the degree about which you speak. If I do find a bug, I submit a bug report; if enough people are annoyed by a certain thing, it will become a priority. I don't give any credence to the "too blinded by their own glory to care about us" theory. I'm sure they are all doing what they believe is right, using what time they have. If you think something else should be done, you can step up and do it.
Ouch - that's annoying. I've never used ShipIt, since I can just download and burn faster than they could ship. In terms of time, that's less of a hassle to me.
This article was posted a little while ago about a user who used Ubuntu in a completly MS environment without his boss noticing for a few months. (linked article from the story)
My experience with it is that it's one of the most mature Desktop distributions, coming complete with most of the tools one would need to perform most jobs. Easy install, and you can use Syntaptic/apt-get for upgrades and additional installation since it's Debian based. You should check it out.
Only 179 bugs. Sure, those are only the ones that the Mozilla team deem necessary to work on; however, we've seen from their reactions with 1.06 -> 1.07 that they are very quick on figuring out what's important and patching it quickly. Sure, that's a lot of unpatched bugs. But: that list is publicly available. Any researcher can go in and say, "hmmm.... let's find the security flaws that Mozilla has left unpatched". And they do, trust me; the thing is, the Firefox team patches the bugs that cause security flaws. Other ones are cosmetic, user interaction, or feature-based in nature. They still appear as "bugs", even though they don't pose a security threat.
The issue is not that OSS has no bugs - that's an obvious farce. The issue is that Microsoft first misdiagnosed a critical bug, and then left it unpatched for 6 months and counting. The Firefox team consistently finds those bugs that do pose a threat, and they leave the work they do open and transparent so that security researcheres can check up on what happens. Microsoft - let's put it thise way: if security researchers never found the flaws in Microsoft's programs, Microsoft would save money and increase efficiency by not fixing them.
Check out the latest changelog on kernel.org. In it you'll find names for patch authors and commiters, as well as a description of every change made to the kernel.
Obviously, not every piece of software included with your generic GNU/Linux distribution will provide such detailed information. But, we're talking about an embedded system - far less software is required when compared to a "generic" distrobution. For embedded systems, a paper trail like this is easy.
be felt by an amputee as the lost natural limb delivering her/him a natural sensory feedback by means of the stimulation of some specific afferent nerves;
be controlled in a very natural way by processing the efferent neural signals coming from the central nervous system (reducing the discomfort of the current EMG-based control prosthesis);
Windows administrators are forced to wait until Windows releases a patch for known vulnerabilities to upgrade their systems. Why, then, were the Linux administrators told to attempt to upgrade their systems before Novell had released newly packaged versions of MySQL? The entire point of a package management system is that administrators rely on companies like Novell to correct dependencies prior to deployment. Since Windows administrators have the same constraint (i.e., waiting for security updates to be released), it is an unfair and arbitrary difference that caused a lot of troubles.
Why did you compare the number of patches required to apply between the systems? This is not a measure of security. Windows patches are bundled and affect many parts of the operating system while Linux patches affect individual components. The overtone in your paper implied that fewer windows patches was in some way easier or more secure; what justification do you have for this assertation?
While kernel patches did not require an immediate reboot during installation, the majority of them need a system restart to immunize the system against a specific vulnerability.
-Page 25, under "Patching and Milestone Upgrades"
What is the rationale behind this? Were the Linux administrators required to restart at this point? This is an incredibly contrived situation; one can simply stop and re-start the process in question after the upgrade has completed.
Furthermore, the upgrade methodology questionable. Real companies use development and production servers and don't upgrade the production server until a reproduceable upgrade trajectory has been tested on the development server. The actions of these administrators imply that they had no such access, and that there was no possibility for backtracking or restarting after a failed step. Normally, one would expect the ability to nuke the development server and start over, rather than following a bad plan to worse conclusions.
Refer to this comment. If you believe the poster is who he says he is (a non-American seeking a math/science PhD from a US college), you can accept his synopsis: the "dumb PhD" problem is only worse in Asia.
4,400 mathematics and science PhDs each year compared with 24,900 math and science PhDs for greater Asia
Perhaps you should compare the base population of "greater Asia" to the base population of the US... then the figure would seem incredibly skewed towards the US.
If the money is considered stolen property, it will still be illegal for him to possess it once he gets out of jail. So, if they are able to link him to any unaccounted for source of income, he'll probably do more time.
There is a real lack of quality teachers in the public school system. Many of them are just there because quitting now would mean losing their retirement, not because they love teaching or because they are good at it.
That phrase does have a lot of people who are governed by it, but it's not the rule. My father is one of the best teachers I know. Teaching is a passion and an art for him. He works at a private school - right away, that's a pay cut (public school teachers get paid much, much more for less experience). He moved from being an administrator to a highschool teacher because he wanted more direct interaction with the kids' development - yet another pay cut.
Too many teachers are doing it because they "can't" - but it's certainly true that some people are better at explaining complicated concepts than otheres.
I'd say that some cases of Open Source on Windows are genuinely good, and others aren't so much. When it's open source that can run on Windows, I say "yay!". When it's open source that requires Windows, I balk.
Part of the philosophy is to put choice into the hands of each individual. I give a lot more credence to OSS that can run on multiple platforms. Sure, you can run.NET projects on Mono or the like - but that's a hoop you have to jump through. You can't be truly confident in the success you'll have, either.
When a project requires you to use closed source software to ensure its functioning, it's virility as an open source program is questionable. Sure, the source is available - but it's dependant on something that is closed. There's no guarantee that the framework upon which it is built won't change, and if it does change then what? Open source programs that are built upon closed source interfaces and systems can do nothing but hope that the next version of said closed source program will continue functioning the way its previous versions have. And they're given no guarantee whatsoever.
I still think it's great that projects like DotNetNuke release their stuff as open source. I just wonder why - why do they choose to build it upon something closed source? It's not as if.NET is intrinsically better than other development options. I mean, DotNetNuke is written in VB.NET - even if I were to develop in.NET, this wouldn't be my first choice. Regardless, I'd be hesitant to choose something that is so heavily tied to a closed source system.
I guess may language was a little unclear. What I meant to say was that that article gave no indication that a backdoor had been found, not that it implied no backdoor existed. Of course, that's what happens when you submit without proofreading.
Hopefully some legislation will send DRM methods like this into illegal-ville. We'll see... until then, I'm certainly not putting new CDs anywhere near a windows installation.
You're confusing the terms "rootkit" and "trojan"/"backdoor".
A trojan in its strictest sense tricks a user into executing one set of code when they think they're executing another. A backdoor simply allows remote execution of arbitrary code.
A rootkit is usually the set of tools that an attacker deploys on a compromised system. "rootkits" in the terms of this article are programs that trick your kernel into doing things it shouldn't do. This could include a trojan or a backdoor, but not necessarily.
Sony's program is a rootkit because it runs without authorization from the CD and alters the Windows API in order to disguise itself. As far as the article indicates, it doesn't include the ability for Sony to execute code on your machine. It's still dirty and sinister, if you ask me. It also allows any other malicious attackers to conceal anything they plant on your machine - simply by prefixing any file name with $sys$ - that's not cool!
I've been forced to restart a visual studio crash more than twice a day this week. I'd much prefer if they merely allowed me to crash it, when I felt like it.
I can't wait until I return to my normal job, programming in a real IDE that doesn't freeze so often.
I'm doing a 6 month internship right now. I'll net $17,000. If it was only a summer thing, I'd be getting around $9,800. This is in addition to full benefits, and up to 7% of my pay matched when I purchase stock. Honestly, this isn't even with a tech company; they just pay IT interns really well.
Let's apply this to something truly deserving of a class-action lawsuit:
"The amount and durability of the [security patches] applied as [...] protective [measures] during the [Internet Explorer and Microsoft Windows lifecycles are] clearly defective in that [they are] not sufficient to adequately protect the [end user's computer, resulting in exploitation] and ultimately irreparable damage," the lawsuit says.
neither "the ends justify the means" nor "all's well that ends well" are sufficient ethical justifications
Those statements are equivalent in meaning, so it doesn't make sense to set them as opposites with a "neither-nor" comparison. They both imply that the consequences of an action tell the entire ethical story.
As far as I can see, ethical actions are covered by three areas:
Intention
What is the motivation behind this action?
This accounts for many situational problems; for example, killing someone can be justified if the intention was self defense.
Action
Is this action intrinsically reprehensible from a moral standpoint?
This is probably one of the most controversial tests, because it requires a standard by which to judge actions. Not everyone agrees on such a standard; in defense of this however, I suggest that most people would agree that pedophilia is morally wrong in any scenario, regardless of the intention or the results.
Consequences
What are the direct results of this action?
This must, of course, be taken into consideration hand-in-hand with the Intentions. Negligent death can be derived from such a combination: no ill will towards the victim, but when a death is foreseeable, one has acted negligently.
Foreseeability is not a hard and fast rule to which I would adhere. To clarify: actions whose bad consequences were foreseeable are often bad, but this does not imply that actions whose bad consequences were not foreseeable are necessarily good.
Of course, this system could use more flushing out.
That depends on the sort of watermarking we're talking about.
If it can be detected in a ripped version of the movie, it's obviously not something intrinsic to the DVD (but rather to the video on that DVD). In this case, there's the possibility that the watermark only affects a certain timeframe in an identifiable pattern. Say, if we identify the watermark at every 15 second mark, the copy belonged to Joe. At every 25 second mark, it was Jim's. If you combine them, you find both marks and can conclude that Joe and Jim got together and screwed with the system. Obviously, things could be chopped up differently to allow for more than 60 unique copies, if needed.
All that to say, your technique would only work if the watermark is something that is constant throughout the movie. Their "watermark" could be as simple as whether or not an extra second of a certain scene was left in.
I never seem to run into this problem. I have one password, with roughly four levels of complexity. Each version has the same meaning, and as such they're all easy to remember. Which one I use depends on the criticality of the resource it protects, but no matter which one it is, I'm never more than 3 tries away.
Now, when there are policies in effect that enforce password changing and prohibit reuse of old passwords, this presents a problem: it's hard to continue generating new obfustications of the same phrase.
Slashdot Mirror
Since Ubuntu is based on Debian, its success is contingent upon that of Debian. Ubuntu isn't a fork from Debian; according to one of the other responders, they pull new changes up from Debian every 6 months. According to Netcraft, Debian is the fastest growing distro:
http://news.netcraft.com/archives/2005/12/05/stron g_growth_for_debian.html
One can assume that Ubuntu, et al. are included in this statistic.
Here's a great example of some "sweet" trademarkage: the color brown
D'oh.
Is the "having a good patch or two ignored" statement from personal experience? I've never submitted anything to them, so I have no experience to compare it to... but it seems to me that you don't need a priority to be assigned to a bug for a patch to be created, submitted, and approved.
I'm sure if someone submits a good patch for any of said "large, obvious, and reviled" bugs, they'll get fixed. I seriously doubt that the Firefox team is would the reparation of any bugs for which a good patch is submitted. However, I don't think you can expect them to always make every important bug a priority.
This story is about security; obviously, bugs that pose security threats are of primary importance. Security bugs could inhibit the growth, yes. But you can't blame module owners for choosing certain bugs over others; for most open source contributors, the work they do is voluntary and they can't do everything themselves. They must choose to respond to certain bugs and not to others. Since the comment is about Microsoft's security patching procedures as compared to Mozilla's, that's what we should consider. The information is out there, in the open; if the FF team shirked the duty of fixing security related bugs, the project would flop.
So, what of the non security related bugs? If something is truly so annoying to a great majority of users, someone needs to step up and fix it. As an end user, I don't encounter any bugs that annoy me to the degree about which you speak. If I do find a bug, I submit a bug report; if enough people are annoyed by a certain thing, it will become a priority. I don't give any credence to the "too blinded by their own glory to care about us" theory. I'm sure they are all doing what they believe is right, using what time they have. If you think something else should be done, you can step up and do it.
Ouch - that's annoying. I've never used ShipIt, since I can just download and burn faster than they could ship. In terms of time, that's less of a hassle to me.
This article was posted a little while ago about a user who used Ubuntu in a completly MS environment without his boss noticing for a few months. (linked article from the story)
My experience with it is that it's one of the most mature Desktop distributions, coming complete with most of the tools one would need to perform most jobs. Easy install, and you can use Syntaptic/apt-get for upgrades and additional installation since it's Debian based. You should check it out.
Note the vast majority of "bugs" in bugzilla that are labeled "enh" --> those ones are enhancements that users would like to see.
Instead of counting against Mozilla, the fact that they allow so much user input is a great OSS feature.
No one said OSS was free of bugs. Since end users are allowed to submit bugs, the only ones that should be counted are those that are confirmed.
Try the following list: bugs that are in Firefox, not marked "enh", and have an action priority (P1-P5). (note: copy/paste link since bugzilla refuses connectiosn referred by /.)
Only 179 bugs. Sure, those are only the ones that the Mozilla team deem necessary to work on; however, we've seen from their reactions with 1.06 -> 1.07 that they are very quick on figuring out what's important and patching it quickly. Sure, that's a lot of unpatched bugs. But: that list is publicly available. Any researcher can go in and say, "hmmm.... let's find the security flaws that Mozilla has left unpatched". And they do, trust me; the thing is, the Firefox team patches the bugs that cause security flaws. Other ones are cosmetic, user interaction, or feature-based in nature. They still appear as "bugs", even though they don't pose a security threat.
The issue is not that OSS has no bugs - that's an obvious farce. The issue is that Microsoft first misdiagnosed a critical bug, and then left it unpatched for 6 months and counting. The Firefox team consistently finds those bugs that do pose a threat, and they leave the work they do open and transparent so that security researcheres can check up on what happens. Microsoft - let's put it thise way: if security researchers never found the flaws in Microsoft's programs, Microsoft would save money and increase efficiency by not fixing them.
Check out the latest changelog on kernel.org. In it you'll find names for patch authors and commiters, as well as a description of every change made to the kernel.
Obviously, not every piece of software included with your generic GNU/Linux distribution will provide such detailed information. But, we're talking about an embedded system - far less software is required when compared to a "generic" distrobution. For embedded systems, a paper trail like this is easy.
From the website:
Windows administrators are forced to wait until Windows releases a patch for known vulnerabilities to upgrade their systems. Why, then, were the Linux administrators told to attempt to upgrade their systems before Novell had released newly packaged versions of MySQL? The entire point of a package management system is that administrators rely on companies like Novell to correct dependencies prior to deployment. Since Windows administrators have the same constraint (i.e., waiting for security updates to be released), it is an unfair and arbitrary difference that caused a lot of troubles.
Why did you compare the number of patches required to apply between the systems? This is not a measure of security. Windows patches are bundled and affect many parts of the operating system while Linux patches affect individual components. The overtone in your paper implied that fewer windows patches was in some way easier or more secure; what justification do you have for this assertation?
What is the rationale behind this? Were the Linux administrators required to restart at this point? This is an incredibly contrived situation; one can simply stop and re-start the process in question after the upgrade has completed.
Furthermore, the upgrade methodology questionable. Real companies use development and production servers and don't upgrade the production server until a reproduceable upgrade trajectory has been tested on the development server. The actions of these administrators imply that they had no such access, and that there was no possibility for backtracking or restarting after a failed step. Normally, one would expect the ability to nuke the development server and start over, rather than following a bad plan to worse conclusions.
Oh, they managed to exploit it, albeit indirectly.
Refer to this comment. If you believe the poster is who he says he is (a non-American seeking a math/science PhD from a US college), you can accept his synopsis: the "dumb PhD" problem is only worse in Asia.
Perhaps you should compare the base population of "greater Asia" to the base population of the US... then the figure would seem incredibly skewed towards the US.
If the money is considered stolen property, it will still be illegal for him to possess it once he gets out of jail. So, if they are able to link him to any unaccounted for source of income, he'll probably do more time.
But what about those who can do teaching?
There is a real lack of quality teachers in the public school system. Many of them are just there because quitting now would mean losing their retirement, not because they love teaching or because they are good at it.
That phrase does have a lot of people who are governed by it, but it's not the rule. My father is one of the best teachers I know. Teaching is a passion and an art for him. He works at a private school - right away, that's a pay cut (public school teachers get paid much, much more for less experience). He moved from being an administrator to a highschool teacher because he wanted more direct interaction with the kids' development - yet another pay cut.
Too many teachers are doing it because they "can't" - but it's certainly true that some people are better at explaining complicated concepts than otheres.
$0.02
I'd say that some cases of Open Source on Windows are genuinely good, and others aren't so much. When it's open source that can run on Windows, I say "yay!". When it's open source that requires Windows, I balk.
Part of the philosophy is to put choice into the hands of each individual. I give a lot more credence to OSS that can run on multiple platforms. Sure, you can run .NET projects on Mono or the like - but that's a hoop you have to jump through. You can't be truly confident in the success you'll have, either.
When a project requires you to use closed source software to ensure its functioning, it's virility as an open source program is questionable. Sure, the source is available - but it's dependant on something that is closed. There's no guarantee that the framework upon which it is built won't change, and if it does change then what? Open source programs that are built upon closed source interfaces and systems can do nothing but hope that the next version of said closed source program will continue functioning the way its previous versions have. And they're given no guarantee whatsoever.
I still think it's great that projects like DotNetNuke release their stuff as open source. I just wonder why - why do they choose to build it upon something closed source? It's not as if .NET is intrinsically better than other development options. I mean, DotNetNuke is written in VB.NET - even if I were to develop in .NET, this wouldn't be my first choice. Regardless, I'd be hesitant to choose something that is so heavily tied to a closed source system.
I guess may language was a little unclear. What I meant to say was that that article gave no indication that a backdoor had been found, not that it implied no backdoor existed. Of course, that's what happens when you submit without proofreading.
Hopefully some legislation will send DRM methods like this into illegal-ville. We'll see... until then, I'm certainly not putting new CDs anywhere near a windows installation.
You're confusing the terms "rootkit" and "trojan"/"backdoor".
A trojan in its strictest sense tricks a user into executing one set of code when they think they're executing another. A backdoor simply allows remote execution of arbitrary code.
A rootkit is usually the set of tools that an attacker deploys on a compromised system. "rootkits" in the terms of this article are programs that trick your kernel into doing things it shouldn't do. This could include a trojan or a backdoor, but not necessarily.
Sony's program is a rootkit because it runs without authorization from the CD and alters the Windows API in order to disguise itself. As far as the article indicates, it doesn't include the ability for Sony to execute code on your machine. It's still dirty and sinister, if you ask me. It also allows any other malicious attackers to conceal anything they plant on your machine - simply by prefixing any file name with $sys$ - that's not cool!
I've been forced to restart a visual studio crash more than twice a day this week. I'd much prefer if they merely allowed me to crash it, when I felt like it.
I can't wait until I return to my normal job, programming in a real IDE that doesn't freeze so often.
I'm doing a 6 month internship right now. I'll net $17,000. If it was only a summer thing, I'd be getting around $9,800. This is in addition to full benefits, and up to 7% of my pay matched when I purchase stock. Honestly, this isn't even with a tech company; they just pay IT interns really well.
So yes, 9k to 18k for a summer internship.
Let's apply this to something truly deserving of a class-action lawsuit:
does "mrbcs" go to BCS in Washington? if so, hi, I went to your highschool.
Oh, yeah?
Try telling that to SCO.
They seem to be doing just fine running Linux. Hope they don't accidentally involve themselves in their automatic lawsuit machine...
Those statements are equivalent in meaning, so it doesn't make sense to set them as opposites with a "neither-nor" comparison. They both imply that the consequences of an action tell the entire ethical story.
As far as I can see, ethical actions are covered by three areas:
Of course, this system could use more flushing out.
</2 cents>
That depends on the sort of watermarking we're talking about.
If it can be detected in a ripped version of the movie, it's obviously not something intrinsic to the DVD (but rather to the video on that DVD). In this case, there's the possibility that the watermark only affects a certain timeframe in an identifiable pattern. Say, if we identify the watermark at every 15 second mark, the copy belonged to Joe. At every 25 second mark, it was Jim's. If you combine them, you find both marks and can conclude that Joe and Jim got together and screwed with the system. Obviously, things could be chopped up differently to allow for more than 60 unique copies, if needed.
All that to say, your technique would only work if the watermark is something that is constant throughout the movie. Their "watermark" could be as simple as whether or not an extra second of a certain scene was left in.
I never seem to run into this problem. I have one password, with roughly four levels of complexity. Each version has the same meaning, and as such they're all easy to remember. Which one I use depends on the criticality of the resource it protects, but no matter which one it is, I'm never more than 3 tries away.
Now, when there are policies in effect that enforce password changing and prohibit reuse of old passwords, this presents a problem: it's hard to continue generating new obfustications of the same phrase.