No one is pointing a gun at your head forcing you to get a licensed architect or structural engineer to design your house. Yet when you look up prospective contractors you are obviously going to ask them, and probably pick one who has his certification.
So why not let it stand as a marketing device? If you want software from the lay-hacker, you can choose to buy from him. If you choose to buy it from the certified hacker, you may do so freely.
Within a decade the marketing clout of the certification (if it is worth anything) would put the uncertified hackers out of business. Its just human nature - we look for a degree in the dentists office, don't we?
After being a software engineer for ten years, I have found one constant in this field of work: disappointment and disgust.
If you allow anyone to program professionally, then you must be prepared for more terrible code.
And please spare me the anecdotes about the English major who is the world's best programmer - we don't architect our socirty on corner cases. Added to which, there would be ample opportunity for non-CS grads to gain the certification where it to become required.
The OS is language
The programs like sed / grep / awk / find use a languages.
TCP is a langauge, APPC/APPN, modems
This is gibberish. He is talking about mixing together multiuple turing-complete programming languages.find and the TCP/IP protocol do not qualify. In the case of the latter, it is a byte ordering protocol, not even a "syntax" per se.
I'm not sure what people are thinking when they specify that everything on a project "needs" to be done in Java or whatever.
Building software is a function of economics. If you've dumped considerable resources into training, code licenses, an existing software base, or other real-world issues, you will be very inclined to insist that your "chosen" language be used in future projects unless there is an overwhelming issue that prohibits it.
People mix languages out of necessity for accomodating legacy code.
Mixing multiple languages creates huge maintainence issues - will the API for integrating the languages give you enough breathing room in the future?
How about performance? Integrating multiple languages means invoking multiple runtimes and address spaces.
What about debugging? The small amount of experience I have had integrating Perl and C clearly indicates that debugging large apps written in multiple languges is extremely difficult - forget about your IDE or traditional single debugger.
VA Linux didn't fail due to the "openness" of its products - considering that until recently its primary business was hardware. VA simply couldn't be price-competitive with larger hardware vendors. As for SourceForge, its not clear that its a very compelling revenue-generator in any case - regardless of the openness of its source.
As for the other companies, most of them were questionable in any sense, and considering that most of them were predicated on the fad aspect of open source, it should come as no surprise that they flopped.
There is hope though, RedHat seems to be doing respectably, and IBM is making large investments in open source that are predicated upon sound business principles.
Prettier outside, same junk inside
on
Concept PC 2001
·
· Score: 4, Interesting
How about PCs that are actually simple to upgrade or alter if we see fit? A few years back PC vendors tried removeable components, but now these designs are relegated to server-class systems (i.e. hot swappable RAID drives).
Still to this day, upgrading a hard drive or a graphics card is an unnecesarily obfuscated process, requiring the PC guts to be cracked open and laid out on the kitchen table.
Of course easily upgradeable components would cut into PC sales, so its probably hopeless.
XML is a poor choice for data storage. Arguably it is also a poor choice for data modelling as it does not have a strict constraint model.
Relational databases are here to stay and will be with us for at least the next fifty years. It is better to think of ways of translating relational data than supplanting it.
SGML/XML is an interchange format and this is the only domain it has proven useful over the years. For years people have tried to construct useable SGML and/or XML databases and the results have been consistently disappointing.
For more complex hierarchical relationships, an object database is more apt, or an XML translation kit for your relational DBs.
At some point it will be simply impossible to effectively firewall by port, protocol or syntax. There are so many ways of piping functionality acrosss the network that firewalls are simply going to have to become intelligent about what represents a hostile bytestream.
I can't get over all of these posts in here like "I'm running a {webserver/database/mail server} and I wonder which one is best?"
For 99% of the people here, the low-capacity applications they are discussing are going to operate identically on both platforms. Unless you are running AOL, Yhaoo, or Hotmail, you are not a corner case. Use whatever you like, it is not going to make one lick of difference in performance or stability.
like all the perl-slinging dot-com companies that have deservedly run themselves into the ground, without ever inventing let alone implementing any useful products or services.
You mean like the companies that were hocking "LISP machines" ten years ago?
What separates these pathetic souls from the dotcoms is that the dotcom folks made some cash before they flamed out.
Do your customers know that you are saddling them with code that will be much more expensive for them to maintain than a "majority" language?
Seriously, should you pass on and they need to hire someone else to maintain your LISP, they will certainly pay 2x or 3x the cost of a C programmer, as good LISP programmers are far more rare.
This isn't a joke - I know of companies that have acquired LISP code that has become a complete albatross as they struggle to hire or train people to maintain it - here's a hint - not many programmers want to bother with LISP as they see it as career-limiting.
All in all, I think offering LISP solutions to your customers is a lousy value proposition in the long term.
I've spent the last several years trying to explain to colleagues why
they should start using another obscure-but-good language, Eiffel, to no avail.
Here is what I have learned. Note that this is not about the pros and cons of
particular languages or paradigms, its about the way the programming language
industry actually works.
The language industry is dominated by network effects. There are major
costs with using a minority language, and for an individual project these
completely outweigh the benefits, even when the benefits are very large. Hence
it is generally far better to stay with a majority language. The costs of a
minority language include:
Support. Sure, you can get a GPL compiler for most languages, but on a project
you don't want to have your coders digging into the code trying to
fix a bug, you want them writing code. Support is something you outsource.
Performance. Every minority language claims to be faster than C, but often
isn't in practice. Whatever the truth, C and C++ are at least known
quantities. Maybe the minority language will be faster, maybe slower. If its
faster, well gee so what. If its slower then you have a major problem.
Tool support. These days even small projects start by drawing UML diagrams and
then converting these automatically into class templates. CASE
tool vendors don't support minority languages. Ditto for testing and
documentation tools. Little things like tying your compiler to your
configuration control manager might potentially be major headaches. Again, its
more risk that the PM can do without.
Nobody ever got fired for buying C/C++/Java. If you are a PM this is a major
issue. Every language is going to bring some headaches, but if you have chosen
a minority language then these headaches can be turned into an excuse for
project failure, and hence for hanging you out to dry.
Trained staff in a minority language are going to be rare. This does not
necessarily make them more expensive (nobody else wants them), but it
does make recruitment much harder and more uncertain. Alternatively you have to
train all your existing people in the new language. And for Functional
Languages its not just another syntax, its a whole new way of thinking. The
industry went through this with OO languages, and many PMs have vivid memories
of reams of non-OO obfuscated C++ written by a bunch of C hackers who had been
sent on a one week C++ course. Getting your head around a new paradigm can take
months, and this is time that the project just does not have.
So, overall the PMs want to go with popular languages, not for PHM
reasons, but for entirely rational local reasons. But rational local decisions
turn into globally arbitrary decisions, as the entire herd gallops off in a
random direction chosen only because most of the herd thought that most of the
herd were headed that way.
The lesson of this is that if you want to introduce a language, you don't
concentrate on making it a good language, you try to persuade the herd of
programmers, PMs and tool vendors that your language is the Next Big Thing. The
important point here is not how much the language will do for productivity,
quality and cost, it is to create the perception that everyone else thinks that
this language will be the next big thing.
There are two ways to do this. One way is to tackle the whole industry at once.
For an object lesson in how to do this, see Java. For an object lesson
in how not to do it, see Eiffel. Believe me, I know all about this. I have
spent a long time giving presentations extolling the technical virtues of
Eiffel, only to have my audience say "Yes, but in the Real World....". In the
Real World what counts is the network effects. And you know what? My audiences
were right. It has taken me a long time to realise this.
The other more interesting and more promising way to introduce a new
language is to identify a niche market and attack that. Once you have taken
over your niche you can expand to nearby niches and start to build momentum.
Python is doing exactly this in web serving, for example. Web serving is a good
niche because lots of people do it, and productivity and quality generally
count for more than raw performance. Projects also tend to be small, so
experiments are not the Career Limiting Moves they are for large projects.
Education can also be a useful niche if you can afford to take the long view,
which is how Pascal, Basic and Unix got started.
I've spent the last several years trying to explain to colleagues why
they should start using another obscure-but-good language, Eiffel, to no avail.
Here is what I have learned. Note that this is not about the pros and cons of
particular languages or paradigms, its about the way the programming language
industry actually works.
The language industry is dominated by network effects. There are major
costs with using a minority language, and for an individual project these
completely outweigh the benefits, even when the benefits are very large. Hence
it is generally far better to stay with a majority language. The costs of a
minority language include:
Support. Sure, you can get a GPL compiler for most languages, but on a project
you don't want to have your coders digging into the code trying to
fix a bug, you want them writing code. Support is something you outsource.
Performance. Every minority language claims to be faster than C, but often
isn't in practice. Whatever the truth, C and C++ are at least known
quantities. Maybe the minority language will be faster, maybe slower. If its
faster, well gee so what. If its slower then you have a major problem.
Tool support. These days even small projects start by drawing UML diagrams and
then converting these automatically into class templates. CASE
tool vendors don't support minority languages. Ditto for testing and
documentation tools. Little things like tying your compiler to your
configuration control manager might potentially be major headaches. Again, its
more risk that the PM can do without.
Nobody ever got fired for buying C/C++/Java. If you are a PM this is a major
issue. Every language is going to bring some headaches, but if you have chosen
a minority language then these headaches can be turned into an excuse for
project failure, and hence for hanging you out to dry.
Trained staff in a minority language are going to be rare. This does not
necessarily make them more expensive (nobody else wants them), but it
does make recruitment much harder and more uncertain. Alternatively you have to
train all your existing people in the new language. And for Functional
Languages its not just another syntax, its a whole new way of thinking. The
industry went through this with OO languages, and many PMs have vivid memories
of reams of non-OO obfuscated C++ written by a bunch of C hackers who had been
sent on a one week C++ course. Getting your head around a new paradigm can take
months, and this is time that the project just does not have.
So, overall the PMs want to go with popular languages, not for PHM
reasons, but for entirely rational local reasons. But rational local decisions
turn into globally arbitrary decisions, as the entire herd gallops off in a
random direction chosen only because most of the herd thought that most of the
herd were headed that way.
The lesson of this is that if you want to introduce a language, you don't
concentrate on making it a good language, you try to persuade the herd of
programmers, PMs and tool vendors that your language is the Next Big Thing. The
important point here is not how much the language will do for productivity,
quality and cost, it is to create the perception that everyone else thinks that
this language will be the next big thing.
There are two ways to do this. One way is to tackle the whole industry at once.
For an object lesson in how to do this, see Java. For an object lesson
in how not to do it, see Eiffel. Believe me, I know all about this. I have
spent a long time giving presentations extolling the technical virtues of
Eiffel, only to have my audience say "Yes, but in the Real World....". In the
Real World what counts is the network effects. And you know what? My audiences
were right. It has taken me a long time to realise this.
The other more interesting and more promising way to introduce a new
language is to identify a niche market and attack that. Once you have taken
over your niche you can expand to nearby niches and start to build momentum.
Python is doing exactly this in web serving, for example. Web serving is a good
niche because lots of people do it, and productivity and quality generally
count for more than raw performance. Projects also tend to be small, so
experiments are not the Career Limiting Moves they are for large projects.
Education can also be a useful niche if you can afford to take the long view,
which is how Pascal, Basic and Unix got started.
I don't see why closed-source extensions would make the product profoundly more viable, and I don't see why the lack of these extensions prevented the viability of the product.
Simply put, it will not be possible to sustain even a medium-sized software shop on a product such as SourceForge. On the low end you can get away with simply using CVS or CVSWeb, and on the high end I suspect customers will be suspicious of VA's long term (and even short term) viability.
VA simply has too much negative momentum at this point to save itself. While it is not their fault that the stock price was overvalued so greatly, they are nonetheless injured by the steep selloff. That coupled with a complete loss of vision at the company probably means the gig is up. I give them eighteen months.
For godsake if you knew anything about French politics you'd know they have a real problem with racism with the Front Nationale
And the US has the Klan and the Black Panthers. Whats your point?
take scientific bigotry there are States in the US (esp Kansas) where Evolution isn't accepted. No one in Europe would have a _chance_ of getting that even close to being approved, they'd be laughed at so hard and then locked in the nut house.
While I believe in evolution, it is only a theory. Without distinct proof it would be dishonest to block opposing views.
In the UK if a policeman pulls me over I do not have to be carrying my driving license, or any other identification, I do not have to give my identity. Sure he can then take me into custody on suspicion... but it is not a crime to not say who you are. Do you have the same freedom ?
Yes. The Miranda Act.
In France if a company wishes to close down they must first discuss it with their employees, do you have such power over your life ?
And the inability to alter the wokforce has crippled and destroyed good French companies. Look at Moulinex for example - can't fire some, so they had to fire all!
The consistent ethic is that free distribution of useful, non-personal information products is good, and restricting this distribution is bad.
But like all of the other posters you presuppose that this is what the content creator wishes. You are taking it upon yourself to impose your own standards on someone else's intellectual property.
When you purchase a CD you buy the rights to your own fair use of the product, not to make a free copy for everyone on the planet.
When in doubt, just remember, theft is wrong, and you know damn well this is theft.
Those who can face unreliable service, high prices, and shamefully bad customer service and support.
And its getting worse. Most of the start-ups that may have created competition in this market have gone under, leaving the cable and telephone monopolies in charge.
I don't know if the solution is more or less regulation and/or public involvement, but in the current atmosphere, things are going to suck for a very long time.
More and more these days, linux projects are rejecting the canons of classic unix design - keep it small, keep it simple, sensibly limit the tasks solved by the code, integrate well with other utilities using simple interfaces.
Following these rules does not mean using mutt on the console - you can enjoy a GUI experience without creating bloatware. KMail is a great example of this - it reads and sends mail with a simple interface that does not attempt to solve an integrated problem.
Unfortunately so many linux projects have become so obsessed with attracting Windows users (why? Do we really expect these people to switch over? Get real!) that linux environments are becoming as fractured as Windows.
Come on, this stuff is being released to the public because it has become a dead-end product for IBM.
Java client tools are dead and buried - no one wants to use them where a native alternative exists...and more often than not these days, users have multiple choices in native tools.
Slashdot Mirror
So why not let it stand as a marketing device? If you want software from the lay-hacker, you can choose to buy from him. If you choose to buy it from the certified hacker, you may do so freely.
Within a decade the marketing clout of the certification (if it is worth anything) would put the uncertified hackers out of business. Its just human nature - we look for a degree in the dentists office, don't we?
If you allow anyone to program professionally, then you must be prepared for more terrible code.
And please spare me the anecdotes about the English major who is the world's best programmer - we don't architect our socirty on corner cases. Added to which, there would be ample opportunity for non-CS grads to gain the certification where it to become required.
The programs like sed / grep / awk / find use a languages.
TCP is a langauge, APPC/APPN, modems
This is gibberish. He is talking about mixing together multiuple turing-complete programming languages.find and the TCP/IP protocol do not qualify. In the case of the latter, it is a byte ordering protocol, not even a "syntax" per se.
Building software is a function of economics. If you've dumped considerable resources into training, code licenses, an existing software base, or other real-world issues, you will be very inclined to insist that your "chosen" language be used in future projects unless there is an overwhelming issue that prohibits it.
Mixing multiple languages creates huge maintainence issues - will the API for integrating the languages give you enough breathing room in the future?
How about performance? Integrating multiple languages means invoking multiple runtimes and address spaces.
What about debugging? The small amount of experience I have had integrating Perl and C clearly indicates that debugging large apps written in multiple languges is extremely difficult - forget about your IDE or traditional single debugger.
As for the other companies, most of them were questionable in any sense, and considering that most of them were predicated on the fad aspect of open source, it should come as no surprise that they flopped.
There is hope though, RedHat seems to be doing respectably, and IBM is making large investments in open source that are predicated upon sound business principles.
Still to this day, upgrading a hard drive or a graphics card is an unnecesarily obfuscated process, requiring the PC guts to be cracked open and laid out on the kitchen table.
Of course easily upgradeable components would cut into PC sales, so its probably hopeless.
Relational databases are here to stay and will be with us for at least the next fifty years. It is better to think of ways of translating relational data than supplanting it.
For more complex hierarchical relationships, an object database is more apt, or an XML translation kit for your relational DBs.
I wonder if anyone is working on this?
If you really want to get more performance, consider upgrading that aged box. Its going to make much more of a difference than swapping OSs.
For 99% of the people here, the low-capacity applications they are discussing are going to operate identically on both platforms. Unless you are running AOL, Yhaoo, or Hotmail, you are not a corner case. Use whatever you like, it is not going to make one lick of difference in performance or stability.
This was a view of things to come from Gibson after the Cyberpunk trilogy - mediocore SF redressing his old themes in new robes.
You mean like the companies that were hocking "LISP machines" ten years ago?
What separates these pathetic souls from the dotcoms is that the dotcom folks made some cash before they flamed out.
Seriously, should you pass on and they need to hire someone else to maintain your LISP, they will certainly pay 2x or 3x the cost of a C programmer, as good LISP programmers are far more rare.
This isn't a joke - I know of companies that have acquired LISP code that has become a complete albatross as they struggle to hire or train people to maintain it - here's a hint - not many programmers want to bother with LISP as they see it as career-limiting.
All in all, I think offering LISP solutions to your customers is a lousy value proposition in the long term.
You Work in a Fashion Industry
I've spent the last several years trying to explain to colleagues why
they should start using another obscure-but-good language, Eiffel, to no avail.
Here is what I have learned. Note that this is not about the pros and cons of
particular languages or paradigms, its about the way the programming language
industry actually works.
The language industry is dominated by network effects. There are major
costs with using a minority language, and for an individual project these
completely outweigh the benefits, even when the benefits are very large. Hence
it is generally far better to stay with a majority language. The costs of a
minority language include:
Support. Sure, you can get a GPL compiler for most languages, but on a project
you don't want to have your coders digging into the code trying to
fix a bug, you want them writing code. Support is something you outsource.
Performance. Every minority language claims to be faster than C, but often
isn't in practice. Whatever the truth, C and C++ are at least known
quantities. Maybe the minority language will be faster, maybe slower. If its
faster, well gee so what. If its slower then you have a major problem.
Tool support. These days even small projects start by drawing UML diagrams and
then converting these automatically into class templates. CASE
tool vendors don't support minority languages. Ditto for testing and
documentation tools. Little things like tying your compiler to your
configuration control manager might potentially be major headaches. Again, its
more risk that the PM can do without.
Nobody ever got fired for buying C/C++/Java. If you are a PM this is a major
issue. Every language is going to bring some headaches, but if you have chosen
a minority language then these headaches can be turned into an excuse for
project failure, and hence for hanging you out to dry.
Trained staff in a minority language are going to be rare. This does not
necessarily make them more expensive (nobody else wants them), but it
does make recruitment much harder and more uncertain. Alternatively you have to
train all your existing people in the new language. And for Functional
Languages its not just another syntax, its a whole new way of thinking. The
industry went through this with OO languages, and many PMs have vivid memories
of reams of non-OO obfuscated C++ written by a bunch of C hackers who had been
sent on a one week C++ course. Getting your head around a new paradigm can take
months, and this is time that the project just does not have.
So, overall the PMs want to go with popular languages, not for PHM
reasons, but for entirely rational local reasons. But rational local decisions
turn into globally arbitrary decisions, as the entire herd gallops off in a
random direction chosen only because most of the herd thought that most of the
herd were headed that way.
The lesson of this is that if you want to introduce a language, you don't
concentrate on making it a good language, you try to persuade the herd of
programmers, PMs and tool vendors that your language is the Next Big Thing. The
important point here is not how much the language will do for productivity,
quality and cost, it is to create the perception that everyone else thinks that
this language will be the next big thing.
There are two ways to do this. One way is to tackle the whole industry at once.
For an object lesson in how to do this, see Java. For an object lesson
in how not to do it, see Eiffel. Believe me, I know all about this. I have
spent a long time giving presentations extolling the technical virtues of
Eiffel, only to have my audience say "Yes, but in the Real World....". In the
Real World what counts is the network effects. And you know what? My audiences
were right. It has taken me a long time to realise this.
The other more interesting and more promising way to introduce a new
language is to identify a niche market and attack that. Once you have taken
over your niche you can expand to nearby niches and start to build momentum.
Python is doing exactly this in web serving, for example. Web serving is a good
niche because lots of people do it, and productivity and quality generally
count for more than raw performance. Projects also tend to be small, so
experiments are not the Career Limiting Moves they are for large projects.
Education can also be a useful niche if you can afford to take the long view,
which is how Pascal, Basic and Unix got started.
author unknown - I copied this long ago:
You Work in a Fashion Industry
I've spent the last several years trying to explain to colleagues why
they should start using another obscure-but-good language, Eiffel, to no avail.
Here is what I have learned. Note that this is not about the pros and cons of
particular languages or paradigms, its about the way the programming language
industry actually works.
The language industry is dominated by network effects. There are major
costs with using a minority language, and for an individual project these
completely outweigh the benefits, even when the benefits are very large. Hence
it is generally far better to stay with a majority language. The costs of a
minority language include:
Support. Sure, you can get a GPL compiler for most languages, but on a project
you don't want to have your coders digging into the code trying to
fix a bug, you want them writing code. Support is something you outsource.
Performance. Every minority language claims to be faster than C, but often
isn't in practice. Whatever the truth, C and C++ are at least known
quantities. Maybe the minority language will be faster, maybe slower. If its
faster, well gee so what. If its slower then you have a major problem.
Tool support. These days even small projects start by drawing UML diagrams and
then converting these automatically into class templates. CASE
tool vendors don't support minority languages. Ditto for testing and
documentation tools. Little things like tying your compiler to your
configuration control manager might potentially be major headaches. Again, its
more risk that the PM can do without.
Nobody ever got fired for buying C/C++/Java. If you are a PM this is a major
issue. Every language is going to bring some headaches, but if you have chosen
a minority language then these headaches can be turned into an excuse for
project failure, and hence for hanging you out to dry.
Trained staff in a minority language are going to be rare. This does not
necessarily make them more expensive (nobody else wants them), but it
does make recruitment much harder and more uncertain. Alternatively you have to
train all your existing people in the new language. And for Functional
Languages its not just another syntax, its a whole new way of thinking. The
industry went through this with OO languages, and many PMs have vivid memories
of reams of non-OO obfuscated C++ written by a bunch of C hackers who had been
sent on a one week C++ course. Getting your head around a new paradigm can take
months, and this is time that the project just does not have.
So, overall the PMs want to go with popular languages, not for PHM
reasons, but for entirely rational local reasons. But rational local decisions
turn into globally arbitrary decisions, as the entire herd gallops off in a
random direction chosen only because most of the herd thought that most of the
herd were headed that way.
The lesson of this is that if you want to introduce a language, you don't
concentrate on making it a good language, you try to persuade the herd of
programmers, PMs and tool vendors that your language is the Next Big Thing. The
important point here is not how much the language will do for productivity,
quality and cost, it is to create the perception that everyone else thinks that
this language will be the next big thing.
There are two ways to do this. One way is to tackle the whole industry at once.
For an object lesson in how to do this, see Java. For an object lesson
in how not to do it, see Eiffel. Believe me, I know all about this. I have
spent a long time giving presentations extolling the technical virtues of
Eiffel, only to have my audience say "Yes, but in the Real World....". In the
Real World what counts is the network effects. And you know what? My audiences
were right. It has taken me a long time to realise this.
The other more interesting and more promising way to introduce a new
language is to identify a niche market and attack that. Once you have taken
over your niche you can expand to nearby niches and start to build momentum.
Python is doing exactly this in web serving, for example. Web serving is a good
niche because lots of people do it, and productivity and quality generally
count for more than raw performance. Projects also tend to be small, so
experiments are not the Career Limiting Moves they are for large projects.
Education can also be a useful niche if you can afford to take the long view,
which is how Pascal, Basic and Unix got started.
Simply put, it will not be possible to sustain even a medium-sized software shop on a product such as SourceForge. On the low end you can get away with simply using CVS or CVSWeb, and on the high end I suspect customers will be suspicious of VA's long term (and even short term) viability.
VA simply has too much negative momentum at this point to save itself. While it is not their fault that the stock price was overvalued so greatly, they are nonetheless injured by the steep selloff. That coupled with a complete loss of vision at the company probably means the gig is up. I give them eighteen months.
And the US has the Klan and the Black Panthers. Whats your point?
take scientific bigotry there are States in the US (esp Kansas) where Evolution isn't accepted. No one in Europe would have a _chance_ of getting that even close to being approved, they'd be laughed at so hard and then locked in the nut house.
While I believe in evolution, it is only a theory. Without distinct proof it would be dishonest to block opposing views.
In the UK if a policeman pulls me over I do not have to be carrying my driving license, or any other identification, I do not have to give my identity. Sure he can then take me into custody on suspicion... but it is not a crime to not say who you are. Do you have the same freedom ?
Yes. The Miranda Act.
In France if a company wishes to close down they must first discuss it with their employees, do you have such power over your life ?
And the inability to alter the wokforce has crippled and destroyed good French companies. Look at Moulinex for example - can't fire some, so they had to fire all!
Yes, C will be around until you die.
But like all of the other posters you presuppose that this is what the content creator wishes. You are taking it upon yourself to impose your own standards on someone else's intellectual property.
When you purchase a CD you buy the rights to your own fair use of the product, not to make a free copy for everyone on the planet.
When in doubt, just remember, theft is wrong, and you know damn well this is theft.
Those who can face unreliable service, high prices, and shamefully bad customer service and support.
And its getting worse. Most of the start-ups that may have created competition in this market have gone under, leaving the cable and telephone monopolies in charge.
I don't know if the solution is more or less regulation and/or public involvement, but in the current atmosphere, things are going to suck for a very long time.
Following these rules does not mean using mutt on the console - you can enjoy a GUI experience without creating bloatware. KMail is a great example of this - it reads and sends mail with a simple interface that does not attempt to solve an integrated problem.
Unfortunately so many linux projects have become so obsessed with attracting Windows users (why? Do we really expect these people to switch over? Get real!) that linux environments are becoming as fractured as Windows.
Frankly if NASA can't coordinate the finances they are given, why give them more? That only reinforces their poor accounting.
Java client tools are dead and buried - no one wants to use them where a native alternative exists...and more often than not these days, users have multiple choices in native tools.