which may explain why the iPod Mini has sold out everywhere despite being a relatively-bad deal compared to the 15 GB model.
Entering "microdrive 4gb" in eBay gets me 64 hits. Apple announced that it has over 100,000 pre-orders for the iPod Mini. Even if every single one of those was stripped from an iPod Mini (not likely) and Apple only produced enough to fulfill pre-orders (not likely), that would account for 0.06% of its sales.
Please just accept that your criteria for what makes a good deal may not be shared by... hundreds of thousands of other people.
The "double-blind" survey is somewhat misleading... but that being said, it's clearly not measuring which format is superlative... it's only measuring people's perceptions.
And here I was thinking that the whole point of lossy audio compression was about throwing away information that people could not hear.:)
The format that throws away the least audible information (as determined, in fact, by "measuring people's perceptions"), other things (encoder complexity, file size, etc) being equal, is the winner.
for critical listening, only uncompressed audio is the way to go.
Somehow I don't think 99-cent files that can be downloaded in seconds was meant for "critical listening". I'm not saying you're wrong, just that you may want to evaluate a product or technology against its stated goals, not against your personal goals. Apple has stated that it basically breaks even at 99 cents per song, so what would it mean for their business model if you increase their bandwidth expenses tenfold?
Unless you really think that equality demands that females have access to all areas, all leagues, all competitions, but excluding males from certain leagues, competitions and areas are perfectly ok.
It is okay under certain conditions. One such condition is when female leagues are not as prestigious or lucrative as the male leagues. The WBNA is one such example, with players making as little as $30,000, compared to rookies in the NBA who are paid at least $300,000. The crucial question is whether a male player can make similar amounts elsewhere. (True for WNBA, false for NBA.)
Like I said, if the situation is reversed (WNBA makes more money), then the league should permit male players to play.
That is, however a sorta odd definition of "equality".
Not really. Americans instituted a (controversial) program known as Affirmative Action, where African-Americans are given preferential treatment in college admissions and other areas. This inequality was deliberately introduced to level the playing field, so that they can catch up literally from slavery. (I don't mean to argue the merits of AA, just to say that inequality can be seen as necessary, even at the expense of European Americans who benefited from slavery.)
Why is it so freaking hard to accept that males and females are different in some areas ?
It's not. It's just that this has been used as an excuse more often than it was used honestly. Some WWII-era politicians tried to cite "scientific studies" that African-Americans have smaller brains, and were not fit to operate complicated machinery like aircraft. It's simply a sensitive topic that should be examined with great care.
Put another way, what does the NBA possibly lose if it allows women in? Now compare that with what the WNBA could lose if it allowed men in.
(I said *perhaps*, I consider it possible that less femals FPS-champs is only a result of less players and/or less training, but I also consider it possible that there are physiological differences that play a role.)
Exactly, which is why (back to the topic now) sexually differentiated leagues should not be instituted until this is proven or at least widely accepted.
If it works for the next 24 years I'll be retired and they can hire someone else to fix it. I'm certain my code will not be around in 2100. So for all "practical" purposes, year % 4 = 0 works for the next 90 or so years.
I thought you were joking until I read your follow-up.
It's not a problem if your function will never be called with anything but the current year. However, how can you guarantee that no other programmer would ever call your function with some other year, and get the wrong answer?
You can put in an:
assert(year > 2000 && year < 2100);
to ensure that, and a comment to explain why it only works in this case. Alternatively, you can define your function as:
int is_leap_year_2000_to_2100(int year)
which is of course a weaker guarantee than the assertion, but should still intrigue the caller enough to check your code.
But the problem is that you're avoiding the two lines of code to be lazy, which means you'll probably not want to do either. Instead, you'll probably end up lying in the function name:
int is_leap_year(int year)
and introduce a bug that will definitely take longer to debug than it takes for you to write and test 2 lines of code.
Buy a mp3 player, try and replace the battery and end up spending another $400 on a new ipod. Whats that, $7-800? Is that ipod still a good deal?
Apple offers to replace the out-of-warranty battery for $105.95 including shipping. You can buy your own battery for less and replace it yourself, but you assume the risk of breaking it. Apple doesn't even say that it's easy to do it yourself.
I could have bought an entire working automobile for $800.
That's right, and if you try to perform repairs on that car yourself without really knowing how to, then you'll probably have to spend another $800 on another car.
Concept of the day: your choices carry consequences.
So, what you are saying is that separate female leagues in basketball is wrong, and they should instead play in the minor league aslong and try to compete their way into the main league by playing well enough?
No, I'm not saying that all-female leagues are wrong. I'm saying that excluding females from dominant leagues (i.e., NBA, NFL, etc) is wrong. There are no equivalents to these when you consider the prestige and paychecks involved. If no woman can play at NBA levels, fine. That's the reality you speak of. If there is just one who could, but is forced to play in the WNBA instead, you've done her an injustice.
Put another way, if the WNBA suddenly started to make a great deal more money than the NBA, then I think it should change its name and allow male players in. Point is, a male player who is good enough to play in the WNBA but not the NBA still has choices like the CBA. A hypothetical female player good enough for the NBA has none.
(I use money to simplify the discussion. I realize sports isn't entirely about money, yet.)
Why do the best Marathon times come from men then? Why aren't women winning the Tour de France?
One possibility is that the difference only shows under extreme (i.e., near death) conditions. That is, if you run people continuously for hundreds of miles, the last few to die may be mostly women. Obviously, even if this was true it wouldn't make a sport. (Note the word "possibility". I'm offering a possible explanation, not asserting a scientific finding.)
Another interesting tidbit is that the US Air Force had found that many women perform better than men in centrifuges, possibly because of their generally shorter distances between brain and heart. Again, this is basically spinning you until you pass out, which doesn't really make a sport either.
Sorry, but it's true. I'm not saying they'll nessecarily finish places 51-57, but my guess is that they would all be in the bottom half, and most of them in the bottom quarter.
There are several problems, but first remember that separate is rarely, if ever, equal.
There's no problem separating players by skill, the way baseball has a major league, a minor league, and other finer divisions. This allows players to improve among others of similar ability, rather than just getting clobbered all day. However, note that it's entirely possible for a baseball player to advance from the minors to the majors, simply by improving.
Next consider golf and its widespread handicap system. The system allows players of unequal abilities to compete directly.
The reason you're wrong is not because you think lowly of female gamers or athletes (for which I really can't be bothered to research and debunk). It's because you want to mitigate the problem by putting them in a separate league with no hope of movement. In general, they cannot become men even after the best female players improve vastly.
The correct way to do it is either to score by handicap, or separate players into leagues by skill (obviously with some rules for promotion or demotion). A FPS game has a most obvious handicap system: either give lower skilled players more powerful weapons, or stronger armor protection. Sex doesn't even have to enter into it.
No one thinks Linux is invulnerable. Linux is just MUCH BETTER than Windows.
That's exactly the kind of information that I don't think matters. What matters to me is that Linux is better today than it was yesterday, and then better tomorrow than it is today. Who cares about Windows?
Now, there is good reason to debunk biased reports. However, the more important task is to identify what vulnerabilities do remain, and how to fix them. How much discussion of that are we seeing in this discussion?
The numbers are meaningless without the background. Even assuming that those numbers are CORRECT, what does that tell you about Linux?
Were those attacks successful because of a bad choice of passwords?...or because of permissions set wrong on a script?...or because of a hole in sendmail?...or because of a buffer overflow?...or because of........?
Indeed. Doesn't it make you wonder? Doesn't it bother you that you don't know for sure that nothing that can be done?
There is no information presented in that "article" beyond some numbers given out of context. Because there is no information given, no actions are required.
How about actively working with the ones who reported the problem to see what can be done about it, rather than doing nothing? Nobody owes us precise and free information on how Linux or anything other free software project can be improved.
No "probably" about it. One of the rules of security is TURN OFF ANYTHING YOU DO NOT ABSOLUTELY NEED.
I'm not talking about the settings on a particular machine. I'm talking about the choice of a distro to leave a service enabled or disabled by default.
The original post reminded us not to forget that Windows or OS X boxes could have undiscovered exploits. I'm reminding that Linux can also have undiscovered exploits. By definition, we cannot know how many undiscovered exploits there are in each OS, so we cannot quantify and compare them. Therefore, we must ignore them and talk about the known exploits. Flamebait?
If anything will destroy Linux, it's fanboy groupthink that the OS is invulnerable. Every choice has a downside. Deciding to leave a service off by default probably makes it more secure, though less convenient. When there are numbers like these presented, it's exactly the time to review such choices to see if they are the right choices to make for your users. Flamebait?
The blame really doesn't go to Linux for its design. It just happens to be popular amongst people who don't know squat about security, though it would help if more distros would lock things down by default.
"Linux" is a vague term here. While which ports are open and what services are running by default aren't part of the Linux kernel design, it's very much part of the design of a Linux distro. How easy it is to switch services on and off is also part of design. It certainly better not be an accident what services are running by default!
If mi2g is saying that BSD OS's and Mac OS-X's are the most secure, then why are they using Linux? Netcraft shows they're running Linux with Apache and have been for over 1.5 years.
I know you're aching to defend Linux in the face of bad numbers, but this is really stretching it. There are many reasons why a company selects one OS over another for its servers: administrator familiarity, price (of both the software and hardware), vendor support, etc. Security - which is not a binary attribute - is one of the factors traded off against the others.
Even if the study is valid (and I'm not saying it is), it doesn't mean Linux cannot be secured. It might mean that Linux is not easily secured, which is a problem. I'm not drawing conclusions (note the "might"), just pointing out that the numbers should not be dismissed just because the source continues to use Linux.
In short, with Linux, most vulns are due to misconfiguration of apps and NOT an inherent flaw in the system.
Windows has, so far, had a bad track record of SYSTEM LEVEL flaws and not necessarily inherent flaws.
It doesn't make a difference whether the burglar came into your house through an unlocked window or an unlocked door. If, assuming you are correct that Linux has a lot of vulnerabilities due to misconfiguration, then isn't it time to review the configuration process?
Don't forget, they're also only counting Overt attacks, I.E. Verified ones... ones that leave a trace. It could very well be that all of those windows or OSX boxes were at some point Owned, but that the attack was so successful as to not leave a trace.
Exactly how would you discover an attack that was so successful as to not leave a trace? By definition such an attack cannot or has not yet been discovered or traced. Leaving them out is both inevitable and fair, because there are attacks against Linux that are similarly undiscovered.
So if you want to take the survey methodology seriously, then the survey proves beyond a shadow of a doubt that Linux has more non-automated attacks involving changing publicly accessible interfaces that were caught and reported by friends to mi2g.
I understand that anytime somebody publishes a Top N List the urge to compete externally is great, but why not ignore the others and simply use this as a data point to improve oneself?
"The reason why OSX 'just works' on Apple computers is because Apple has complete control over the hardware." [...] is something Apple people say and it makes them feel good, because implied in it is the presumption that Apple's hardware is actually better than what the unwashed masses buy at Fry's.
No, it's something you say to point out that Apple has a much smaller of hardware combinations to support.
to revolutionize the industry, it isn't necessary to support all hardware. You could support only ECS K7VTA3 boards, with an ATI video card. And that tiny slice of the PC world would still DOUBLE YOUR MARKET SHARE.
It would also put Apple directly in the crosshairs of Microsoft. There's no way Microsoft would overlook this challenge. It's not a matter of losing a few percent over years, but a real danger of mass exodus. Remember also that this is a Microsoft that just basically got off with a slap on the wrist with its anti-trust case. Can you imagine another Attorney General taking them on again soon?
your protestations that a huge amount of work would have to be done to port everything over to x86 simply betray that you haven't written code to compile cleanly on multiple systems.
Compile cleanly? You're not seriously suggesting that something that compiles cleanly is good enough to ship? Different hardware platforms and compilers will make bugs show up. You'll also need to increase QA capacity dramatically.
It's not very hard to port code to a different platform and get it to an alpha level. To get it ready to ship is another story entirely.
Also, while Adobe might port Photoshop to x86 OS X, do you imagine Microsoft would port Office to it?
All the applications that Apple depends on were originally written for the real computer market -- MS Office, Adobe, etc, and ported only as a way of squeezing a few more sales out of them.
Excel was originally developed on the Mac in 1985. Word was also developed on the Mac before there was a Windows version (a DOS version that doesn't really act like either predates the Mac version). The original version of Photoshop was written on a Mac Plus. So what are you talking about?
Why are Jobs & Followers limiting their potential market in this way ? The only answer is that they are afraid of being precisely the type of computer revolutionaries that they pretend to be in Super Bowl Ads.
I have a much simpler explanation: they are afraid of Microsoft. Why do you find that hard to believe?
The retail industry is just waiting for someone to put a CHEAP cash register with some major bank (credit card) support in it. The first person to cash in on this will make $$$!
If the cash register has to be "CHEAP", how am I going to make "$$$"? Identifying a market demand is not the same as identifying an actual source of profit.
The issue is providing support to such some vendors at a price that's reasonable.
Another is surviving the first lawsuit for a bug that cost somebody some real money.
Not sure if you know already or not, but Debian is pretty easy to upgrade from one version to the next...
The cost I was talking about is a potential cost for instability introduced by the new features (that you didn't really need) when you upgrade. A new version almost certainly brings new bugs, and also configuration mistakes and other user errors into your system. On a production server, you do not upgrade lightly.
Ideally, you pick a version with the features you need, and get continuous security, optimization, and bug patches until it is as close to perfect as humanly possible. You would upgrade only when you need a new feature. What I was trying to point out is that from a TCO perspective, staying with really really old software is still not viable, despite it being open source.
the Fedora legacy project [is] currently supporting Red Hat Linux 7.2, 7.3, and 8.0 as these have reached their End-of-Life (EOL).
Red Hat 7.2 was released on October 22, 2001. Who supports anything older than two years and four months?
As Fedora Core releases become EOL, we will provide support for them on a 1-2-3 and out policy, providing for roughly 1.5 years of update support for each release.
IOW, they expect you to upgrade within 1.5 years. I believe this also means support for 7.2 will be dropped within three months.
This is, let me stress, entirely fair. Fedora (or anybody else) doesn't have infinite volunteer resources, and cannot possibly support every old version. I'm not blaming them in any way.
I'm just saying that at some point it's cheaper for you to upgrade than to insist on running the old version. Even when running open source software.
I think the point is that you can patch Red Hat 5.x for free by upgrading to a more recent version of Red^H^H^HFedora for no charge.
Please read the original post I was responding to, which states:
Unless your arguing that staying current is the only way to avoid exploits, then your making a strong argument that the TCO of Open Source should be sung from the moutain top.
I'm not going to respond to each response with the same message, so here it is:
The IE situation is the worst. You probably have no choice but to upgrade. In this case you can probably download IE 6 for free, but for other exploits you may have to pay for a newer version of Windows. Hear me, it's the worst.
The open source situation is better. You at least have the source, and at the worst case can go patch it yourself or pay somebody to patch it. Some investment in time or money can enable you to stay with an older version to avoid upgrading.
However, open source doesn't solve all the problems. If there's no volunteer to keep an old version patched, then there's some cost on your part if you don't want to upgrade. Upgrading, on the other hand, contains some risks (which may translate to cost as well). For one, the new features may contain new exploits.
Which is why I wrote that insisting on running Red Hat 5.0 may be expensive, even though it's open source. It's entirely possible (which is good, and better than IE or Windows), because you have source, but it may not be viable, despite having the source.
Somebody brought up Debian. Yes, Debian maintains an excellent stable distribution. However, not even Debian volunteers patch every old version. At some point, "testing" becomes "stable" and the old "stable" will be left to rot. If you insist on running the old one, then your personal TCO will increase significantly.
And now the obvious conclusion: not even open source can make not upgrading a viable option forever. At some point (obviously at different points for Windows compared to Red Hat Linux) it's cheaper to upgrade. That's all I'm saying.
Maybe you should compare it to a relatively new Red Hat version, like 7.3 or say 8.0.
That's the entire point I was making, which you apparently missed. Just because Red Hat 5.0 was open source doesn't mean you can viably continue to use it indefinitely. If nobody will apply patches for you for free, you'll either have to do it yourself (time) or pay somebody to do it (money). Remember, the cost in this case is not compared to Windows, but to upgrading.
But just for the sake of argument, where would you get free patches for Red Hat 7.3?
Just because it doesn't occur in future releases, doesn't mean its been fixed. Unless your arguing that staying current is the only way to avoid exploits, then your making a strong argument that the TCO of Open Source should be sung from the moutain top.
You're right, but open source software don't all conveniently provide security updates for old versions, either. It is definitely better, because if nobody else (package maintainer) does it for you, you can do it yourself. However, let's not sing from the mountaintops, because the TCO for insisting on running Red Hat 5.0 today is probably considerable.
Both forms of development obey the same equation: cost versus benefit. The difference is that the cost in commercial software is entirely calculated based on the perspective of the source code owner. While open source is better, it can still be "too expensive" to fix relative to just upgrading.
It seems a lot of people think that overtaking Mac is not a newsworthy feat. It is a huge deal. [...] if they have developed Photoshop for Mac, including MacOSX, then they now have a reason to develop it for GNU/Linux.
Notice many stores selling Linux-based computers? Notice dozens of stores selling only Macintosh computers, as well as some others that also Macintosh computers? The market share of a free product will not be interesting to Adobe until it can be shown that the same people are willing to pay $700 for Photoshop.
it looks to me like they did go for maximal reuse. It's just that, with all cross-platform requirements gone, the choice was not between Gecko and KHTML but between Gecko and KHTML + Cocoa...
Ahh, good point. This brings up another point, which is that reuse and commercially developed code aren't mutually exclusive. Microsoft bought some code to jumpstart IE, and Apple bought NeXTStep to jumpstart MacOS X. In my original rebuttal I simply forgot to mention the obvious: that you can buy the copyright of the code you want.
I will agree with you that the great-granparent overreached with that "virtual standstill" comment. But still I think you're stretching those examples quite a bit. Maybe you can find better ones:-)
Picky, picky.:) Netscape had 70% of the market, and Microsoft caught up within a few years, including bug-for-bug compatibility in some areas. Isn't that dramatic enough an example to prove that closed source development isn't really slow?
As you admit OS X makes significant (I'd say huge) reuse of (Mach,) BSD and NeXTstep. Didn't previous attempts to do it from scratch almost kill Apple? (I forget the projects' names... Taligent? Copland?)
Note that Apple went cherry picking with MacOS X. The conventional wisdom would be to just adopt BSD in its entirety, which maximizes the number of lines reused. It's difficult to say, especially from an outsider's view, whether the problems with Copeland is really technical.
As I said, suitable reuse does speed up improvement. MacOS X has progressed much more quickly than Windows in the past three years or so, and a part of that success must be credited to their liberal adoption of free software.
As to KHTML vs. Gecko, they seem to simply not have found the latter so "superior"...
The relevant passage from the article you cited is: "The size of your code and ease of development within that code made it a better choice for us than other open source projects. Your clean design was also a plus."
In other words, it was better for Apple that KHTML was smaller. It was big enough to save them considerable time, but small enough to easily understand and extend. Put another way, you don't try to reuse the maximum number of lines of code possible, which matches my point exactly. New lines of code are simply not that hard to write, compared to the effort required in understanding a larger body of code.
Entering "microdrive 4gb" in eBay gets me 64 hits. Apple announced that it has over 100,000 pre-orders for the iPod Mini. Even if every single one of those was stripped from an iPod Mini (not likely) and Apple only produced enough to fulfill pre-orders (not likely), that would account for 0.06% of its sales.
Please just accept that your criteria for what makes a good deal may not be shared by... hundreds of thousands of other people.
And here I was thinking that the whole point of lossy audio compression was about throwing away information that people could not hear. :)
The format that throws away the least audible information (as determined, in fact, by "measuring people's perceptions"), other things (encoder complexity, file size, etc) being equal, is the winner.
for critical listening, only uncompressed audio is the way to go.
Somehow I don't think 99-cent files that can be downloaded in seconds was meant for "critical listening". I'm not saying you're wrong, just that you may want to evaluate a product or technology against its stated goals, not against your personal goals. Apple has stated that it basically breaks even at 99 cents per song, so what would it mean for their business model if you increase their bandwidth expenses tenfold?
It is okay under certain conditions. One such condition is when female leagues are not as prestigious or lucrative as the male leagues. The WBNA is one such example, with players making as little as $30,000, compared to rookies in the NBA who are paid at least $300,000. The crucial question is whether a male player can make similar amounts elsewhere. (True for WNBA, false for NBA.)
Like I said, if the situation is reversed (WNBA makes more money), then the league should permit male players to play.
That is, however a sorta odd definition of "equality".
Not really. Americans instituted a (controversial) program known as Affirmative Action, where African-Americans are given preferential treatment in college admissions and other areas. This inequality was deliberately introduced to level the playing field, so that they can catch up literally from slavery. (I don't mean to argue the merits of AA, just to say that inequality can be seen as necessary, even at the expense of European Americans who benefited from slavery.)
Why is it so freaking hard to accept that males and females are different in some areas ?
It's not. It's just that this has been used as an excuse more often than it was used honestly. Some WWII-era politicians tried to cite "scientific studies" that African-Americans have smaller brains, and were not fit to operate complicated machinery like aircraft. It's simply a sensitive topic that should be examined with great care.
Put another way, what does the NBA possibly lose if it allows women in? Now compare that with what the WNBA could lose if it allowed men in.
(I said *perhaps*, I consider it possible that less femals FPS-champs is only a result of less players and/or less training, but I also consider it possible that there are physiological differences that play a role.)
Exactly, which is why (back to the topic now) sexually differentiated leagues should not be instituted until this is proven or at least widely accepted.
I thought you were joking until I read your follow-up.
It's not a problem if your function will never be called with anything but the current year. However, how can you guarantee that no other programmer would ever call your function with some other year, and get the wrong answer?
You can put in an:
to ensure that, and a comment to explain why it only works in this case. Alternatively, you can define your function as:which is of course a weaker guarantee than the assertion, but should still intrigue the caller enough to check your code.But the problem is that you're avoiding the two lines of code to be lazy, which means you'll probably not want to do either. Instead, you'll probably end up lying in the function name:
and introduce a bug that will definitely take longer to debug than it takes for you to write and test 2 lines of code.To knowingly do that is plainly unprofessional.
Apple offers to replace the out-of-warranty battery for $105.95 including shipping. You can buy your own battery for less and replace it yourself, but you assume the risk of breaking it. Apple doesn't even say that it's easy to do it yourself.
I could have bought an entire working automobile for $800.
That's right, and if you try to perform repairs on that car yourself without really knowing how to, then you'll probably have to spend another $800 on another car.
Concept of the day: your choices carry consequences.
No, I'm not saying that all-female leagues are wrong. I'm saying that excluding females from dominant leagues (i.e., NBA, NFL, etc) is wrong. There are no equivalents to these when you consider the prestige and paychecks involved. If no woman can play at NBA levels, fine. That's the reality you speak of. If there is just one who could, but is forced to play in the WNBA instead, you've done her an injustice.
Put another way, if the WNBA suddenly started to make a great deal more money than the NBA, then I think it should change its name and allow male players in. Point is, a male player who is good enough to play in the WNBA but not the NBA still has choices like the CBA. A hypothetical female player good enough for the NBA has none.
(I use money to simplify the discussion. I realize sports isn't entirely about money, yet.)
One possibility is that the difference only shows under extreme (i.e., near death) conditions. That is, if you run people continuously for hundreds of miles, the last few to die may be mostly women. Obviously, even if this was true it wouldn't make a sport. (Note the word "possibility". I'm offering a possible explanation, not asserting a scientific finding.)
Another interesting tidbit is that the US Air Force had found that many women perform better than men in centrifuges, possibly because of their generally shorter distances between brain and heart. Again, this is basically spinning you until you pass out, which doesn't really make a sport either.
There are several problems, but first remember that separate is rarely, if ever, equal.
There's no problem separating players by skill, the way baseball has a major league, a minor league, and other finer divisions. This allows players to improve among others of similar ability, rather than just getting clobbered all day. However, note that it's entirely possible for a baseball player to advance from the minors to the majors, simply by improving.
Next consider golf and its widespread handicap system. The system allows players of unequal abilities to compete directly.
The reason you're wrong is not because you think lowly of female gamers or athletes (for which I really can't be bothered to research and debunk). It's because you want to mitigate the problem by putting them in a separate league with no hope of movement. In general, they cannot become men even after the best female players improve vastly.
The correct way to do it is either to score by handicap, or separate players into leagues by skill (obviously with some rules for promotion or demotion). A FPS game has a most obvious handicap system: either give lower skilled players more powerful weapons, or stronger armor protection. Sex doesn't even have to enter into it.
That's exactly the kind of information that I don't think matters. What matters to me is that Linux is better today than it was yesterday, and then better tomorrow than it is today. Who cares about Windows?
Now, there is good reason to debunk biased reports. However, the more important task is to identify what vulnerabilities do remain, and how to fix them. How much discussion of that are we seeing in this discussion?
The numbers are meaningless without the background. Even assuming that those numbers are CORRECT, what does that tell you about Linux?
Were those attacks successful because of a bad choice of passwords? ...or because of permissions set wrong on a script? ...or because of a hole in sendmail? ...or because of a buffer overflow? ...or because of ........?
Indeed. Doesn't it make you wonder? Doesn't it bother you that you don't know for sure that nothing that can be done?
There is no information presented in that "article" beyond some numbers given out of context. Because there is no information given, no actions are required.
How about actively working with the ones who reported the problem to see what can be done about it, rather than doing nothing? Nobody owes us precise and free information on how Linux or anything other free software project can be improved.
No "probably" about it. One of the rules of security is TURN OFF ANYTHING YOU DO NOT ABSOLUTELY NEED.
I'm not talking about the settings on a particular machine. I'm talking about the choice of a distro to leave a service enabled or disabled by default.
The original post reminded us not to forget that Windows or OS X boxes could have undiscovered exploits. I'm reminding that Linux can also have undiscovered exploits. By definition, we cannot know how many undiscovered exploits there are in each OS, so we cannot quantify and compare them. Therefore, we must ignore them and talk about the known exploits. Flamebait?
If anything will destroy Linux, it's fanboy groupthink that the OS is invulnerable. Every choice has a downside. Deciding to leave a service off by default probably makes it more secure, though less convenient. When there are numbers like these presented, it's exactly the time to review such choices to see if they are the right choices to make for your users. Flamebait?
"Linux" is a vague term here. While which ports are open and what services are running by default aren't part of the Linux kernel design, it's very much part of the design of a Linux distro. How easy it is to switch services on and off is also part of design. It certainly better not be an accident what services are running by default!
I know you're aching to defend Linux in the face of bad numbers, but this is really stretching it. There are many reasons why a company selects one OS over another for its servers: administrator familiarity, price (of both the software and hardware), vendor support, etc. Security - which is not a binary attribute - is one of the factors traded off against the others.
Even if the study is valid (and I'm not saying it is), it doesn't mean Linux cannot be secured. It might mean that Linux is not easily secured, which is a problem. I'm not drawing conclusions (note the "might"), just pointing out that the numbers should not be dismissed just because the source continues to use Linux.
It doesn't make a difference whether the burglar came into your house through an unlocked window or an unlocked door. If, assuming you are correct that Linux has a lot of vulnerabilities due to misconfiguration, then isn't it time to review the configuration process?
Exactly how would you discover an attack that was so successful as to not leave a trace? By definition such an attack cannot or has not yet been discovered or traced. Leaving them out is both inevitable and fair, because there are attacks against Linux that are similarly undiscovered.
So if you want to take the survey methodology seriously, then the survey proves beyond a shadow of a doubt that Linux has more non-automated attacks involving changing publicly accessible interfaces that were caught and reported by friends to mi2g.
I understand that anytime somebody publishes a Top N List the urge to compete externally is great, but why not ignore the others and simply use this as a data point to improve oneself?
This means Apple has to pay Microsoft for every copy of x86 OS X sold. What makes you think this is a good idea?
No, it's something you say to point out that Apple has a much smaller of hardware combinations to support.
to revolutionize the industry, it isn't necessary to support all hardware. You could support only ECS K7VTA3 boards, with an ATI video card. And that tiny slice of the PC world would still DOUBLE YOUR MARKET SHARE.
It would also put Apple directly in the crosshairs of Microsoft. There's no way Microsoft would overlook this challenge. It's not a matter of losing a few percent over years, but a real danger of mass exodus. Remember also that this is a Microsoft that just basically got off with a slap on the wrist with its anti-trust case. Can you imagine another Attorney General taking them on again soon?
your protestations that a huge amount of work would have to be done to port everything over to x86 simply betray that you haven't written code to compile cleanly on multiple systems.
Compile cleanly? You're not seriously suggesting that something that compiles cleanly is good enough to ship? Different hardware platforms and compilers will make bugs show up. You'll also need to increase QA capacity dramatically.
It's not very hard to port code to a different platform and get it to an alpha level. To get it ready to ship is another story entirely.
Also, while Adobe might port Photoshop to x86 OS X, do you imagine Microsoft would port Office to it?
All the applications that Apple depends on were originally written for the real computer market -- MS Office, Adobe, etc, and ported only as a way of squeezing a few more sales out of them.
Excel was originally developed on the Mac in 1985. Word was also developed on the Mac before there was a Windows version (a DOS version that doesn't really act like either predates the Mac version). The original version of Photoshop was written on a Mac Plus. So what are you talking about?
Why are Jobs & Followers limiting their potential market in this way ? The only answer is that they are afraid of being precisely the type of computer revolutionaries that they pretend to be in Super Bowl Ads.
I have a much simpler explanation: they are afraid of Microsoft. Why do you find that hard to believe?
If the cash register has to be "CHEAP", how am I going to make "$$$"? Identifying a market demand is not the same as identifying an actual source of profit.
The issue is providing support to such some vendors at a price that's reasonable.
Another is surviving the first lawsuit for a bug that cost somebody some real money.
The cost I was talking about is a potential cost for instability introduced by the new features (that you didn't really need) when you upgrade. A new version almost certainly brings new bugs, and also configuration mistakes and other user errors into your system. On a production server, you do not upgrade lightly.
Ideally, you pick a version with the features you need, and get continuous security, optimization, and bug patches until it is as close to perfect as humanly possible. You would upgrade only when you need a new feature. What I was trying to point out is that from a TCO perspective, staying with really really old software is still not viable, despite it being open source.
Red Hat 7.2 was released on October 22, 2001. Who supports anything older than two years and four months?
As Fedora Core releases become EOL, we will provide support for them on a 1-2-3 and out policy, providing for roughly 1.5 years of update support for each release.
IOW, they expect you to upgrade within 1.5 years. I believe this also means support for 7.2 will be dropped within three months.
This is, let me stress, entirely fair. Fedora (or anybody else) doesn't have infinite volunteer resources, and cannot possibly support every old version. I'm not blaming them in any way.
I'm just saying that at some point it's cheaper for you to upgrade than to insist on running the old version. Even when running open source software.
Please read the original post I was responding to, which states:
I'm not going to respond to each response with the same message, so here it is:
The IE situation is the worst. You probably have no choice but to upgrade. In this case you can probably download IE 6 for free, but for other exploits you may have to pay for a newer version of Windows. Hear me, it's the worst.
The open source situation is better. You at least have the source, and at the worst case can go patch it yourself or pay somebody to patch it. Some investment in time or money can enable you to stay with an older version to avoid upgrading.
However, open source doesn't solve all the problems. If there's no volunteer to keep an old version patched, then there's some cost on your part if you don't want to upgrade. Upgrading, on the other hand, contains some risks (which may translate to cost as well). For one, the new features may contain new exploits.
Which is why I wrote that insisting on running Red Hat 5.0 may be expensive, even though it's open source. It's entirely possible (which is good, and better than IE or Windows), because you have source, but it may not be viable, despite having the source.
Somebody brought up Debian. Yes, Debian maintains an excellent stable distribution. However, not even Debian volunteers patch every old version. At some point, "testing" becomes "stable" and the old "stable" will be left to rot. If you insist on running the old one, then your personal TCO will increase significantly.
And now the obvious conclusion: not even open source can make not upgrading a viable option forever. At some point (obviously at different points for Windows compared to Red Hat Linux) it's cheaper to upgrade. That's all I'm saying.
That's the entire point I was making, which you apparently missed. Just because Red Hat 5.0 was open source doesn't mean you can viably continue to use it indefinitely. If nobody will apply patches for you for free, you'll either have to do it yourself (time) or pay somebody to do it (money). Remember, the cost in this case is not compared to Windows, but to upgrading.
But just for the sake of argument, where would you get free patches for Red Hat 7.3?
You're right, but open source software don't all conveniently provide security updates for old versions, either. It is definitely better, because if nobody else (package maintainer) does it for you, you can do it yourself. However, let's not sing from the mountaintops, because the TCO for insisting on running Red Hat 5.0 today is probably considerable.
Both forms of development obey the same equation: cost versus benefit. The difference is that the cost in commercial software is entirely calculated based on the perspective of the source code owner. While open source is better, it can still be "too expensive" to fix relative to just upgrading.
Notice many stores selling Linux-based computers? Notice dozens of stores selling only Macintosh computers, as well as some others that also Macintosh computers? The market share of a free product will not be interesting to Adobe until it can be shown that the same people are willing to pay $700 for Photoshop.
Ahh, good point. This brings up another point, which is that reuse and commercially developed code aren't mutually exclusive. Microsoft bought some code to jumpstart IE, and Apple bought NeXTStep to jumpstart MacOS X. In my original rebuttal I simply forgot to mention the obvious: that you can buy the copyright of the code you want.
Picky, picky. :) Netscape had 70% of the market, and Microsoft caught up within a few years, including bug-for-bug compatibility in some areas. Isn't that dramatic enough an example to prove that closed source development isn't really slow?
As you admit OS X makes significant (I'd say huge) reuse of (Mach,) BSD and NeXTstep. Didn't previous attempts to do it from scratch almost kill Apple? (I forget the projects' names... Taligent? Copland?)
Note that Apple went cherry picking with MacOS X. The conventional wisdom would be to just adopt BSD in its entirety, which maximizes the number of lines reused. It's difficult to say, especially from an outsider's view, whether the problems with Copeland is really technical.
As I said, suitable reuse does speed up improvement. MacOS X has progressed much more quickly than Windows in the past three years or so, and a part of that success must be credited to their liberal adoption of free software.
As to KHTML vs. Gecko, they seem to simply not have found the latter so "superior"...
The relevant passage from the article you cited is: "The size of your code and ease of development within that code made it a better choice for us than other open source projects. Your clean design was also a plus."
In other words, it was better for Apple that KHTML was smaller. It was big enough to save them considerable time, but small enough to easily understand and extend. Put another way, you don't try to reuse the maximum number of lines of code possible, which matches my point exactly. New lines of code are simply not that hard to write, compared to the effort required in understanding a larger body of code.