As 'nice' as a clean architecture, specification, unit tests, etc sound, in practice I have observed problems: -Companies *still* think good software is done by larger development teams, and that a consensus is critical to acheive quality product. Everyone sits around, gives feedback, and lets other people provide their feedback out of being civil. This takes an eternity, and without some person stepping up to be the asshole who gets his way, a lack of consistent vision leads toward everyone marching toward mediocrity. As a result, I've found that a project with fewer developers who maybe touch base briefly once a week better than teams that have 2 hour meetings to ensure they are in 'lock-step' every other day. Good developers know when to touch base and sync up, and they also know when to just shut up even when they think their idea is better (if everyone insisted on getting the 'best' idea in instead of just getting the good idea in, projects just stall). -People invest so much time writing specs to code for that might be as well suited just to code up a prototype and describe it as a 'reference' implementation rather than trying to plan everything without touching code at all. For me, my mind just logically realizes fault with a design when coding that I wouldn't think of when writing it up in specs. -Unit tests are a mixed bag. They can catch carelessness, but exacerbate the problem of developer misunderstanding/miscommunication as they gain a false sense of security seeing unit tests pass (and they take a long time to develop, and if a modules interactions are sufficiently complex, impossible to get decent coverage). -What I describe was hinted at (though no one dared question unit tests) when I was taking software engineering. Unfortunately, the class was wrapped in buzzwords like 'extreme programming', 'agile processes', and functional requirements were supposed to be thought of in terms of 'user stories'. Hidden behind those buzzwords were grains of truth, however, as I saw the concepts 'adopted' by some software development shops, I really saw use of buzzwords with no meaning. 'User stories' even when called that ended up being the same thing that functional requirements have always been. Words like agile are attached to processes that will expend months of planning without a single line of code, then lock into the design and say nothing can change without a miracle even if the coding demonstrates something was really wrong with the design.
In summary, I think a *lot* of the process-heavy shops/projects have the heavy process in place to compensate for mediocre programmers. The thought is that a team of a dozen programmers is important, and impossible to afford with good talent. The reality is a typical dozen-man team can be replaced by 3 or 4 really good developers with strong vision and produce a much better product in much shorter time. Don't try to get more developers, just get fewer, better programmers and don't saddle them with trying to pull the dead weight of an unskilled team.
I've seen the flip side though. I've seen a project spend nearly as much time writing unit tests to a spec as they do writing to the spec.
To make matters even worse, often times the problem is not a mistake when the programmer mistyped, but a mistake in the spec or the programmer's understanding of the spec, leading to a unit test that passes fine, but the code is spewing out garbage. I've seen fixes go into code that break unit tests, and they then have to fix the unit test.
At the same time, the marketing layer between development and customers can sometimes be detrimental, particularly if the customers in a particular segment are more in line with the developers than the marketing dept is.
I've seen some highly technical customers approach provide feedback to a company's marketing dept. That marketing dept, without firmly 'getting' it, distill it into abstract marketing bullet points, and pass it to development. Development releases a product, and the customer says 'wtf is this?'. This is mostly an artifact of companies pigeon-holing people into roles without regard for their specific market needs. These are the environments where open source particularly eats into traditional commercial product mindshare, as the marketing abstraction layer is transparent if it is there at all.
Now I recognize that in most scenarios, the users and developers are not as much on the same page as marketing and users, but what really should be valued is people who could do well in either field, so that they can understand the customer requirements intimitely, and yet understand what it really takes to fulfill those criteria.
The scoping mechanism I agree is awful, but it's also one reason I am also frustrated by python for sophisticated applications. I have not found a way to acheive more granularity than Javascript in Python apps (i.e. arbitrary block scope). One may fairly argue that they feel those circumstances should be broken up into functions if it seems required to have a block-scoped variable, but sometimes it just works better to know before a function ends that you will get errors if you accidentally use that variable where you didn't intend and spinning off functions could be awkward.
However, I recognize that Python's vision of a more straightforward paradigm would be compromised by that feature. For python, it's not so bad as it isn't a mandatory standard and usually lives alongside other intepreters with different goals. I do agree that Javascript is a larger problem, since every language that you could implement in a browser must be ultimately executed under Javascript, and thus choosing an alternative if it doesn't suit your needs isn't as viable.
I know it is very capable, flexible, and many frameworks exist to shortcut many common sequences of javascript used in sophisticated application development. I can respect a Javascript developer and not doubt for a minute they can code up fully capable stuff (particularly in conjution with HTML5 features including canvas). I won't claim that Javascript doesn't have a decent debugging strategy (i.e. firebug). I even appreciate the fact that sometimes, the community is better of just picking *something* and sticking with it in the name of standardization even if something universally more popular yet not much more featureful comes along.
However, while I recognize that what I can do isn't so different from what I can do in other languages, it is how I have to do it. I find the syntax to share too many of the characteristics I find distasteful about Java, namely typically tedious steps to do most of what I want. Some of it is the language itself, some of it is the relative complexity of manipulating HTML DOM elements and CSS compared to most modern desktop APIs, and some more of it is the network access model being a bit more limited than arbitrary sockets for certain tasks. Writing a Perl GTK program or a WxWidgets in Python (though I'm less fond of Wx) is, to me, just a lot easier than Javascript/HTML/CSS environments.
It can hurt in the long term and the short term. You get too many bright people on a project and it takes forever to reach consensus on entirely too much. Particularly if each is passionate about the entire product beyond their small piece and have strong opinions/vision about how it should be done. Especially if they are users/fans of their own software.
First off, people keep saying 'disks never report bad blocks until they've exceeded their bad block count'. That is just wrong, it holds true for write operations, but it *cannot* magically do that on read (if it could read the sector, it isn't an error, if it can't, than it certainly can't reconstruct the data that it is missing. There may be some more complications involved, but that describes one scenario accurately.
If the bad sector relocation count is exceeded, then the drive is failed. Maybe frequent relocations before exhausting that overhead would be a sign too, but a one-off bad block on read is not something to be overly worried about.
Enterprise arrays that have native filesystem virtualisation
Do we really have to put the word 'virtualisation' on everything? I don't see what aspect of the concept is remote 'virtual'. Filesystem-level or filesystem aware RAID schemes I wouldn't mind, but 'virtualisation' is being tossed around to the point of becoming a meaningless buzzword, completely stripped of its original, specific meaning.
Other than that one word, I agree with the sentiment. RAID is a sufficiently generecized concept that can cover the dumbest array configs (unclean arrays require full device resync, one bad sector read putting an array into degraded mode instantly, no filesystem awareness resorting in managing unimportant data) to smarter cases (unclean arrays being a near impossibility or resync aided by a journal to know which specific parts could have stale parity, bad sector read inducing sector rewrite if hard drive can still rewrite and issueing a warning, and schemes that know the difference between used and unused space). If you focus on the low end and think it the end-all, be-all of RAID, then yes, you'll think it's in need of immediate attention. If you understand the more sophisticated implementations, you'll realize it scales no worse than the data you use.
Take the recent MS Word injunction. Now, we can argue about the validity of the patent in question there, but regardless of that point, everyone *knew* that MS would not have to cease and desist distribution of Word, not because the patent was bs, but because MS is just too resourceful and end the end, perceived as 'too big to fail'.
On the flipside, MS can crush a threatening smaller company even if the patent is flimsier. The smaller company will not have the benefit of as many legal resources to start with, and also would not have people thinking "I can't be the one to screw the largest software company in the US".
As it stands in the software industry, a vast majority of the financial resources are controlled by companies that can abuse their disproportionate share to game the patent system enough to win more than lose and feel confident they will always win more than lose.
The fact is, in any product, people jump ship to 'something else'. They may jump from OSS to commercial, from commercial to commercial, from commercial to OSS, or OSS to OSS. The OSS aspect of it is a feature for some, but its the total featureset that gets compared. Sometimes, something is just better than something else. An anecdote about some hobbyists 30 minute hack behaving more poorly than a commercial product with man-years of polish behind it is about as useful as comparing some untalented developers get-rich-quick startup software hammered out in a rush for venture capital against a venerable project like Apache.
But there has to be a happy medium on the endusermarketingdevelopment gap. I've seen way too many cases where users really know what they want, it gets filtered through marketing that doesn't fundamentally feel the problem directly or even understand the field that well distill it into marketing points for development to fulfill, and development writing to these points and the user ending up with a mess.
However, that is luck of the draw, regardless of commercial or open-source. I've come into many commercial projects where I fight security issues. Most developers get a few small 'best-practices' on security, frequently without context. For example, most every developer has 'buffer-overrun' burned into his mind and either avoid C or always use strncpy/snprintf/etc rather than the alternatives. And for many, that's the end of what they think of when you say 'vulnerability' without a specific example. Aside from the easily taught examples like that, most developers (commercial or open-source) never take the time to understand the context of their design in security.
Out of curiosity, I would like to know the details of this vulnerability that exposed you though.
1. Both sides of the coin have problems here. On the commercial side, the paid-for testers have their input dismissed if they say the intentional user interaction design decisions of development were wrong. If they find behavior that deviates from the specification, developers will fix, but if it 'works as designed', the testers will almost always be ignored. The converse happens in OSS world, there isn't much strict specification cross-checking, but when testers take issue with design choices, their chances of being heard (since the line between 'real user' and 'tester' is blurred) are higher. 2. A given, depending on the project. Some commercial projects can be bad, but I will agree that open source projects will tend to the documentation last. 3. While this is important, I do think it shouldn't be considered as useful as it is. I've seen people feel overconfident because they have automated testing. It is good at catching some mistakes, but bad at catching others like fundamental misunderstanding. I've seen where someone implemented their code poorly because they thought it needed to do something, and then implemented a test case that passes because they had the wrong assumption when they wrote both pieces of code. 4. That never happens in the commercial space... oh wait..... 5. does the fact that there exists Ford, Chevy, Toyota, Honda, Hyundai, Daihatsu, Daewoo, Pontiac, Saturn, Lincoln, Mercury, Cadillac, Buick, Mazda, Porsche, Jaguar, Jeep, Dodge, Land Rover, Ferrari, Fiat, and more each selling many different models of car make it 'just too difficult to choose' a car? I'll never understand people who say 'there's too much choice' in OSS when in every other market other than Operating systems, there are generally a lot more prominent viable choices than there are in Linux distributions. 6. I'm not sure how that is distinct between proprietary and open solutions. If you mean you love the registry mess, then blissfully ignore the market outside of those using gConf. However, I doubt you manipulate the raw data in regedit for everything, but prefer the configuration dialogs of the applications themselves (I'm not going to add an ssh host key through regedit for PuTTY for example). 7. The unix framework is not mature anymore? I suppose you meant 'modern', as it is certainly mature. If you are rehashing the tired old trolling about X, I have a tear-free compositing desktop on par with OSX and Windows. Admittedly, they are restructuring the memory management framework for better performance in linux specifically, but that's not 'UNIX framework'. 8. Again with the choices. Pick one and pretend the rest don't exist if you are that bothered. 9. If anyone violates this for me it is commercial software. I have seen cases where it seems they intentionally make something seem a big production when it could be quite straightforward (to make someone feel like the job is a big deal and worthy of paying money for it). 10. Again, to me that is more a problem with commercial software that requires marketing bullet point accumulation to justify upgrades.
Windows also enables IPv6 by default. For any well written app, one of two things should happen in the face of IPv6 if an IPv4 identity also exists: -The app hasn't gone to the new IPv6 capable APIs, in which case, it will only work on IPv4 -The app has used the new APIs, and used them correctly such that it is agnostic as to whether IPv6 or IPv4. I've never seen a problem like you describe, so I would be interesting if you have a link to a discussion on it so I could understand how the software messed up here.
Incidentally, I agree that VNC is tortuously slow. That's why I use NX. My gripe there is that FreeNX has not been a solid, quality project, but I'm hoping that Google's attention in 'NeatX' will turn that around.
I know with IBM, you can set it up to call home and automatically order parts.
I.e. one day an IBM service person shows up on your doorstep with a new hard drive without anyone ever having even noticed a hotspare is in use in the storage subsystem. They probably would be perfectly fine with talking over the phone and coordinating remotely with an administrator in the event it is something that requires downtime to replace.
I wholeheartedly agree that IPMI is very much underrated. When I hear 'buzz' about management protocols, it is almost always about SMASH, CIM, WS-MAN, etc, and IPMI is never mentioned. Of those, I've found IPMI to be the most direct, straightforward, unambiguous protocol. If two vendors implement IPMI, I can probably do everything I want to those boxes with the exact same commands (i.e. power off is *always*, underneath the implementing utilities, the specific byte sequence 0 2 0). If two vendors say they support any of the other 'standards', who knows if they will work together as things even as basic as 'turn the damn server off' may have entirely different syntaxes and still be compliant. Add to that the sheer amount of work to write scripts to manage anything other than IPMI is generally verbose.
SMASH just describes vague strategies rather than precise 'verbs' to implement and how to do so. CIM/WS-MAN seems to be more concerned about abstracting away details of in-band management of an OS rather than sanely addressing out-of-band management. On that front, I still don't quite get it. By abstracting the implementation specific details of an OS to 'common' looks, I feel it ends up being something harder to manage and less powerful than simply targeting each OS in turn (the OSes differ for good reason, generally.
Anyway, I just saw a rare opportunity to rant about the state of DMTF standards. IPMI is overlooked because in this age of everything having to be XML, done over HTTP, and open-ended to the point of uselessness, it is a protocol that is binary data over udp datagrams that tells the vendors they *will* implement almost everything an administrator needs from hardware management in very precise ways.
I concur that IPMI is your friend, but IPMI does not include 'remote media' (or remote video). Those are implemented as proprietary extensions by the like of IBM and such.
However, I use netboot and SOL (the former is mostly unrelated to IPMI, except there is a standard to choose a boot device, and the later is part of IPMI 2.0). Using the remote video and remote media ends up being a pain in a multivendor situation since they are implemented differently, and SOL (even for Windows) is sufficient for when ssh or RDP doesn't work.
Out of any sufficiently large community, some will engage in the sort of things you describe, or similar or complementary things. Corporate marketing campaigns are largely relying upon evoking those sentiments in the people they target (irrational 'we're #1' mentality without substantial real justification).
1) The chances of making every last Linux user refrain from that are about as likely as having every last Windows user refrain from considering every last willing Linux user an elitist snob who engages in what you describe.
2) That is true, though the severity of your example is far far less bad. I would use one of the various local privelege escalation vulnerabilities (some which were in the kernel undiscovered almost as long as this was in Windows), though even that isn't quite as severe as an unprivileged remote access crash in some measures (in others, admittedly, DoS is much less bad than privilege escalation, though I rarely hear of Windows infrastructures banking on avoiding local privilege escalation much).
3) Again, this may be true of some of the community, it is also true of Windows community (look at a few random message boards, you'll see windows users looking equally foolish)
4) I don't see a correlation between meme-spouting and linux usage. I also see no evidence that Linux people like xkcd any more than non-linux people (though I don't see how xkcd is construed as a particularly bad thing).
In short, if you want a community larger than 30-50 people that is completely devoid of people who fail to meet your standards, you might as well give up on any community.
One could infer that the presence of that elective addon and the fact it has hashes defined means the person has stuff to hide. In some legal situations, that would be sufficient, but generally the worry that is supposed to address is friends and family...
Javascript is powerful, but I would not call it 'awesome'. It is very verbose and has very peculiar ways about it. Javascript frameworks alleviate some of the pain with nice functions like '$' to do getElementsById, but fancier even, but some of the weirdness still shines through.
Also, Javascript is only as powerful as the primitives exposed by the interpreter. For example, try writing a hardware accelerated 3D application in javascript. The language could describe such a thing, but as it stands it has no hooks to manipulate such a thing.
With respect to thousands of paths, it is a reality when you can do thousands of 'things'. You can't have 5 total things that you can possible describe to the computer and achieve anything more than 5 actions. Basically, GUI doesn't scale as well with general capability as CLI does. Now, the argument about 'normal' end-user software is valid, but where does the line get drawn between 'normal' and 'non-normal' user actions? If you draw the line wrong, you just pollute the 'normal' user view with extraneous stuff they have to wade through as they search for what they want to do.
On the one hand, I agree. Personally, too much of what I do is influenced by business leadership who have no personal insight as to what is good technology, yet insist on demanding certain technical decisions based on flashy demos rather than merit. I would be fine working with experience business leadership, or leadership willing to delegate, but we have too many business leaders that come for the high-growth business without the experience, and in order to make themselves feel relevant, attend technology demos and demand their favorite be used, even if the product has zero ability to be scripted or used at all from a CLI simply because it has a web interface that has the shiniest graphics.
Of course, it also means some tolerance of OSS and such may decrease, as the money handlers that do trust the technology to work out in the end start demanding to correlate quantifiable, tangible benefit for transactions. I think there is a lot of value, but placing a dollar value on it is difficult to do in a way that is absolutely believed by someone else.
And of course, this means less money invested in the industry and less money to fund those of us who would have been here regardless of the boom. I suspect the most passionate may not be the last to go, rather the more business oriented will probably wring out the last dollars before the tech people would be able to.
The xbox membership cost is not universal either, PS3 and Wii have no such cost. Also, the broadband is optional on the consoles, as they can play offline. Multiplayer requires less than the Onlive does in terms of latency and throughput.
Oh, and just to add, if they are fully anticipating dropping frames, this means they will be able to take advantage of keyframes in encoding less often to avoid large penalties for having to drop frames. If they had a keyframe every 30 seconds, one dip could knock off video quality for 30 seconds. Therefore, their encoding requirements will be even higher.
Slashdot Mirror
As 'nice' as a clean architecture, specification, unit tests, etc sound, in practice I have observed problems:
-Companies *still* think good software is done by larger development teams, and that a consensus is critical to acheive quality product. Everyone sits around, gives feedback, and lets other people provide their feedback out of being civil. This takes an eternity, and without some person stepping up to be the asshole who gets his way, a lack of consistent vision leads toward everyone marching toward mediocrity. As a result, I've found that a project with fewer developers who maybe touch base briefly once a week better than teams that have 2 hour meetings to ensure they are in 'lock-step' every other day. Good developers know when to touch base and sync up, and they also know when to just shut up even when they think their idea is better (if everyone insisted on getting the 'best' idea in instead of just getting the good idea in, projects just stall).
-People invest so much time writing specs to code for that might be as well suited just to code up a prototype and describe it as a 'reference' implementation rather than trying to plan everything without touching code at all. For me, my mind just logically realizes fault with a design when coding that I wouldn't think of when writing it up in specs.
-Unit tests are a mixed bag. They can catch carelessness, but exacerbate the problem of developer misunderstanding/miscommunication as they gain a false sense of security seeing unit tests pass (and they take a long time to develop, and if a modules interactions are sufficiently complex, impossible to get decent coverage).
-What I describe was hinted at (though no one dared question unit tests) when I was taking software engineering. Unfortunately, the class was wrapped in buzzwords like 'extreme programming', 'agile processes', and functional requirements were supposed to be thought of in terms of 'user stories'. Hidden behind those buzzwords were grains of truth, however, as I saw the concepts 'adopted' by some software development shops, I really saw use of buzzwords with no meaning. 'User stories' even when called that ended up being the same thing that functional requirements have always been. Words like agile are attached to processes that will expend months of planning without a single line of code, then lock into the design and say nothing can change without a miracle even if the coding demonstrates something was really wrong with the design.
In summary, I think a *lot* of the process-heavy shops/projects have the heavy process in place to compensate for mediocre programmers. The thought is that a team of a dozen programmers is important, and impossible to afford with good talent. The reality is a typical dozen-man team can be replaced by 3 or 4 really good developers with strong vision and produce a much better product in much shorter time. Don't try to get more developers, just get fewer, better programmers and don't saddle them with trying to pull the dead weight of an unskilled team.
I've seen the flip side though. I've seen a project spend nearly as much time writing unit tests to a spec as they do writing to the spec.
To make matters even worse, often times the problem is not a mistake when the programmer mistyped, but a mistake in the spec or the programmer's understanding of the spec, leading to a unit test that passes fine, but the code is spewing out garbage. I've seen fixes go into code that break unit tests, and they then have to fix the unit test.
At the same time, the marketing layer between development and customers can sometimes be detrimental, particularly if the customers in a particular segment are more in line with the developers than the marketing dept is.
I've seen some highly technical customers approach provide feedback to a company's marketing dept. That marketing dept, without firmly 'getting' it, distill it into abstract marketing bullet points, and pass it to development. Development releases a product, and the customer says 'wtf is this?'. This is mostly an artifact of companies pigeon-holing people into roles without regard for their specific market needs. These are the environments where open source particularly eats into traditional commercial product mindshare, as the marketing abstraction layer is transparent if it is there at all.
Now I recognize that in most scenarios, the users and developers are not as much on the same page as marketing and users, but what really should be valued is people who could do well in either field, so that they can understand the customer requirements intimitely, and yet understand what it really takes to fulfill those criteria.
The scoping mechanism I agree is awful, but it's also one reason I am also frustrated by python for sophisticated applications. I have not found a way to acheive more granularity than Javascript in Python apps (i.e. arbitrary block scope). One may fairly argue that they feel those circumstances should be broken up into functions if it seems required to have a block-scoped variable, but sometimes it just works better to know before a function ends that you will get errors if you accidentally use that variable where you didn't intend and spinning off functions could be awkward.
However, I recognize that Python's vision of a more straightforward paradigm would be compromised by that feature. For python, it's not so bad as it isn't a mandatory standard and usually lives alongside other intepreters with different goals. I do agree that Javascript is a larger problem, since every language that you could implement in a browser must be ultimately executed under Javascript, and thus choosing an alternative if it doesn't suit your needs isn't as viable.
I know it is very capable, flexible, and many frameworks exist to shortcut many common sequences of javascript used in sophisticated application development. I can respect a Javascript developer and not doubt for a minute they can code up fully capable stuff (particularly in conjution with HTML5 features including canvas). I won't claim that Javascript doesn't have a decent debugging strategy (i.e. firebug). I even appreciate the fact that sometimes, the community is better of just picking *something* and sticking with it in the name of standardization even if something universally more popular yet not much more featureful comes along.
However, while I recognize that what I can do isn't so different from what I can do in other languages, it is how I have to do it. I find the syntax to share too many of the characteristics I find distasteful about Java, namely typically tedious steps to do most of what I want. Some of it is the language itself, some of it is the relative complexity of manipulating HTML DOM elements and CSS compared to most modern desktop APIs, and some more of it is the network access model being a bit more limited than arbitrary sockets for certain tasks. Writing a Perl GTK program or a WxWidgets in Python (though I'm less fond of Wx) is, to me, just a lot easier than Javascript/HTML/CSS environments.
It can hurt in the long term and the short term. You get too many bright people on a project and it takes forever to reach consensus on entirely too much. Particularly if each is passionate about the entire product beyond their small piece and have strong opinions/vision about how it should be done. Especially if they are users/fans of their own software.
Hence why it is a warning condition.
First off, people keep saying 'disks never report bad blocks until they've exceeded their bad block count'. That is just wrong, it holds true for write operations, but it *cannot* magically do that on read (if it could read the sector, it isn't an error, if it can't, than it certainly can't reconstruct the data that it is missing. There may be some more complications involved, but that describes one scenario accurately.
If the bad sector relocation count is exceeded, then the drive is failed. Maybe frequent relocations before exhausting that overhead would be a sign too, but a one-off bad block on read is not something to be overly worried about.
Enterprise arrays that have native filesystem virtualisation
Do we really have to put the word 'virtualisation' on everything? I don't see what aspect of the concept is remote 'virtual'. Filesystem-level or filesystem aware RAID schemes I wouldn't mind, but 'virtualisation' is being tossed around to the point of becoming a meaningless buzzword, completely stripped of its original, specific meaning.
Other than that one word, I agree with the sentiment. RAID is a sufficiently generecized concept that can cover the dumbest array configs (unclean arrays require full device resync, one bad sector read putting an array into degraded mode instantly, no filesystem awareness resorting in managing unimportant data) to smarter cases (unclean arrays being a near impossibility or resync aided by a journal to know which specific parts could have stale parity, bad sector read inducing sector rewrite if hard drive can still rewrite and issueing a warning, and schemes that know the difference between used and unused space). If you focus on the low end and think it the end-all, be-all of RAID, then yes, you'll think it's in need of immediate attention. If you understand the more sophisticated implementations, you'll realize it scales no worse than the data you use.
At least microsoft on the whole wouldn't...
Take the recent MS Word injunction. Now, we can argue about the validity of the patent in question there, but regardless of that point, everyone *knew* that MS would not have to cease and desist distribution of Word, not because the patent was bs, but because MS is just too resourceful and end the end, perceived as 'too big to fail'.
On the flipside, MS can crush a threatening smaller company even if the patent is flimsier. The smaller company will not have the benefit of as many legal resources to start with, and also would not have people thinking "I can't be the one to screw the largest software company in the US".
As it stands in the software industry, a vast majority of the financial resources are controlled by companies that can abuse their disproportionate share to game the patent system enough to win more than lose and feel confident they will always win more than lose.
The fact is, in any product, people jump ship to 'something else'. They may jump from OSS to commercial, from commercial to commercial, from commercial to OSS, or OSS to OSS. The OSS aspect of it is a feature for some, but its the total featureset that gets compared. Sometimes, something is just better than something else. An anecdote about some hobbyists 30 minute hack behaving more poorly than a commercial product with man-years of polish behind it is about as useful as comparing some untalented developers get-rich-quick startup software hammered out in a rush for venture capital against a venerable project like Apache.
But there has to be a happy medium on the endusermarketingdevelopment gap. I've seen way too many cases where users really know what they want, it gets filtered through marketing that doesn't fundamentally feel the problem directly or even understand the field that well distill it into marketing points for development to fulfill, and development writing to these points and the user ending up with a mess.
However, that is luck of the draw, regardless of commercial or open-source. I've come into many commercial projects where I fight security issues. Most developers get a few small 'best-practices' on security, frequently without context. For example, most every developer has 'buffer-overrun' burned into his mind and either avoid C or always use strncpy/snprintf/etc rather than the alternatives. And for many, that's the end of what they think of when you say 'vulnerability' without a specific example. Aside from the easily taught examples like that, most developers (commercial or open-source) never take the time to understand the context of their design in security.
Out of curiosity, I would like to know the details of this vulnerability that exposed you though.
1. Both sides of the coin have problems here. On the commercial side, the paid-for testers have their input dismissed if they say the intentional user interaction design decisions of development were wrong. If they find behavior that deviates from the specification, developers will fix, but if it 'works as designed', the testers will almost always be ignored. The converse happens in OSS world, there isn't much strict specification cross-checking, but when testers take issue with design choices, their chances of being heard (since the line between 'real user' and 'tester' is blurred) are higher.
2. A given, depending on the project. Some commercial projects can be bad, but I will agree that open source projects will tend to the documentation last.
3. While this is important, I do think it shouldn't be considered as useful as it is. I've seen people feel overconfident because they have automated testing. It is good at catching some mistakes, but bad at catching others like fundamental misunderstanding. I've seen where someone implemented their code poorly because they thought it needed to do something, and then implemented a test case that passes because they had the wrong assumption when they wrote both pieces of code.
4. That never happens in the commercial space... oh wait.....
5. does the fact that there exists Ford, Chevy, Toyota, Honda, Hyundai, Daihatsu, Daewoo, Pontiac, Saturn, Lincoln, Mercury, Cadillac, Buick, Mazda, Porsche, Jaguar, Jeep, Dodge, Land Rover, Ferrari, Fiat, and more each selling many different models of car make it 'just too difficult to choose' a car? I'll never understand people who say 'there's too much choice' in OSS when in every other market other than Operating systems, there are generally a lot more prominent viable choices than there are in Linux distributions.
6. I'm not sure how that is distinct between proprietary and open solutions. If you mean you love the registry mess, then blissfully ignore the market outside of those using gConf. However, I doubt you manipulate the raw data in regedit for everything, but prefer the configuration dialogs of the applications themselves (I'm not going to add an ssh host key through regedit for PuTTY for example).
7. The unix framework is not mature anymore? I suppose you meant 'modern', as it is certainly mature. If you are rehashing the tired old trolling about X, I have a tear-free compositing desktop on par with OSX and Windows. Admittedly, they are restructuring the memory management framework for better performance in linux specifically, but that's not 'UNIX framework'.
8. Again with the choices. Pick one and pretend the rest don't exist if you are that bothered.
9. If anyone violates this for me it is commercial software. I have seen cases where it seems they intentionally make something seem a big production when it could be quite straightforward (to make someone feel like the job is a big deal and worthy of paying money for it).
10. Again, to me that is more a problem with commercial software that requires marketing bullet point accumulation to justify upgrades.
Windows also enables IPv6 by default. For any well written app, one of two things should happen in the face of IPv6 if an IPv4 identity also exists:
-The app hasn't gone to the new IPv6 capable APIs, in which case, it will only work on IPv4
-The app has used the new APIs, and used them correctly such that it is agnostic as to whether IPv6 or IPv4.
I've never seen a problem like you describe, so I would be interesting if you have a link to a discussion on it so I could understand how the software messed up here.
Incidentally, I agree that VNC is tortuously slow. That's why I use NX. My gripe there is that FreeNX has not been a solid, quality project, but I'm hoping that Google's attention in 'NeatX' will turn that around.
I know with IBM, you can set it up to call home and automatically order parts.
I.e. one day an IBM service person shows up on your doorstep with a new hard drive without anyone ever having even noticed a hotspare is in use in the storage subsystem. They probably would be perfectly fine with talking over the phone and coordinating remotely with an administrator in the event it is something that requires downtime to replace.
I wholeheartedly agree that IPMI is very much underrated. When I hear 'buzz' about management protocols, it is almost always about SMASH, CIM, WS-MAN, etc, and IPMI is never mentioned. Of those, I've found IPMI to be the most direct, straightforward, unambiguous protocol. If two vendors implement IPMI, I can probably do everything I want to those boxes with the exact same commands (i.e. power off is *always*, underneath the implementing utilities, the specific byte sequence 0 2 0). If two vendors say they support any of the other 'standards', who knows if they will work together as things even as basic as 'turn the damn server off' may have entirely different syntaxes and still be compliant. Add to that the sheer amount of work to write scripts to manage anything other than IPMI is generally verbose.
SMASH just describes vague strategies rather than precise 'verbs' to implement and how to do so. CIM/WS-MAN seems to be more concerned about abstracting away details of in-band management of an OS rather than sanely addressing out-of-band management. On that front, I still don't quite get it. By abstracting the implementation specific details of an OS to 'common' looks, I feel it ends up being something harder to manage and less powerful than simply targeting each OS in turn (the OSes differ for good reason, generally.
Anyway, I just saw a rare opportunity to rant about the state of DMTF standards. IPMI is overlooked because in this age of everything having to be XML, done over HTTP, and open-ended to the point of uselessness, it is a protocol that is binary data over udp datagrams that tells the vendors they *will* implement almost everything an administrator needs from hardware management in very precise ways.
I concur that IPMI is your friend, but IPMI does not include 'remote media' (or remote video). Those are implemented as proprietary extensions by the like of IBM and such.
However, I use netboot and SOL (the former is mostly unrelated to IPMI, except there is a standard to choose a boot device, and the later is part of IPMI 2.0). Using the remote video and remote media ends up being a pain in a multivendor situation since they are implemented differently, and SOL (even for Windows) is sufficient for when ssh or RDP doesn't work.
Out of any sufficiently large community, some will engage in the sort of things you describe, or similar or complementary things. Corporate marketing campaigns are largely relying upon evoking those sentiments in the people they target (irrational 'we're #1' mentality without substantial real justification).
1) The chances of making every last Linux user refrain from that are about as likely as having every last Windows user refrain from considering every last willing Linux user an elitist snob who engages in what you describe.
2) That is true, though the severity of your example is far far less bad. I would use one of the various local privelege escalation vulnerabilities (some which were in the kernel undiscovered almost as long as this was in Windows), though even that isn't quite as severe as an unprivileged remote access crash in some measures (in others, admittedly, DoS is much less bad than privilege escalation, though I rarely hear of Windows infrastructures banking on avoiding local privilege escalation much).
3) Again, this may be true of some of the community, it is also true of Windows community (look at a few random message boards, you'll see windows users looking equally foolish)
4) I don't see a correlation between meme-spouting and linux usage. I also see no evidence that Linux people like xkcd any more than non-linux people (though I don't see how xkcd is construed as a particularly bad thing).
In short, if you want a community larger than 30-50 people that is completely devoid of people who fail to meet your standards, you might as well give up on any community.
One could infer that the presence of that elective addon and the fact it has hashes defined means the person has stuff to hide. In some legal situations, that would be sufficient, but generally the worry that is supposed to address is friends and family...
Javascript is powerful, but I would not call it 'awesome'. It is very verbose and has very peculiar ways about it. Javascript frameworks alleviate some of the pain with nice functions like '$' to do getElementsById, but fancier even, but some of the weirdness still shines through.
Also, Javascript is only as powerful as the primitives exposed by the interpreter. For example, try writing a hardware accelerated 3D application in javascript. The language could describe such a thing, but as it stands it has no hooks to manipulate such a thing.
Which is exactly the sort of thing that the 'tethering' app enables.
Of course, it's a pain manually because a certain binary (unless hexedited) will keep zapping ip_forward. (PmConnectionManager)
With respect to thousands of paths, it is a reality when you can do thousands of 'things'. You can't have 5 total things that you can possible describe to the computer and achieve anything more than 5 actions. Basically, GUI doesn't scale as well with general capability as CLI does. Now, the argument about 'normal' end-user software is valid, but where does the line get drawn between 'normal' and 'non-normal' user actions? If you draw the line wrong, you just pollute the 'normal' user view with extraneous stuff they have to wade through as they search for what they want to do.
On the one hand, I agree. Personally, too much of what I do is influenced by business leadership who have no personal insight as to what is good technology, yet insist on demanding certain technical decisions based on flashy demos rather than merit. I would be fine working with experience business leadership, or leadership willing to delegate, but we have too many business leaders that come for the high-growth business without the experience, and in order to make themselves feel relevant, attend technology demos and demand their favorite be used, even if the product has zero ability to be scripted or used at all from a CLI simply because it has a web interface that has the shiniest graphics.
Of course, it also means some tolerance of OSS and such may decrease, as the money handlers that do trust the technology to work out in the end start demanding to correlate quantifiable, tangible benefit for transactions. I think there is a lot of value, but placing a dollar value on it is difficult to do in a way that is absolutely believed by someone else.
And of course, this means less money invested in the industry and less money to fund those of us who would have been here regardless of the boom. I suspect the most passionate may not be the last to go, rather the more business oriented will probably wring out the last dollars before the tech people would be able to.
The xbox membership cost is not universal either, PS3 and Wii have no such cost. Also, the broadband is optional on the consoles, as they can play offline. Multiplayer requires less than the Onlive does in terms of latency and throughput.
Oh, and just to add, if they are fully anticipating dropping frames, this means they will be able to take advantage of keyframes in encoding less often to avoid large penalties for having to drop frames. If they had a keyframe every 30 seconds, one dip could knock off video quality for 30 seconds. Therefore, their encoding requirements will be even higher.