Re:Our resposibilities to each other
on
The CVS Cop-Out
·
· Score: 1
Actually both the attitudes you cite are found in petulant children. However, I'd note that developers tend to take the first attitude only when first faced with users taking the second. Mature adults who understand that the developer's doing this out of the goodness of his heart and doesn't owe them anything tend to get a much more polite and respectful response from developers because the user's being polite and respectful too.
I'd note that this isn't some new phenomenom related to F/OSS. I ran into it back in the early 80s when I ran a BBS system. I set up a system, made it available to people for free, and only expected them to follow a few simple rules of what I considered common courtesy (no flaming or personal attacks, take off-topic discussions to an area where they're on-topic, don't monopolize the BBS). Normally I could deal with infractions with a polite nudge, but I had a few bad apples who insisted that, because I'd made the system available to them, I couldn't enforce any rules. When I had someone tell me I couldn't kick them off for blatantly flaming, using foul language, personal attacks and flooding the discussion areas because the First Amendment gave them that right, I tended to resort to the final argument: reach over, offline the modem so it dropped the call and wouldn't auto-answer again, dump the offender off the system and nuke their usernames (these sorts always seemed to have several in reserve) and put a note about the removal in the MOTD. Yeah it's kind of childish, but what am I going to do, argue with a self-absorbed nutcase?
Re:Oh .. I get it.
on
The CVS Cop-Out
·
· Score: 1, Insightful
Because I needed the software, and I'm using or going to use it. I'm going to write it regardless of whether I release it to the rest of the world or not. It doesn't cost me a lot, if anything, to make it available to everyone else, and if I make it available everyone else gets more than if I didn't. If it's buggy they don't get as much more, but they still get more.
I have to say, I sense a theme here. OSS developers are giving you for free things you didn't have before, and you're complaining that they aren't giving you as much as fast and as good a quality as you want.
Re:Not a cop-out, just a fact
on
The CVS Cop-Out
·
· Score: 1
Except that a lot of the time that isn't viable.
The bug isn't particularly major, or there's a known and easily-used workaround that avoids the problem.
The fix for the bug's intertwined with a lot of other work. It can't be easily extracted into a simple patch, it's going to touch a lot of other code and all the stuff that it's intertwined with would have to come along. The more changes you pull into the fix, the longer it takes to apply and test. It can easily be faster to just continue on to the next planned release.
The bug's a major showstopper, but it's cause is a fundamental aspect of the program's internal design. Fixing this kind of bug often requires first reworking the internal design to get rid of the problem, then recoding the rest of the program to account for the changes. And if the work's already been done and checked in, it'll be faster to just speed up the next release rather than backport extensive rework.
And last but not least, it's usually not just one bug. Usually it's a lot of people all wanting their one bug backported. Several dozen people each with one bug equals several dozen bugs that one or two developers have to backport. They have to then weigh the value of fixing those bugs (to them, since the users aren't paying for this) vs. the cost to the project of delaying development by weeks or months while all this happens.
Re:Oh .. I get it.
on
The CVS Cop-Out
·
· Score: 4, Interesting
In a company, you would be paying me money to do the work. You can bet that if you're paying me then making it work for you and fixing any bugs you find go straight to the top of my priority list. But if you aren't paying me, you don't get special priority. They go on the list, sure, but they get prioritized based on what I think is important.
I see you all the time, BTW. You're the guy who's always asking me to fix his computer. For free. Even though he didn't get it from me, won't take it to the shop he got it from, won't listen to any advice I give him let alone actually follow it, and insists he didn't do anything to break the system. It's amazing how offended such folks can be when I insist on payment in advance at standard rates.
Not a cop-out, just a fact
on
The CVS Cop-Out
·
· Score: 4, Insightful
The writer's probably familiar with the same thing in hardcopy publishing: a magazine prints an inaccuracy, realizes it after publication but before the magazine hits the stands, and puts a correction in for the next issue. Once the magazine hits the stands everyone in the world starts writing in about the error, and the only thing the magazine can say is "We know, we've already written the correction and it'll be in the next issue.". Their statement isn't a cop-out, it's a simple fact.
Same with the "It's been fixed in CVS.". The developers know about the bug, they know how to fix it, they have fixed it, and there's not a thing they can do further until the next release version with the fix in it goes out. Often the fix is intertwined with other changes so it's not a simple matter of applying a small patch and releasing a bugfix version, and there's always testing to make sure the fix doesn't break anything else (and fixing the breakage if it does). Plus, if they do decide to go back, remember that they're already well along the way to the next release. Coding's been done, all that work has to be interrupted, put aside, then picked up once the bugfix is out. That can cost more time than actually fixing the bug did. I deal with this all the time at work, where a bug that takes me a couple of hours to diagnose, fix and test can, when it pops up in production near the mid-point of development for the next version, cost me half a week or more of development time. Needless to say I try to avoid that kind of costly backtracking unless the bug's a true world-shaker that absolutely can't be lived with.
The "It's been fixed in CVS." can be translated roughly as "Yes, we know about it. We've fixed it. Every bit of time you make us take repeating this is time we can't work on getting the fix into your hands.".
No, the Internet isn't that fragile. It's suprisingly robust, in fact. About the only thing that can really do any significant damage is sheer volume, enough traffic from enough distinct sources to overwhelm the target server or swamp it's network connections. No matter what, anything is always going to be vulnerable to that. You can only have finite bandwidth and server horsepower, and if an opponent's willing and able to throw enough resources at you he can simply overwhelm you. It's often referred to as "the Slashdot effect".
The only thing that's happened is that, because of the inherent insecurity of Windows machines and the increasing number of them with broadband connections, the bad guys now have access to orders of magnitude more bandwidth and horsepower than any single server can have. In military terms it's like facing an enemy who outnumbers you by ten thousand to one. Distributing your DNS won't help, redundant pipes won't help, distributing your servers won't help, if you can deal with 99% of his assault he's still got a hundred times what you can absorb left.
The only thing that can help is cutting off the supply of ownable machines the bad guys can take over and use in their attacks. If they're limited to their own machines they can't do much harm.
This company's going to get shot down if they face Google in court. Their example of filtering is the opposite of what they're complaining about. They give an example of Google not offering suggestions for "sex", which means Google is filtering the input keywords. They then complain that Google doesn't exclude "servercheck keygen" from the result set for "servercheck", which would involve filtering the output set. Google's response will be, quite properly, "Yes, we can look at keywords and not offer any suggestions for a certain set of keywords. But that's not what you're asking. You're asking for us to filter the set of suggestions returned for potentially any set of keywords and remove certain suggestions but not others. And what criteria do we use to decide what's legitimate? "keygen" is entirely legitimate as a keyword for software to let authors generate license keys to issue to buyers of their own software, after all.".
None. There isn't an abstraction layer. This is just a new process for Novell to notify hardware makers when they patch or build a new kernel, get precompiled binary drivers for their newly-built kernel and make them available to users as part of the security-update download of a new kernel package. It's got nothing to do with the actual driver modules, kernel compilation or anything in the software itself.
For the remote desktop, you don't quite grok X11 yet. Any desktop on Linux is automatically remote. That's because even your local desktop is remote, it merely uses a protocol other than TCP on a "connection" that's just linked lists in RAM. The easiest way to get a remote desktop is using XDMCP to log in to the machine you want to use. If you've got an X server on your laptop (Cygwin/X will do), it'll let you set things up easily enough (unfortunately Windows doesn't allow you to replace the Windows desktop, so you'll have to be satisfied with either letting Windows be your window manager and desktop or having your entire X11 desktop in a (possibly full-screen) window). Remote audio takes a bit more, but there's things like NAS that'll allow it. I'm not sure on the setup because I haven't had to set it up (yet).
Actually that isn't the argument made. The argument for dynamically linking to GPL'd libraries is that the program using those libraries has to include at least a small amount of the actual code from those libraries (specifically the header files that define the API) at compile time, and that included code directly contribues a certain amount of binary code in the resulting executable. The GPL doesn't make any exceptions, so you have to either abide by the GPL's terms or not distribute that binary code as part of your executable (which you can't do unless you don't use the library at all). The LGPL was, BTW, created to provide an offical way of allowing this particular use.
I personally think that might run afould of fair use, but then again the companies that would most use this loophole have themselves argued that fair use doesn't cover situations similar to this in regards their code and I can't feel sorry for them being bitten by their own position. And, as I noted, the LGPL exists so a creator using the GPL instead is making a statement of intent about his license terms which a court would have to take into account.
Benefits to who? Certainly the costs of SOX compliance outweigh the benefits to the companies that have to comply, but SOX wasn't intended to benefit those companies.
I think all the response this tactic deserves is an icy "If you want to discuss license compliance, let me transfer you to our legal department where someone can assist you.". Then you do just that, making sure your lawyer knows before the MS rep can talk that the rep has stated or implied that you lack licenses for some software.
Of course, also make sure you've got original media and license certificats and keys for every copy of software you've got installed, or relevant current license agreement documentation covering the installed software. Remember that there's what MS might like you to have to produce, then there's what you legally have to or should be able to produce, and the two aren't neccesarily identical.
It amuses me that they focus so much on Computer Science enrollment. My experience is that a lot of the best programmers don't have a computer-science degree, or even math- or engineering-related degrees. Out of the last 6 months' worth of applicants I've interviewed where I work, the best one had an education degree. The people with CS degrees have, by contrast, been uniformly lacking in basic programming background and skills. It's not limited to the US either, it goes for the non-US applicants as well.
The thing is, getting in isn't a problem... for those involved in that sort of thing in the first place. Your problem with the barrier is that you aren't the sort who's involved in malware. I see the same thing as a computer programmer. I constantly boggle people with my ability to come up with the most obscure information about computer systems when they've spent literally days searching and haven't found anything. This was true even back 25 years ago when I was in school. What's an insurmountable barrier for a complete outsider evaporates quickly for anyone who's even begun to be involved in the field, mainly because one of the first things you develop is a network of people you can ask about where to look for things.
The thing about walls is that they often depend on your perspective, and one of the hardest things to learn and remember is that your perspective isn't neccesarily the only one.
Where drivers use defined APIs to the kernel without including significant code beyond API declarations and constant definitions (via header files), I don't see any grounds for trying to extend the kernel license to them. And I don't think trying to would be productive. If hardware makers want to go to the trouble of keeping their driver cleanly seperated from kernel internals and keeping up with changes in the kernel APIs and ABIs, I say it's their code and their right. It's a different matter if they start modifying kernel code itself to make their driver work, but if their driver can be plugged into a stock kernel without needing the kernel patched and recompiled, and the driver doesn't contain kernel code beyond what'd be allowed by fair use I can't see an issue.
At the same time, I don't see why the kernel has to cater to those vendors. I don't think kernel driver APIs/ABIs should change arbitrarily just to break proprietary drivers, but I don't think they should be frozen just to accomodate those drivers when there's good, solid technical reasons to justify changes. If the vendors want to keep their drivers proprietary, then they take on all the responsibilities that come with that including keeping up with kernel changes on their own. This will, of course, put the proprietary vendors at a disadvantage and cost them more to maintain the drivers, but that's the choice they made.
I wouldn't encourage proprietary drivers, but I wouldn't ban them either.
Again, when viruses were rampant in the 80s and early 90s it was all private networks with that same supposed barrier, yet it didn't appear to be a significant barrier to new virus writers. They had easy access to the private networks through a completely different community that could provide them with the connections they needed. The only apparent barriers were to the AV companies and other "good guys".
As I noted, the fallacy in your arguments is an unstated one: that what people outside the rootkit-writer community do can hinder communication within the rootkit community in a significant way. This has not been the case in the past, and nobody can point out any changes in the private networks that would change this in the future. When you say "Both would just become harder.", I have to respond "But both haven't become harder any other time your scenario's occurred.".
Except that the rootkit makers have always passed information around on their own private networks. Forcing them underground would change absolutely nothing on their side, and would mean the AV companies would have less info on the rootkits to base their signatures and detection code on. In fact, the nastiest stealthed, encrypted, polymorphic viruses were developed when there was no public circulation of information about the techniques involved.
The problem is that saying that circulation of information helps the rootkit makers has the implicit assumption that anyone outside that community can hinder circulation of information within it. This happens not to be the case.
Actually the all-you-can-eat places do limit the Homer Simpsons and still call it all-you-can-eat. They simply say "all you can eat" means all you personally can eat while you're there. You don't get to take it home with you and eat it later. You don't get to split your meal with your friends. And you don't get to leave and come back the next day and pick up where you left off without paying again.
My ISP is Cox HSI. Where I live their policy is to apply transit caps, but enforcement is mainly limited to habitual high-volume offenders. If you go over the cap occasionally, you won't see anything happen. If you go over by a large amount for an extended period of time, though, you'll find your connection throttled back and possibly face termination of your account for ToS violation. They've had to wield this club quite rarely, as only about 2-3% of customers are problem cases. That small percentage is responsible for about 50% of traffic, so shutting down or throttling even a few of the worst offenders has a significant effect.
If you're buying 2mbit of dedicated bandwidth, then yes you're entitled to it no matter what you do with it. But most people buying broadband connections aren't buying dedicated bandwidth. They're buying shared bandwidth burstable to (for example) 2mbit. In that case, using 2mbit continuously is trying to use something you didn't buy.
It's like my old dial-up ISP. They sold two kinds of accounts: standard dial-up, and dedicated modem lines. With a dedicated line, you bought modems for both ends and a dedicated phone line from your house to the ISP and you were entitled to exclusive use of that connection all the time. A standard dial-up account was not a dedicated line, and the assumption was that you weren't going to be dialed in continuously. So when people bought a standard dial-up account and tried to stay dialed in 24x7, after a bit the ISP sent them a nasty-gram: "Either buy a dedicated line, stop trying to stay dialed in 24 hours a day, or find your account terminated. If you haven't chosen in 10 days, we'll choose #3 for you.". I'd note that a standard dial-up account was $20/month, while a dedicated line started at $120/month and went up depending on distance ($20 for the account, $100 and up for phone company charges for the pair).
Except that the Linux developers mostly don't care whether consumers use Linux or not. Linux is developed because the developers want to do things, not because someone else does. If consumers don't adopt Linux in droves, it'll make precisely zero difference to the development of Linux. This is what's got companies like Real Networks and the media companies worried, Linux simply isn't playing the same game as them:
Other companies: "Hah! Rook to queen's bishop 4. Checkmate!" Linux: "Nice move. Pity we're playing checkers. <tac><tac><tac> King me."
I think CNet's coming to the wrong conclusions. Firstly, Apple's never going to license OSX on anything but Mac hardware. Control of the hardware's what gives Apple the ability to keep OSX stable and easy to install, they aren't going to give that up. What they've done with Mac-on-Intel and Boot Camp, though, is made buying Apple hardware safe for Windows users: whether you like OSX or not, you will be able to run Windows on your Intel-based Mac. Boot Camp isn't directly intended to let people dual-boot, it's intended as a warm fuzzy "Look, if OSX isn't for you you haven't wasted the price of that nice shiny hardware you bought.".
I think Apple fully intends to have good PC virtualization software as well. Intel hardware will make that easier. At that point they've got an attractive path to migrating people off Windows. They'll be able to say "If you buy a Mac with OSX, you can still run all your Windows software as well as you could on your Windows machine. If it turns out you've got one or two programs (like games) that won't run under the virtualization software, you can dual-boot into Windows if you have to. And if OSX just plain won't work for you, you can just wipe it and run Windows all the time and still have the shiny Mac hardware for people to drool over. If you're buying new hardware anyway, how can you go wrong?".
The problem is, as someone outside Apple I'm not neccesarily obliged not to disclose their trade secrets no matter how much damage my disclosure might do to Apple. In fact, as an outsider the only times I am obliged to keep their secrets are if a) I've signed a binding NDA with them or b) I'm aware when the information's given to me that it's being given in violation of an NDA or other obligation not to disclose it. The burden of maintaining secrecy falls almost entirely on Apple, and if they fail to maintain secrecy then it's almost entirely their problem, not mine. Note that in general trade secrets have no protection in law, the only things enforceable by law are agreements not to disclose certain information.
If a company came at me for disclosing trade secrets, the first thing I'd demand of them is that they identify exactly what agreement obliged me to maintain those secrets and to prove that I'd in fact signed that agreement. If they couldn't or wouldn't, I'd invite them to go pound sand (or, if they were suing me, I'd ask the judge for an immediate dismissal with prejudice and to be awarded costs). I wouldn't waste time on First Amendment or "I didn't disclose anything" arguments, I'd go straight for "I've no duty not to disclose".
Slashdot Mirror
Actually both the attitudes you cite are found in petulant children. However, I'd note that developers tend to take the first attitude only when first faced with users taking the second. Mature adults who understand that the developer's doing this out of the goodness of his heart and doesn't owe them anything tend to get a much more polite and respectful response from developers because the user's being polite and respectful too.
I'd note that this isn't some new phenomenom related to F/OSS. I ran into it back in the early 80s when I ran a BBS system. I set up a system, made it available to people for free, and only expected them to follow a few simple rules of what I considered common courtesy (no flaming or personal attacks, take off-topic discussions to an area where they're on-topic, don't monopolize the BBS). Normally I could deal with infractions with a polite nudge, but I had a few bad apples who insisted that, because I'd made the system available to them, I couldn't enforce any rules. When I had someone tell me I couldn't kick them off for blatantly flaming, using foul language, personal attacks and flooding the discussion areas because the First Amendment gave them that right, I tended to resort to the final argument: reach over, offline the modem so it dropped the call and wouldn't auto-answer again, dump the offender off the system and nuke their usernames (these sorts always seemed to have several in reserve) and put a note about the removal in the MOTD. Yeah it's kind of childish, but what am I going to do, argue with a self-absorbed nutcase?
Because I needed the software, and I'm using or going to use it. I'm going to write it regardless of whether I release it to the rest of the world or not. It doesn't cost me a lot, if anything, to make it available to everyone else, and if I make it available everyone else gets more than if I didn't. If it's buggy they don't get as much more, but they still get more.
I have to say, I sense a theme here. OSS developers are giving you for free things you didn't have before, and you're complaining that they aren't giving you as much as fast and as good a quality as you want.
Except that a lot of the time that isn't viable.
- The bug isn't particularly major, or there's a known and easily-used workaround that avoids the problem.
- The fix for the bug's intertwined with a lot of other work. It can't be easily extracted into a simple patch, it's going to touch a lot of other code and all the stuff that it's intertwined with would have to come along. The more changes you pull into the fix, the longer it takes to apply and test. It can easily be faster to just continue on to the next planned release.
- The bug's a major showstopper, but it's cause is a fundamental aspect of the program's internal design. Fixing this kind of bug often requires first reworking the internal design to get rid of the problem, then recoding the rest of the program to account for the changes. And if the work's already been done and checked in, it'll be faster to just speed up the next release rather than backport extensive rework.
And last but not least, it's usually not just one bug. Usually it's a lot of people all wanting their one bug backported. Several dozen people each with one bug equals several dozen bugs that one or two developers have to backport. They have to then weigh the value of fixing those bugs (to them, since the users aren't paying for this) vs. the cost to the project of delaying development by weeks or months while all this happens.In a company, you would be paying me money to do the work. You can bet that if you're paying me then making it work for you and fixing any bugs you find go straight to the top of my priority list. But if you aren't paying me, you don't get special priority. They go on the list, sure, but they get prioritized based on what I think is important.
I see you all the time, BTW. You're the guy who's always asking me to fix his computer. For free. Even though he didn't get it from me, won't take it to the shop he got it from, won't listen to any advice I give him let alone actually follow it, and insists he didn't do anything to break the system. It's amazing how offended such folks can be when I insist on payment in advance at standard rates.
The writer's probably familiar with the same thing in hardcopy publishing: a magazine prints an inaccuracy, realizes it after publication but before the magazine hits the stands, and puts a correction in for the next issue. Once the magazine hits the stands everyone in the world starts writing in about the error, and the only thing the magazine can say is "We know, we've already written the correction and it'll be in the next issue.". Their statement isn't a cop-out, it's a simple fact.
Same with the "It's been fixed in CVS.". The developers know about the bug, they know how to fix it, they have fixed it, and there's not a thing they can do further until the next release version with the fix in it goes out. Often the fix is intertwined with other changes so it's not a simple matter of applying a small patch and releasing a bugfix version, and there's always testing to make sure the fix doesn't break anything else (and fixing the breakage if it does). Plus, if they do decide to go back, remember that they're already well along the way to the next release. Coding's been done, all that work has to be interrupted, put aside, then picked up once the bugfix is out. That can cost more time than actually fixing the bug did. I deal with this all the time at work, where a bug that takes me a couple of hours to diagnose, fix and test can, when it pops up in production near the mid-point of development for the next version, cost me half a week or more of development time. Needless to say I try to avoid that kind of costly backtracking unless the bug's a true world-shaker that absolutely can't be lived with.
The "It's been fixed in CVS." can be translated roughly as "Yes, we know about it. We've fixed it. Every bit of time you make us take repeating this is time we can't work on getting the fix into your hands.".
No, the Internet isn't that fragile. It's suprisingly robust, in fact. About the only thing that can really do any significant damage is sheer volume, enough traffic from enough distinct sources to overwhelm the target server or swamp it's network connections. No matter what, anything is always going to be vulnerable to that. You can only have finite bandwidth and server horsepower, and if an opponent's willing and able to throw enough resources at you he can simply overwhelm you. It's often referred to as "the Slashdot effect".
The only thing that's happened is that, because of the inherent insecurity of Windows machines and the increasing number of them with broadband connections, the bad guys now have access to orders of magnitude more bandwidth and horsepower than any single server can have. In military terms it's like facing an enemy who outnumbers you by ten thousand to one. Distributing your DNS won't help, redundant pipes won't help, distributing your servers won't help, if you can deal with 99% of his assault he's still got a hundred times what you can absorb left.
The only thing that can help is cutting off the supply of ownable machines the bad guys can take over and use in their attacks. If they're limited to their own machines they can't do much harm.
This company's going to get shot down if they face Google in court. Their example of filtering is the opposite of what they're complaining about. They give an example of Google not offering suggestions for "sex", which means Google is filtering the input keywords. They then complain that Google doesn't exclude "servercheck keygen" from the result set for "servercheck", which would involve filtering the output set. Google's response will be, quite properly, "Yes, we can look at keywords and not offer any suggestions for a certain set of keywords. But that's not what you're asking. You're asking for us to filter the set of suggestions returned for potentially any set of keywords and remove certain suggestions but not others. And what criteria do we use to decide what's legitimate? "keygen" is entirely legitimate as a keyword for software to let authors generate license keys to issue to buyers of their own software, after all.".
None. There isn't an abstraction layer. This is just a new process for Novell to notify hardware makers when they patch or build a new kernel, get precompiled binary drivers for their newly-built kernel and make them available to users as part of the security-update download of a new kernel package. It's got nothing to do with the actual driver modules, kernel compilation or anything in the software itself.
For the remote desktop, you don't quite grok X11 yet. Any desktop on Linux is automatically remote. That's because even your local desktop is remote, it merely uses a protocol other than TCP on a "connection" that's just linked lists in RAM. The easiest way to get a remote desktop is using XDMCP to log in to the machine you want to use. If you've got an X server on your laptop (Cygwin/X will do), it'll let you set things up easily enough (unfortunately Windows doesn't allow you to replace the Windows desktop, so you'll have to be satisfied with either letting Windows be your window manager and desktop or having your entire X11 desktop in a (possibly full-screen) window). Remote audio takes a bit more, but there's things like NAS that'll allow it. I'm not sure on the setup because I haven't had to set it up (yet).
Actually that isn't the argument made. The argument for dynamically linking to GPL'd libraries is that the program using those libraries has to include at least a small amount of the actual code from those libraries (specifically the header files that define the API) at compile time, and that included code directly contribues a certain amount of binary code in the resulting executable. The GPL doesn't make any exceptions, so you have to either abide by the GPL's terms or not distribute that binary code as part of your executable (which you can't do unless you don't use the library at all). The LGPL was, BTW, created to provide an offical way of allowing this particular use. I personally think that might run afould of fair use, but then again the companies that would most use this loophole have themselves argued that fair use doesn't cover situations similar to this in regards their code and I can't feel sorry for them being bitten by their own position. And, as I noted, the LGPL exists so a creator using the GPL instead is making a statement of intent about his license terms which a court would have to take into account.
Benefits to who? Certainly the costs of SOX compliance outweigh the benefits to the companies that have to comply, but SOX wasn't intended to benefit those companies.
I think all the response this tactic deserves is an icy "If you want to discuss license compliance, let me transfer you to our legal department where someone can assist you.". Then you do just that, making sure your lawyer knows before the MS rep can talk that the rep has stated or implied that you lack licenses for some software.
Of course, also make sure you've got original media and license certificats and keys for every copy of software you've got installed, or relevant current license agreement documentation covering the installed software. Remember that there's what MS might like you to have to produce, then there's what you legally have to or should be able to produce, and the two aren't neccesarily identical.
Perhaps someone needs to point Mr. Winske at Peter Korn's blog entry covering the subject of accessibility in OpenOffice.org. It covers the strong and weak points on both the Windows and Unix platforms.
I for one have. Which is exactly why I'd point someone like this case at them. The two deserve each other. :)
It amuses me that they focus so much on Computer Science enrollment. My experience is that a lot of the best programmers don't have a computer-science degree, or even math- or engineering-related degrees. Out of the last 6 months' worth of applicants I've interviewed where I work, the best one had an education degree. The people with CS degrees have, by contrast, been uniformly lacking in basic programming background and skills. It's not limited to the US either, it goes for the non-US applicants as well.
The thing is, getting in isn't a problem... for those involved in that sort of thing in the first place. Your problem with the barrier is that you aren't the sort who's involved in malware. I see the same thing as a computer programmer. I constantly boggle people with my ability to come up with the most obscure information about computer systems when they've spent literally days searching and haven't found anything. This was true even back 25 years ago when I was in school. What's an insurmountable barrier for a complete outsider evaporates quickly for anyone who's even begun to be involved in the field, mainly because one of the first things you develop is a network of people you can ask about where to look for things.
The thing about walls is that they often depend on your perspective, and one of the hardest things to learn and remember is that your perspective isn't neccesarily the only one.
Where drivers use defined APIs to the kernel without including significant code beyond API declarations and constant definitions (via header files), I don't see any grounds for trying to extend the kernel license to them. And I don't think trying to would be productive. If hardware makers want to go to the trouble of keeping their driver cleanly seperated from kernel internals and keeping up with changes in the kernel APIs and ABIs, I say it's their code and their right. It's a different matter if they start modifying kernel code itself to make their driver work, but if their driver can be plugged into a stock kernel without needing the kernel patched and recompiled, and the driver doesn't contain kernel code beyond what'd be allowed by fair use I can't see an issue.
At the same time, I don't see why the kernel has to cater to those vendors. I don't think kernel driver APIs/ABIs should change arbitrarily just to break proprietary drivers, but I don't think they should be frozen just to accomodate those drivers when there's good, solid technical reasons to justify changes. If the vendors want to keep their drivers proprietary, then they take on all the responsibilities that come with that including keeping up with kernel changes on their own. This will, of course, put the proprietary vendors at a disadvantage and cost them more to maintain the drivers, but that's the choice they made.
I wouldn't encourage proprietary drivers, but I wouldn't ban them either.
Again, when viruses were rampant in the 80s and early 90s it was all private networks with that same supposed barrier, yet it didn't appear to be a significant barrier to new virus writers. They had easy access to the private networks through a completely different community that could provide them with the connections they needed. The only apparent barriers were to the AV companies and other "good guys".
As I noted, the fallacy in your arguments is an unstated one: that what people outside the rootkit-writer community do can hinder communication within the rootkit community in a significant way. This has not been the case in the past, and nobody can point out any changes in the private networks that would change this in the future. When you say "Both would just become harder.", I have to respond "But both haven't become harder any other time your scenario's occurred.".
Except that the rootkit makers have always passed information around on their own private networks. Forcing them underground would change absolutely nothing on their side, and would mean the AV companies would have less info on the rootkits to base their signatures and detection code on. In fact, the nastiest stealthed, encrypted, polymorphic viruses were developed when there was no public circulation of information about the techniques involved.
The problem is that saying that circulation of information helps the rootkit makers has the implicit assumption that anyone outside that community can hinder circulation of information within it. This happens not to be the case.
Actually the all-you-can-eat places do limit the Homer Simpsons and still call it all-you-can-eat. They simply say "all you can eat" means all you personally can eat while you're there. You don't get to take it home with you and eat it later. You don't get to split your meal with your friends. And you don't get to leave and come back the next day and pick up where you left off without paying again.
My ISP is Cox HSI. Where I live their policy is to apply transit caps, but enforcement is mainly limited to habitual high-volume offenders. If you go over the cap occasionally, you won't see anything happen. If you go over by a large amount for an extended period of time, though, you'll find your connection throttled back and possibly face termination of your account for ToS violation. They've had to wield this club quite rarely, as only about 2-3% of customers are problem cases. That small percentage is responsible for about 50% of traffic, so shutting down or throttling even a few of the worst offenders has a significant effect.
If you're buying 2mbit of dedicated bandwidth, then yes you're entitled to it no matter what you do with it. But most people buying broadband connections aren't buying dedicated bandwidth. They're buying shared bandwidth burstable to (for example) 2mbit. In that case, using 2mbit continuously is trying to use something you didn't buy.
It's like my old dial-up ISP. They sold two kinds of accounts: standard dial-up, and dedicated modem lines. With a dedicated line, you bought modems for both ends and a dedicated phone line from your house to the ISP and you were entitled to exclusive use of that connection all the time. A standard dial-up account was not a dedicated line, and the assumption was that you weren't going to be dialed in continuously. So when people bought a standard dial-up account and tried to stay dialed in 24x7, after a bit the ISP sent them a nasty-gram: "Either buy a dedicated line, stop trying to stay dialed in 24 hours a day, or find your account terminated. If you haven't chosen in 10 days, we'll choose #3 for you.". I'd note that a standard dial-up account was $20/month, while a dedicated line started at $120/month and went up depending on distance ($20 for the account, $100 and up for phone company charges for the pair).
Except that the Linux developers mostly don't care whether consumers use Linux or not. Linux is developed because the developers want to do things, not because someone else does. If consumers don't adopt Linux in droves, it'll make precisely zero difference to the development of Linux. This is what's got companies like Real Networks and the media companies worried, Linux simply isn't playing the same game as them:
Other companies: "Hah! Rook to queen's bishop 4. Checkmate!"
Linux: "Nice move. Pity we're playing checkers. <tac><tac><tac> King me."
I think CNet's coming to the wrong conclusions. Firstly, Apple's never going to license OSX on anything but Mac hardware. Control of the hardware's what gives Apple the ability to keep OSX stable and easy to install, they aren't going to give that up. What they've done with Mac-on-Intel and Boot Camp, though, is made buying Apple hardware safe for Windows users: whether you like OSX or not, you will be able to run Windows on your Intel-based Mac. Boot Camp isn't directly intended to let people dual-boot, it's intended as a warm fuzzy "Look, if OSX isn't for you you haven't wasted the price of that nice shiny hardware you bought.".
I think Apple fully intends to have good PC virtualization software as well. Intel hardware will make that easier. At that point they've got an attractive path to migrating people off Windows. They'll be able to say "If you buy a Mac with OSX, you can still run all your Windows software as well as you could on your Windows machine. If it turns out you've got one or two programs (like games) that won't run under the virtualization software, you can dual-boot into Windows if you have to. And if OSX just plain won't work for you, you can just wipe it and run Windows all the time and still have the shiny Mac hardware for people to drool over. If you're buying new hardware anyway, how can you go wrong?".
The problem is, as someone outside Apple I'm not neccesarily obliged not to disclose their trade secrets no matter how much damage my disclosure might do to Apple. In fact, as an outsider the only times I am obliged to keep their secrets are if a) I've signed a binding NDA with them or b) I'm aware when the information's given to me that it's being given in violation of an NDA or other obligation not to disclose it. The burden of maintaining secrecy falls almost entirely on Apple, and if they fail to maintain secrecy then it's almost entirely their problem, not mine. Note that in general trade secrets have no protection in law, the only things enforceable by law are agreements not to disclose certain information.
If a company came at me for disclosing trade secrets, the first thing I'd demand of them is that they identify exactly what agreement obliged me to maintain those secrets and to prove that I'd in fact signed that agreement. If they couldn't or wouldn't, I'd invite them to go pound sand (or, if they were suing me, I'd ask the judge for an immediate dismissal with prejudice and to be awarded costs). I wouldn't waste time on First Amendment or "I didn't disclose anything" arguments, I'd go straight for "I've no duty not to disclose".