I have not seen anyone touch on the methodology and philosophy of the software lifecycle as a determining factor in this so-called 'scripting bias':
I see shops that only work with the waterfall lifecycle - and they have a tendency to produce code that is minimally useful, particularly if their discovery techniques with key users is inadequate. While lip service is given to 'maintainable code', it is usually horrid to maintain, regardless of the ease of maintaining a consistent code base - particularly since the design itself is flawed. Rebuilding a flawed design is not maintenance. Corrections can take months or years as each request undergoes the scrutiny of the revision control process (a truely draconian process in some organizations). These shops have a tendency to only do one or two languages (C++ and Java usually) well.
There is a more progressive philosophy that views the project, and its lifecycle as an ever expanding spiral that allows iterative design, code, test, evaluate results and schedule, rinse and repeat. These projects tend to have frequent code releases, multiple mockups, and encompass the real needs of the end user community, when all is said and done. Maintenance is a snap because: A) The users get what they need, thus don't put in change/enhancement requests right off the bat, and B) Most maintenance activities center around fixing bugs as opposed to recreating the application. This methodology lends itself to multiple languages and scripting - since the main focus is to get the job done right.
~~
I have witnessed several waterfall projects that extended over 5 or more years and to this day do not fill the needs of the user base (most of which ended up using glue - like embedded macro languages or scripting to fill in the gaps). It seems to me that more than any other, this is a method of ensuring large numbers of mediocre programmers employment over extended periods of time.
On the other hand, I have used iterative design, and have had success upon success, with a minimal cost in time and resources - since I am free to utilize the right tool for each job as needed based upon an solid risk accessment. I think this methodology is rarely used in most established 'code factories'.
This also manifests itself in how we think of our end user communities. Just as the BOFH complains about stupid 'Lusers', I think there is a lack of respect for the people who have to actually live with the products we produce. This is getting the cart before the horse, for without the users there would be no need for programmers or 'scripters' for that matter.
Of course, I could be completely off base, biased by my limited view of the world. Right.
Another thing I have found interesting is the amount of 'glue' that needed in complex and crufty systems alike.
Perhaps your company has an old Cobol or Fortran application that runs to hundreds of thousands of lines of code. Do you rebuild it in GCC? (shameless OSS plug) Or, do you interface it with more modern systems using relatively cheap scripting code?
As you say, this usually comes down to a situation of money and time. If you don't have the money or the time to rebuild it, you will end up creating something that will make it interface with new systems as painlessly as possible - aka 'glue'.
Some especially useful glue: *Unix shell pipes and output redirection *Perl and expect.pm - allows you to manage socket connections - and link multiple applications on the same platform or across the network easily (handles all the socket creation/breakdown stuff seamlessly) and automate the handling of normally interactive interfaces via 'expect' 'send' functionality. *TCL and Expect - see above...expect was originally developed as part of TCL (much as the Tk widget set) - but has evolved to perl as well (not sure if there are any other language implementations atm). *Any language you can embed into an application (Lisp macros in EMACS for example).
Again, I think the Unix/Linux culture has more of a propensity to embrace this technique as opposed to 'C++' or 'Java' programming cultures.
Another thing I have not seen anyone touch on is the methodology and philosophy of the software lifecycle. I see shops that only work with the waterfall lifecycle - and they have a tendency to produce code that is minimally useful (or not useful at all for real end users) and horrid to maintain (regardless of the ease of maintaining a consistent code base; if the concept itself is all wrong you are going to end up rebuilding it anyway - and through a series of enhancement requests - that takes months or years to implement; what was originally desired!). These shops have a tendency to only do one or two languages (C++ and Java usually) well.
There is a more progressive philosophy that views the project, and its lifecycle as an ever expanding spiral that allows iterative design, code, test, evaluate results and schedule, rinse and repeat. These projects tend to have frequent code releases, multiple mockups, and encompass the real needs of your end user community when all is said and done. Maintenance is a snap because: A) The users get what they need, thus don't put in change/enhancement requests right off the bat, and B) Most maintenance activities center around fixing bugs as opposed to recreating the application. This methodology lends itself to multiple languages and scripting - since the main focus is to get the job done right.
I have witnessed several waterfall projects that extended over 5 or more years and to this day do not fill the needs of the user base (most of which ended up using glue - like embedded macro languages or scripting to fill in the gaps). It seems to me that more than any other, this is a method of ensuring large numbers of mediocre programmers employment over extended periods of time.
On the other hand, I have used iterative design, and have had success upon success, with a minimal cost in time and resources - since I am free to utilize the right tool for each job as needed based upon an solid risk accessment.
I followed the programming (as opposed to hardware) branch within the Computer Science degree program at my University. At the university there was no stigma placed on one language over another, and so armed with my previous experience with basic, pascal and fortran, I dove into classes on perl, sed, awk, and Unix shell programming, as well as C++, Java and Lisp.
My first job was as a Unix systems administrator/technical support weenie on an proprietary embedded system. The system did not have (and it was not legal to add, without breaking our maintenance agreement) a compiler. So, any automation we needed to perform was in the form of shell scripts.
I ended up building a full blow interactive application that hundreds of people use on a daily basis to this day. The last bug for this system was found in 1999. Scripting allowed us to extend the functionality on that system, and all of the design tasks and lifecycle considerations were the same.
I have been in several projects since then, big and small. In every case I always was able to make the decision to use a scripting language if I thought it appropriate (for example, we needed to perform remote administration on hundreds of machines; what better way to automate this functionality than with Perl and Expect.pm - so I did). As a developer I always keep my eyes open for the most efficient means of getting the job done.
Perhaps being a system administrator for a time helped me avoid the stigma associated with 'scripting'. To me it is all just programming - plain and simple. Those that limit themselves and don't grok as many languages and methods as possible are selling themselves short. Today I am extending my abilities by teaching myself python, and extending my perl repetoire with perl/Tk.
Holy wars are only an overt attempt to subjugate other's ideas to your own. Its wrong - so,STOP IT!
Re:Yep...recompilation of the kernel anyone..?
on
Microsoft At Middle Age
·
· Score: 4, Insightful
There is one thing you failed to mention: You can't recompile the windows kernel to make it smaller.
I regularly tune and recompile my linux kernels to support the specific hardware I have on my eclectic assortment of old boxes (P100s etc..). This fine tuning makes the kernel run quicker, and allows me to lower the disk and memory footprint. (P.S. I burn CDs that contain these unique kernels as recovery disks - so no worries on catastrophic failures). You don't have to live with a bloated 'one size fits all' distribution if you don't want to under linux. Not so for windows (unless you pay a price of course).
I have all of this flexibility in Linux for free. Windows can't beat that.
It is a big deal for me. I demand quality over quantity and glitz. Windows does not deliver.
One thing that I recognized at an early age was that as much as everyone wants to segment everything into nice simple cubbyholes, these artificial barriers are inherently flawed. I also recognized that this was a simplistic solution to the really unique aspects within everything. Hierachical segmentation is a binary solution (it either is or is not in a particular box), whereas reality is pure analog (this may sound funny coming from a computer scientist - however I know it to be true - it is also why I grok'd fuzzy logic when the idea first gained popularity).
The author of this piece (and many of you here for that matter) make the same mistake. Why must we pigeonhole everyone? The very term we use to label ourselves on these forums, 'Nerd', really serves to reinforce this self denigrating process. I really think - while most people are reasonable and intelligent in various aspects of their lives - they get it all wrong when it comes to this (pattern matching is something we instinctively learn at a very early age - perhaps that explains this tendency).
No one is a saint or a sinner - only what they choose to be at any given moment. Integrity is recognizing this and being your true self at every opportunity.
Poor ignorant kids are going to get sucked into the 'Micro-centric' worldview of Bill Gates and company - further padding revenue well into this century.
I'm wiping my daughter's windows box as soon as possible and reloading Linux; this has gone far enough.
The most critical issue that I see from this is publishers locking out those who can not pay for the service. The ability for the publishers to create their own definitions of what is "fair use" could create a further imbalance between those universities that are rich and those that are poor.
The key element that makes the internet such a critical part of academia is the freedom to exchange ideas from anywhere on earth. Removing that fundamental element puts those people who can not pay for the same ability out of the loop, and serves to stratify society even more than it is already.
Who benefits? Two factions benefit from this: 1. Monopolies - corporations who tend to gain from exclusive control over a particular market. This reinforces their exclusivity at the expense of freedom. 2. Elitists - those who feel that only a select few with resources should have access to higher education and the halls of power.
Both of these factions work hand in hand to further their agendas. Every ivy league college will have a fully functioning Palladium system, state colleges and universities will cut critical continuing education and other 'bootstrap' programs to pay for it, and small colleges without the resources will be left in the dark. Once the defacto standard is set (by publishers removing free electronic access, and embracing Palladium), it will all be over - the internet will be come a 'dark' place for those left out.
Of course, that might have a positive effect: those who GPL their manuscripts will have wide acceptance as 'the source', since most teachers will not be able to pay for the cannonical knowledge base to 'clip' for fair use.
'nothing personal', says the ganster as he pulls the trigger, sending a round through your skull...
Taking money out of my pocket - equates to taking food out of the mouth of my children.
It damn well is personal - particularly if I don't have another choice in the matter. A quick example: MS strong arms the IT department at your corporation - forcing you to upgrade, and thus outlay another cool million - NO BONUS or Salary Treatment for you this year!
Coersive and plainly immoral practices are wrong. I can't see how anyone can make amends with an organization that clearly practices activities that would make each of us shunned and hated (and possibly imprisoned) if we did the same in our private lives.
I don't see the oil companies inviting alternative energy and environmental protection groups into conferences discussing how to improve oil production/development.
I don't see World Finance groups bringing poor people into their conferences. (perhaps they should)
As a rule, a particular constituency has a right to organize and exclude those that do not represent the values of that community. Why should we not take advantage of this? Why should we let the deck be stacked against us because 'we are better than that?'
Open meeting laws do not apply to these private gatherings.
I said the same thing you did, in a different way - and got a 'flamebait' for my troubles. This point is valid:
Microsoft has shown its colors for two many years; we must be on our guard to deflect any mechanizations to derail the progress of that conference.
If we lie to ourselves that 'we must always be nice and turn the other cheek' - we will end up penniless, and lying face down in the gutter - metaphorically speaking of course.
The patent office is a disgrace - from the bogus things that a patent expert got passed the patent clerks, to this indignity - things need to change!
We need to write our congressional representatives and get legislation inacted that does the following:
1. Add a new branch of the patent office that only handles internet and computer related patents.
2. Staff this new section with people who are computer and internet savvy.
Obviously this will have to be staffed by people who are demonstrably intelligent and reasonable - which means alot of outside hires at the patent office...
Microsoft speaking at an Open Source conference is clearly an oxymoron. They have made their position clear from years of predatory and monopolistic business practices.
We better make damn sure we have our best and brightest Open Source proponents in that room to shoot down the FUD that Microsoft is sure to be flying.
I have no confidence that the Microsoft Corporation will be able to change its spots overnight - if ever. "Shared Source" reinforces that view.
"FOCUS:
Every new release of a software which has less bugs than the older one is also more complex and has more features...
Gates:
No, only if that is what'll sell!
FOCUS:
But...
Gates:
Only if that is what'll sell! We've never done a piece of software unless we thought it would sell. That's why everything we do in software... it's really amazing: We do it because we think that's what customers want. That's why we do what we do.
FOCUS:
But on the other hand - you would say: Okay, folks, if you don't like these new features, stay with the old version, and keep the bugs?
Gates:
No! We have lots and lots of competitors. The new version - it's not there to fix bugs. That's not the reason we come up with a new version.
FOCUS:
But there are bugs an any version which people would really like to have fixed.
Gates:
No! There are no significant bugs in our released software that any significant number of users want fixed.
FOCUS:
Oh, my God. I always get mad at my computer if MS Word swallows the page numbers of a document which I printed a couple of times with page numbers. If I complain to anybody they say "Well, upgrade from version 5.11 to 6.0".
Gates:
No! If you really think there's a bug you should report a bug. Maybe you're not using it properly. Have you ever considered that?
FOCUS:
Yeah, I did...
Gates:
It turns out Luddites don't know how to use software properly, so you should look into that. -- The reason we come up with new versions is not to fix bugs. It's absolutely not. It's the stupidest reason to buy a new version I ever heard. When we do a new version we put in lots of new things that people are asking for. And so, in no sense, is stability a reason to move to a new version. It's never a reason."
So, you can see that your assumption is incorrect. YOU CAN NOT DEPEND ON YOUR VENDOR TO FIX IT. We found this out the hard way at my job - after spending millions of dollars; now we have an open architecture system where we can plug and play different vendor solutions easily, and use open source next to vendor supplied applications.
On the other hand, I have written the maintainer of a famous development environment [don't want to drop names - not good form] - and he returned my email the same day with an answer to my question. My experience tells me your basic understanding does not jive with reality.
I have been given projects where I had to interface with some existing POS (such as windows) - and I did not have access to the source, and thus needed to approach the project from the standpoint of a blackbox.
In general this works fine - until some future date, when the owner of the blackbox decides to change the API such that your code breaks.
Blackboxes, other than in an academic setting, imply a closed proprietary system. Open systems, on the other hand, are not truely black boxes because you do have access to the source and all the underlying APIs (no Eastereggs waiting to create undocumented interactions).
When we are all dead and gone, and all of our thoughts and ideas are long lost, these things will come to pass. Homosapiens will just be a memory in some ancient anthropological archive - provided we or our ancesters don't extinguish all life before then.
This is one science experiment we can't observe the end of (unless you exist in a Douglas Adams novel).
Writing is about finding the truth and expressing it as directly as possible. Any other form of writing makes me question the motivations of the people doing the writing.
Slashdot Mirror
I have not seen anyone touch on the methodology and philosophy of the software lifecycle as a determining factor in this so-called 'scripting bias':
I see shops that only work with the waterfall lifecycle - and they have a tendency to produce code that is minimally useful, particularly if their discovery techniques with key users is inadequate. While lip service is given to 'maintainable code', it is usually horrid to maintain, regardless of the ease of maintaining a consistent code base - particularly since the design itself is flawed. Rebuilding a flawed design is not maintenance. Corrections can take months or years as each request undergoes the scrutiny of the revision control process (a truely draconian process in some organizations). These shops have a tendency to only do one or two languages (C++ and Java usually) well.
There is a more progressive philosophy that views the project, and its lifecycle as an ever expanding spiral that allows iterative design, code, test, evaluate results and schedule, rinse and repeat. These projects tend to have frequent code releases, multiple mockups, and encompass the real needs of the end user community, when all is said and done. Maintenance is a snap because: A) The users get what they need, thus don't put in change/enhancement requests right off the bat, and B) Most maintenance activities center around fixing bugs as opposed to recreating the application. This methodology lends itself to multiple languages and scripting - since the main focus is to get the job done right.
~~
I have witnessed several waterfall projects that extended over 5 or more years and to this day do not fill the needs of the user base (most of which ended up using glue - like embedded macro languages or scripting to fill in the gaps). It seems to me that more than any other, this is a method of ensuring large numbers of mediocre programmers employment over extended periods of time.
On the other hand, I have used iterative design, and have had success upon success, with a minimal cost in time and resources - since I am free to utilize the right tool for each job as needed based upon an solid risk accessment. I think this methodology is rarely used in most established 'code factories'.
This also manifests itself in how we think of our end user communities. Just as the BOFH complains about stupid 'Lusers', I think there is a lack of respect for the people who have to actually live with the products we produce. This is getting the cart before the horse, for without the users there would be no need for programmers or 'scripters' for that matter.
Of course, I could be completely off base, biased by my limited view of the world. Right.
Another thing I have found interesting is the amount of 'glue' that needed in complex and crufty systems alike.
Perhaps your company has an old Cobol or Fortran application that runs to hundreds of thousands of lines of code. Do you rebuild it in GCC? (shameless OSS plug) Or, do you interface it with more modern systems using relatively cheap scripting code?
As you say, this usually comes down to a situation of money and time. If you don't have the money or the time to rebuild it, you will end up creating something that will make it interface with new systems as painlessly as possible - aka 'glue'.
Some especially useful glue:
*Unix shell pipes and output redirection
*Perl and expect.pm - allows you to manage socket connections - and link multiple applications on the same platform or across the network easily (handles all the socket creation/breakdown stuff seamlessly) and automate the handling of normally interactive interfaces via 'expect' 'send' functionality.
*TCL and Expect - see above...expect was originally developed as part of TCL (much as the Tk widget set) - but has evolved to perl as well (not sure if there are any other language implementations atm).
*Any language you can embed into an application (Lisp macros in EMACS for example).
Again, I think the Unix/Linux culture has more of a propensity to embrace this technique as opposed to 'C++' or 'Java' programming cultures.
Another thing I have not seen anyone touch on is the methodology and philosophy of the software lifecycle. I see shops that only work with the waterfall lifecycle - and they have a tendency to produce code that is minimally useful (or not useful at all for real end users) and horrid to maintain (regardless of the ease of maintaining a consistent code base; if the concept itself is all wrong you are going to end up rebuilding it anyway - and through a series of enhancement requests - that takes months or years to implement; what was originally desired!). These shops have a tendency to only do one or two languages (C++ and Java usually) well.
There is a more progressive philosophy that views the project, and its lifecycle as an ever expanding spiral that allows iterative design, code, test, evaluate results and schedule, rinse and repeat. These projects tend to have frequent code releases, multiple mockups, and encompass the real needs of your end user community when all is said and done. Maintenance is a snap because: A) The users get what they need, thus don't put in change/enhancement requests right off the bat, and B) Most maintenance activities center around fixing bugs as opposed to recreating the application. This methodology lends itself to multiple languages and scripting - since the main focus is to get the job done right.
I have witnessed several waterfall projects that extended over 5 or more years and to this day do not fill the needs of the user base (most of which ended up using glue - like embedded macro languages or scripting to fill in the gaps). It seems to me that more than any other, this is a method of ensuring large numbers of mediocre programmers employment over extended periods of time.
On the other hand, I have used iterative design, and have had success upon success, with a minimal cost in time and resources - since I am free to utilize the right tool for each job as needed based upon an solid risk accessment.
I like to call this the 'box within a box'. Everything is virtualized - which makes computers the ultimate simulation machine:
Shape of a spreadsheet -- POOF! - a spreadsheet appears
Shape of an Airplane -- POOF! - a flight simulator appears
Shape of a raincloud -- POOF! - a meteorological simulation appears
( POOF! = design and implementation btw)
I followed the programming (as opposed to hardware) branch within the Computer Science degree program at my University. At the university there was no stigma placed on one language over another, and so armed with my previous experience with basic, pascal and fortran, I dove into classes on perl, sed, awk, and Unix shell programming, as well as C++, Java and Lisp.
My first job was as a Unix systems administrator/technical support weenie on an proprietary embedded system. The system did not have (and it was not legal to add, without breaking our maintenance agreement) a compiler. So, any automation we needed to perform was in the form of shell scripts.
I ended up building a full blow interactive application that hundreds of people use on a daily basis to this day. The last bug for this system was found in 1999. Scripting allowed us to extend the functionality on that system, and all of the design tasks and lifecycle considerations were the same.
I have been in several projects since then, big and small. In every case I always was able to make the decision to use a scripting language if I thought it appropriate (for example, we needed to perform remote administration on hundreds of machines; what better way to automate this functionality than with Perl and Expect.pm - so I did). As a developer I always keep my eyes open for the most efficient means of getting the job done.
Perhaps being a system administrator for a time helped me avoid the stigma associated with 'scripting'. To me it is all just programming - plain and simple. Those that limit themselves and don't grok as many languages and methods as possible are selling themselves short. Today I am extending my abilities by teaching myself python, and extending my perl repetoire with perl/Tk.
Holy wars are only an overt attempt to subjugate other's ideas to your own. Its wrong - so, STOP IT!
There is one thing you failed to mention: You can't recompile the windows kernel to make it smaller.
I regularly tune and recompile my linux kernels to support the specific hardware I have on my eclectic assortment of old boxes (P100s etc..). This fine tuning makes the kernel run quicker, and allows me to lower the disk and memory footprint. (P.S. I burn CDs that contain these unique kernels as recovery disks - so no worries on catastrophic failures). You don't have to live with a bloated 'one size fits all' distribution if you don't want to under linux. Not so for windows (unless you pay a price of course).
I have all of this flexibility in Linux for free. Windows can't beat that.
It is a big deal for me. I demand quality over quantity and glitz. Windows does not deliver.
I was a thespian! Damnit...
(*goes back to monosylabic mumbling*)
These kinds of things are out there already. Try this streaming audio for old time radio shows:
http://www.live365.com/stations/knronline
Or:
http://www.live365.com/stations/otrnow
I agree it would also be nice to see new creative scripts and performances as another alternative to these oldies.
One thing that I recognized at an early age was that as much as everyone wants to segment everything into nice simple cubbyholes, these artificial barriers are inherently flawed. I also recognized that this was a simplistic solution to the really unique aspects within everything. Hierachical segmentation is a binary solution (it either is or is not in a particular box), whereas reality is pure analog (this may sound funny coming from a computer scientist - however I know it to be true - it is also why I grok'd fuzzy logic when the idea first gained popularity).
The author of this piece (and many of you here for that matter) make the same mistake. Why must we pigeonhole everyone? The very term we use to label ourselves on these forums, 'Nerd', really serves to reinforce this self denigrating process. I really think - while most people are reasonable and intelligent in various aspects of their lives - they get it all wrong when it comes to this (pattern matching is something we instinctively learn at a very early age - perhaps that explains this tendency).
No one is a saint or a sinner - only what they choose to be at any given moment. Integrity is recognizing this and being your true self at every opportunity.
Poor ignorant kids are going to get sucked into the 'Micro-centric' worldview of Bill Gates and company - further padding revenue well into this century.
I'm wiping my daughter's windows box as soon as possible and reloading Linux; this has gone far enough.
The most critical issue that I see from this is publishers locking out those who can not pay for the service. The ability for the publishers to create their own definitions of what is "fair use" could create a further imbalance between those universities that are rich and those that are poor.
The key element that makes the internet such a critical part of academia is the freedom to exchange ideas from anywhere on earth. Removing that fundamental element puts those people who can not pay for the same ability out of the loop, and serves to stratify society even more than it is already.
Who benefits? Two factions benefit from this:
1. Monopolies - corporations who tend to gain from exclusive control over a particular market. This reinforces their exclusivity at the expense of freedom.
2. Elitists - those who feel that only a select few with resources should have access to higher education and the halls of power.
Both of these factions work hand in hand to further their agendas. Every ivy league college will have a fully functioning Palladium system, state colleges and universities will cut critical continuing education and other 'bootstrap' programs to pay for it, and small colleges without the resources will be left in the dark. Once the defacto standard is set (by publishers removing free electronic access, and embracing Palladium), it will all be over - the internet will be come a 'dark' place for those left out.
Of course, that might have a positive effect: those who GPL their manuscripts will have wide acceptance as 'the source', since most teachers will not be able to pay for the cannonical knowledge base to 'clip' for fair use.
Go visit Ethiopia and Somalia if you want to see how cheap can be regarded. This past century has been the bloodiest in Earth's history.
I don't see how you can equate conditions in turn of the centry industry, and the Holocaust(sic).
'nothing personal', says the ganster as he pulls the trigger, sending a round through your skull...
Taking money out of my pocket - equates to taking food out of the mouth of my children.
It damn well is personal - particularly if I don't have another choice in the matter. A quick example: MS strong arms the IT department at your corporation - forcing you to upgrade, and thus outlay another cool million - NO BONUS or Salary Treatment for you this year!
Coersive and plainly immoral practices are wrong. I can't see how anyone can make amends with an organization that clearly practices activities that would make each of us shunned and hated (and possibly imprisoned) if we did the same in our private lives.
This is about lobbying for a position.
I don't see the oil companies inviting alternative energy and environmental protection groups into conferences discussing how to improve oil production/development.
I don't see World Finance groups bringing poor people into their conferences. (perhaps they should)
As a rule, a particular constituency has a right to organize and exclude those that do not represent the values of that community. Why should we not take advantage of this? Why should we let the deck be stacked against us because 'we are better than that?'
Open meeting laws do not apply to these private gatherings.
I said the same thing you did, in a different way - and got a 'flamebait' for my troubles. This point is valid:
Microsoft has shown its colors for two many years; we must be on our guard to deflect any mechanizations to derail the progress of that conference.
If we lie to ourselves that 'we must always be nice and turn the other cheek' - we will end up penniless, and lying face down in the gutter - metaphorically speaking of course.
P.S. - Hopefull this would have the effect of raising the denial level of internet and computer/software patents to the 99% level or better... :)
The patent office is a disgrace - from the bogus things that a patent expert got passed the patent clerks, to this indignity - things need to change!
We need to write our congressional representatives and get legislation inacted that does the following:
1. Add a new branch of the patent office that only handles internet and computer related patents.
2. Staff this new section with people who are computer and internet savvy.
Obviously this will have to be staffed by people who are demonstrably intelligent and reasonable - which means alot of outside hires at the patent office...
Microsoft speaking at an Open Source conference is clearly an oxymoron. They have made their position clear from years of predatory and monopolistic business practices.
We better make damn sure we have our best and brightest Open Source proponents in that room to shoot down the FUD that Microsoft is sure to be flying.
I have no confidence that the Microsoft Corporation will be able to change its spots overnight - if ever. "Shared Source" reinforces that view.
Real coders don't need overtime, or sleep for that matter.
Be a real coder, and stop slacking off...
Been to any Nuclear Power Plants, or Chemical plants, etc...?
Software that crashes can kill.
Better to put the responsibility for fixing a driver or api call on somebody who is both libel to me and who has experience in doing so.
... it's really amazing: We do it because we think that's what customers want. That's why we do what we do.
- dasmegabyte
To quote the FOCUS Magazine interview with Bill Gates [October 23, 1995]:
"FOCUS:
Every new release of a software which has less bugs than the older one is also more complex and has more features...
Gates:
No, only if that is what'll sell!
FOCUS:
But...
Gates:
Only if that is what'll sell! We've never done a piece of software unless we thought it would sell. That's why everything we do in software
FOCUS:
But on the other hand - you would say: Okay, folks, if you don't like these new features, stay with the old version, and keep the bugs?
Gates:
No! We have lots and lots of competitors. The new version - it's not there to fix bugs. That's not the reason we come up with a new version.
FOCUS:
But there are bugs an any version which people would really like to have fixed.
Gates:
No! There are no significant bugs in our released software that any significant number of users want fixed.
FOCUS:
Oh, my God. I always get mad at my computer if MS Word swallows the page numbers of a document which I printed a couple of times with page numbers. If I complain to anybody they say "Well, upgrade from version 5.11 to 6.0".
Gates:
No! If you really think there's a bug you should report a bug. Maybe you're not using it properly. Have you ever considered that?
FOCUS:
Yeah, I did...
Gates:
It turns out Luddites don't know how to use software properly, so you should look into that. -- The reason we come up with new versions is not to fix bugs. It's absolutely not. It's the stupidest reason to buy a new version I ever heard. When we do a new version we put in lots of new things that people are asking for. And so, in no sense, is stability a reason to move to a new version. It's never a reason."
So, you can see that your assumption is incorrect. YOU CAN NOT DEPEND ON YOUR VENDOR TO FIX IT. We found this out the hard way at my job - after spending millions of dollars; now we have an open architecture system where we can plug and play different vendor solutions easily, and use open source next to vendor supplied applications.
On the other hand, I have written the maintainer of a famous development environment [don't want to drop names - not good form] - and he returned my email the same day with an answer to my question. My experience tells me your basic understanding does not jive with reality.
The conclusion of the article was that the power distribution curve is a random process.
Given that, there is no meaning we can rightfully attach to this effect (or bloggs for that matter) other than how we want to view the situation.
At a higher level this simply means: Do or do not; there is no try.
I have been given projects where I had to interface with some existing POS (such as windows) - and I did not have access to the source, and thus needed to approach the project from the standpoint of a blackbox.
In general this works fine - until some future date, when the owner of the blackbox decides to change the API such that your code breaks.
Blackboxes, other than in an academic setting, imply a closed proprietary system. Open systems, on the other hand, are not truely black boxes because you do have access to the source and all the underlying APIs (no Eastereggs waiting to create undocumented interactions).
When we are all dead and gone, and all of our thoughts and ideas are long lost, these things will come to pass. Homosapiens will just be a memory in some ancient anthropological archive - provided we or our ancesters don't extinguish all life before then.
This is one science experiment we can't observe the end of (unless you exist in a Douglas Adams novel).
An error of ommission is still an error.
Writing is about finding the truth and expressing it as directly as possible. Any other form of writing makes me question the motivations of the people doing the writing.
That is not true. They would have just continued extending the rights of the patentees (like the recent copyright ruling in the supreme court).
We will all be dead before Bill's children and grandchildren stop reaping the benefits of Microsoft's exclusionary practices.