Under Windows you occasionally see that problem too, with differing versions of DLL's getting mixed up, overwritten, or lost and the general instability that results.
Well, this is the funniest damn thing I've read in a while. That is an incredible understatement. What Windows has is pretty much the same problem that people are talking about here. It is just that there are a lot of GUI tools to help straighten it out. Still, I'm a Windows developer (who has written DLLs), yet I can't figure out why my &#$# Win95 machine starts complaining about a missing MPR.DLL at random times. (And then there is the "minor" change that Microsoft recently made to one of the MFC DLLs that broke our application in certain cases. Not so fun given Microsoft's penchant for upgrading DLLs under the covers at every opportunity.)
The longer I work in this industry, the more I agree with another Dr. Dobbs editorial. DLLs, dynamic linking, whatever you call it, causes more problems then it fixes, especially in these days of $200 20 gig disks and $70 64 meg SIMMs.
At the moment, I work for a Windows developer, and our particulary product uses DLLs in order to support multiple types of configurations. The amount of work keeping multiple versions of DLLs and calling executables straight is immense, and it is too damn easy to make a "trivial" change that kills backwards compatibility.
As a relative Linux newbie, I used to think the situation there was better, especially with the Red Hat RPM system. Hah! After one novice attempt at installing egcs, I somehow managed to screw up my system entirely to the point where "hello world" wouldn't compile. It was a month of off and on work to get to the point where I could compile a program again. (Hell, the streamio library segfaults still, but I don't have the energy to figure out if this is a configuration issue.) (And all this because I just wanted to play with bitset.)
Versioning is a huge problem that seems to effect both Windows and Linux equally. Current attempts to fix it (Windows COM+, for one) don't seem to really work. I say, scrap the whole thing and static link everything. If you include the libraries you need in your binary, it won't break when someone else screws up the system.
This reminds me of a company a few years back that would sell you a square meter of land on Mars. You're paying for a novelty piece of paper. Why not just fire up the old inkjet?
If you want to send a signal to aliens, your better off going out into the wilderness and firing one of those cheap laser pointers at the sky.
Ok, some may think this is a troll, but the truth is, at this point in the century, Bill Gates has had far more influence on the computer industry than Torvalds.
(TIME's Person of the Century is that person who, for better or worse, most influenced the course of history over the past 100 years.)
Now personally I think that this is something that ought to change, but I don't think that's gonna happen in five months.
Now let's all hope that Gates gets wedged between Hitler, Stalin and Mao. Perhaps then people will get a clue...
"A short step away" is hyperbole. It is like saying that because someone was able to get a short program typed in out of a magazine to compile that they are a "short step away" from being a professional programmer.
This is a baby step. An important one, but no where near the final one.
However, some other posters should note that this is not about creating new diseases. virus is basically a machine for inserting genetic changes into cells. Currently, these are evolved and are generally not changes that we want. However, there are a huge number of changes that we certainly do want to make. We want to cure cancer. We want to cure genetic diseases. Being able to create a virus that replaces the "bad" sequence causing the disease with the "good" sequence that doesn't is obviously a very, very good thing for us.
It is important to remember that how nice Gates is with his money has nothing to do with how honorable his company is. Most of the 19th century robber barons gave tons of money away when they got older. (Carnegie Hall, anyone?) This doesn't mean that they didn't use horrendous business practices to get the money in the first place. Rockefeller's business practices were the ones that inspired anti-trust laws in the first place. He was ruthless at driving out competitors. And later, he was well known for spending a ton of money on charity.
This does not surprise me at all because it fits in with Gates' personality. Everything I've read about he says that he is not a greedy guy. He is a power-hungry guy. Those are two very different things. I suspect that he'd give a lot more money right now if that didn't mean selling more shares (and thus giving up control (power)) to get the cash.
Re:Huray! Now, more people use C++!!
on
GCC 2.95 Released
·
· Score: 1
I once did a real world project in a OO fashion using only C as a test and while it was certainly possible, it was certainly much more work. The program worked well, was (IMHO) fairly easy to maintain, blah, blah, blah, but I could have easily written a similarly good C++ program in about 1/3 the time, and it would have been even more easy to maintain.
Re:Huray! Now, more people use C++!!
on
GCC 2.95 Released
·
· Score: 1
I'd agree with all that with the exception that the templates in the STL are incredibly useful and ought not be avoided.
Templates themselves are wildly useful, it is just that you really have to know what you are doing to get anything positive out of them. I'd say, don't use templates unless you understand exactly how the STL works, and then only use them if you can't do the same thing easily without them.
Operator overloading should only be used in certain cookie cutter ways. Creating '>' operators for io in a new class. Creating an assignment operator for a new class. That sort of thing.
IMHO, most of the "problems" of C++ come from people who overuse inheritance . Huge inheritance hierarchies are nearly always a mistake. Much better are a bunch of smaller, completely independent classes. (You know, "modularity", that thing they told you was good in school.)
The other mistake is going in expecting something like Smalltalk and then getting pissed because it is not. Part of the whole point of C++ is that you don't have to make every single line of code object-oriented. I know that is heresy for many OO types, but in the real world it is damn useful to have a language that is OO when you want it, but only when you want it. That is why C++ is so much more popular then languages that enforce OO.
Personally, I think anyone coding in C should switch to C++ even if they aren't going to go OO. C++ has some extensions over C that allow you to improve structured programs as well. Just remember that typing "g++" does not mean you have to start the project with "class Object".
It is a real life example that I have run into more than once. And yes, they do do different things. However, lots of people throw around string objects when they don't need to, creating bloated programs. Since both calls allow
string str = GetName()
Many programmers think they are the same, and since "string GetName()" works, they use it without thought.
Exactly. After all, they say up front that this is a "two year project". I'm sure that after two years, they'll have lots of ideas on things to improve. But thinking like scientists, they don't want to change things midstream.
(BTW: was that 23 hours for the graphics version?)
Yeah, why just last night I wanted to crack RC5 to, er, uh...
Just what use is there to cracking RC5? Assuming you are not a government, that is?
Anybody who understands the math knows that it is merely a matter of throwing enough CPU power at it. It is only interesting as a distributed computing test.
With Seti, you get both that and an interesting question that we don't know the answer to.
Since one of the biggest optimization problems seems to be in the graphics, and since only Windows (and Mac) boxes have graphics versions, I'd think a Linux advocate would be tickled about this. It certainly makes that OS look better than Windows. (I suspect it is also one reason why Team Slashdot is currently number one.)
Having tested on many machines, it is clear that there are optimization issues, especially with graphics. You pay a lot for those pretty graphs.
Here are some of the average times I've gotten:
(WU = Work Unit)
Windows NT 4, Pentium II 350 Mhz: ~25 hours/WU Windows NT 4, Pentium II 350 Mhz, no graphics: ~12 hours/WU Linux, Pentium 75 Mhz: 65 hours/WU Windows NT 4, Pentium 150 Mhz (laptop): ~150 hours/WU Windows NT 4, Pentium 150 Mhz (laptop), no graphics: ~50 hours/WU.
(All NT boxes had "run in background" set.)
With these numbers, it is clear that the graph greatly effect performance. I suspect that the relatively superior performance on the Linux box is because NT degrades the priority of any non-foreground process.
I do wish that Seti would make this more clear at their site. It isn't immediately obvious, and I probably wouldn't have noticed myself if I hadn't wondered why my Linux box (no graphic version) seemed to do so much better than the NT PII boxes.
Still, what a lot of people miss is that this is an experiment. We shouldn't expect perfection immediately.
As for the source, well, I agree with Seti on this. The danger of muddying the results is far too great. In essence, we are donating CPU time. In doing so, it is basically theirs to do as they see fit. It is not us running a program for ourselves. It is them running a program using us as helpers. If you don't like that, don't participate.
Barring bit twiddling to save individual bytes, a good design usually is an efficient design. Those two things aren't necessarily trade-offs the way size versus speed is. It doesn't take a lot of effort to say "Hey, this list ought to have a tail pointer" when you first create the code. Probably a lot less then retrofitting the code later. (To take an actual C instance I ran into years ago.) Experience helps you learn to do those kind of things as second nature, without wasting time at all. Experience says that
string GetName()
is less efficient than
string& GetName()
Too many programmers write the former without thought, see that it works, and declare themselves done and later wonder at the complaints of slowness. Yes, a profiler tells you what you did wrong, with a line like "90% string()", but why not learn to head the problem off at the pass?
The real trade-off is efficiency versus initial design time. Far too often, people speed through the beginning phases of a project at the cost of maintainability, flexibility and efficiency. You have to spend an hour or two thinking to save a hundred hours debugging, tuning and reworking in a year.
I agree in general, but then, there are times it is better to use the flat array rather than the vector. (Though believe me, having rolled my own dynamic arrays multiple times, I adore std::vector.)
Anyway, I'm talking about code I cleaned up, written by someone who had no concept of efficiency. It worked fine in a test environment, but in the real world, it became unmanagably slow.
I got paid a lot to clean that up, too.
Virtual memory has made people sloppy. I'm not talking about saving bits and bytes. I am talking about simply knowing that
new char a[100];
and
new char a[100000];
are different, performancewise. A lot of younger programmers have no concept of that, and so produce slower code. I've done the latter when it made sense. The key is knowing that there is a potential issue. It is part of good design to know all the issues.
Money's the thing. Companies are always willing to pay contractors more than salaried employees (even counting benefits).
I suspect that a big part of it is that if an older programmer were paid the salaray he was "worth" (given supply and demand) he would make more than his manager. Managers don't like that as it conflicts with the corporate class structure. So instead, they pay a contractor even more, but because this is outside the salary structure, they can pretend they are still more highly paid than their employees.
A company I used to contract for once offered me a salaried position. The salary they were offering me was quite literally 60% of what I was making as contracting full time for them (and my contract house had better benefits.) And they wondered why I laughed at them...
One the other hand, you young turks have never had the experience of having to fit real functionality in 140k, and that often shows. About ten years ago, the industry was flooded with extremely competent immigrant Russian programmers. They were so competent because they had to deal with crappy, slow equipment with little memory.
I don't know how many times I've come across code that was woefully inefficient and only ran because of the fast processors that were thrown at it. What both companies and young programmers don't always understand is that talent only takes you so far. You need experience to go the distance.
(Your post did bring back memories, though. When I came out of college, I immediately went to work at the current "hot technology" (TSR programming, for those who still know what that is.) and was screwed, salarywise, but a shady operator for about a year before I got smart.)
As someone who is rapidily approaching old age (34), perhaps I can give some insight for the youn 'uns.
Maintaining a successful career as a programmer is not an easy thing. It is not like being a plumber, where you learn your trade and then perhaps do a little studying from time to time. You have to be careful and you have to be observant.
I found myself oh so close to trouble recently because while everyone else was moving towards Windows and the internet, I was spending my working time as an OS/2 programmer. Why? Well, they paid me gobs. It almost killed my career, though, as I found when I finally got fed up with that place. Recruiters looked not at my ten years experience, but at my relatively weak Windows experience. Fortunately, I was able to leverage what Windows I had and some application domain knowledge into a new job that, while is lower paying, will give me a killer resume.
The lesson? Money isn't everything. It is really easy to get sucked into high paying jobs that are death to your career. It is also very easy to become complacent, and say to yourself that you'll start looking for a new job in a few months.
Before the anti-Windows flames start, let me say that I am busy practicing my Linux programming at home. Which brings me to another problem. Off-time experience is no experience from the standpoint of most employers. You can be the biggest Linux expert in the world, but if you can't point to a job where your title was "Linux developer" or a test you passed with "Linux" in the title, many prospective employers won't want to hear from you.
(Actually, I suspect most Linux shops are better about this. My experience was with Windows, where I'd written much in my spare time only to be confronted with questions on my lack of Windows experience. However, as Linux grows in popularity, you'll find more "old-school" employers who think exactly like that.)
So even if you think you know technology "X", go take a class in "X". Sure, you'll be bored, but you'll have that all-important piece of paper saying you know it. Get any certifications you can, even if you think that tests are a poor indication of ability. Many employers don't, and that is what is important.
Another big cause of this problem is the way salaries top out for programmers. When I was younger, my salary grew with leaps and bounds. Now, I am pretty much near the top, which means most companies are loath to pay more. That can be hard psychologically if you've gotten used to the hefty raise every year. One way around it is to become a contractor, though that has its own pitfalls. (Biggest one: no one will pay to train you.)
Finally, don't wed yourself to a technology. Don't think of yourself as a linux programmer. Think of yourself as a programmer who is doing linux right now. Believe me, you'll be better off, regardless of how superior linux is, both because superiority is not a guarantee of survival and because something better may well come along. Lots of OS/2 programmers felt the same way. Stick your nose into lots of things, even Windows. (You'll need to hold it, believe me...) Take lots of classes. Try to get your employer to assign you a variety of tasks. And above all, keep a keen eye on those technological currents, even when you've settled down with a wife and a mortgage.
I concur bigtime. My worst "CTS" type pain has come from pathological mousing.
One thing that has worked real well for me is to teach myself to become ambidextrous when it comes from the mouse. It is not as hard as it seems and it helps a lot.
Track balls also seem to be worse then normal mice. I had to give mine up.
I held off as long as I could, but Microsoft (sadly) seems to have won the development tool war on Windows. It makes me sad because Turbo C was the first piece of PC software I ever bought.
Slashdot Mirror
The danger isn't that Linux will win, or that Linux will lose. The danger is that one day, we will be faced with ftp directories like:
cool-mp-player-ms-linux.2.2.1.bzip requires alib
cool-mp-player-ibm-linux.2.2.1.bzip requires blib
cool-mp-player-gnu-linux.2.2.1.bzip
bzip-torvalds-linux.0.99-2.tar requires clib
blib-3.4.1.bzip doesn't support ms-linux
blib-3.4.2.bzip ms-linux support added
alib-2.2.42-11.bzip requires gnu linux.
alib-2.2.42-12.bzip added torvalds linux supprt
clib-ms-linux-31.2.bzip requies alib
Now multiply that by 500 applications.
Now add different hardware with different drivers (or no drivers) on particular versions of software.
Personally, I don't want to deal with that. It is bad enough already with different versions of the c library
Well, this is the funniest damn thing I've read in a while. That is an incredible understatement. What Windows has is pretty much the same problem that people are talking about here. It is just that there are a lot of GUI tools to help straighten it out. Still, I'm a Windows developer (who has written DLLs), yet I can't figure out why my &#$# Win95 machine starts complaining about a missing MPR.DLL at random times. (And then there is the "minor" change that Microsoft recently made to one of the MFC DLLs that broke our application in certain cases. Not so fun given Microsoft's penchant for upgrading DLLs under the covers at every opportunity.)
The longer I work in this industry, the more I agree with another Dr. Dobbs editorial. DLLs, dynamic linking, whatever you call it, causes more problems then it fixes, especially in these days of $200 20 gig disks and $70 64 meg SIMMs.
At the moment, I work for a Windows developer, and our particulary product uses DLLs in order to support multiple types of configurations. The amount of work keeping multiple versions of DLLs and calling executables straight is immense, and it is too damn easy to make a "trivial" change that kills backwards compatibility.
As a relative Linux newbie, I used to think the situation there was better, especially with the Red Hat RPM system. Hah! After one novice attempt at installing egcs, I somehow managed to screw up my system entirely to the point where "hello world" wouldn't compile. It was a month of off and on work to get to the point where I could compile a program again. (Hell, the streamio library segfaults still, but I don't have the energy to figure out if this is a configuration issue.) (And all this because I just wanted to play with bitset.)
Versioning is a huge problem that seems to effect both Windows and Linux equally. Current attempts to fix it (Windows COM+, for one) don't seem to really work. I say, scrap the whole thing and static link everything. If you include the libraries you need in your binary, it won't break when someone else screws up the system.
This reminds me of a company a few years back that would sell you a square meter of land on Mars. You're paying for a novelty piece of paper. Why not just fire up the old inkjet?
If you want to send a signal to aliens, your better off going out into the wilderness and firing one of those cheap laser pointers at the sky.
Ok, some may think this is a troll, but the truth is, at this point in the century, Bill Gates has had far more influence on the computer industry than Torvalds.
(TIME's Person of the Century is that person who, for better or worse, most influenced the course of history over the past 100 years.)
Now personally I think that this is something that ought to change, but I don't think that's gonna happen in five months.
Now let's all hope that Gates gets wedged between Hitler, Stalin and Mao. Perhaps then people will get a clue...
"A short step away" is hyperbole. It is like saying that because someone was able to get a short program typed in out of a magazine to compile that they are a "short step away" from being a professional programmer.
This is a baby step. An important one, but no where near the final one.
However, some other posters should note that this is not about creating new diseases. virus is basically a machine for inserting genetic changes into cells. Currently, these are evolved and are generally not changes that we want. However, there are a huge number of changes that we certainly do want to make. We want to cure cancer. We want to cure genetic diseases. Being able to create a virus that replaces the "bad" sequence causing the disease with the "good" sequence that doesn't is obviously a very, very good thing for us.
This does not surprise me at all because it fits in with Gates' personality. Everything I've read about he says that he is not a greedy guy. He is a power-hungry guy. Those are two very different things. I suspect that he'd give a lot more money right now if that didn't mean selling more shares (and thus giving up control (power)) to get the cash.
I once did a real world project in a OO fashion using only C as a test and while it was certainly possible, it was certainly much more work. The program worked well, was (IMHO) fairly easy to maintain, blah, blah, blah, but I could have easily written a similarly good C++ program in about 1/3 the time, and it would have been even more easy to maintain.
I'd agree with all that with the exception that the templates in the STL are incredibly useful and ought not be avoided.
Templates themselves are wildly useful, it is just that you really have to know what you are doing to get anything positive out of them. I'd say, don't use templates unless you understand exactly how the STL works, and then only use them if you can't do the same thing easily without them.
Operator overloading should only be used in certain cookie cutter ways. Creating '>' operators for io in a new class. Creating an assignment operator for a new class. That sort of thing.
IMHO, most of the "problems" of C++ come from people who overuse inheritance . Huge inheritance hierarchies are nearly always a mistake. Much better are a bunch of smaller, completely independent classes. (You know, "modularity", that thing they told you was good in school.)
The other mistake is going in expecting something like Smalltalk and then getting pissed because it is not. Part of the whole point of C++ is that you don't have to make every single line of code object-oriented. I know that is heresy for many OO types, but in the real world it is damn useful to have a language that is OO when you want it, but only when you want it. That is why C++ is so much more popular then languages that enforce OO.
Personally, I think anyone coding in C should switch to C++ even if they aren't going to go OO. C++ has some extensions over C that allow you to improve structured programs as well. Just remember that typing "g++" does not mean you have to start the project with "class Object".
It is a real life example that I have run into more than once. And yes, they do do different things. However, lots of people throw around string objects when they don't need to, creating bloated programs. Since both calls allow
string str = GetName()
Many programmers think they are the same, and since "string GetName()" works, they use it without thought.
Exactly. After all, they say up front that this is a "two year project". I'm sure that after two years, they'll have lots of ideas on things to improve. But thinking like scientists, they don't want to change things midstream.
(BTW: was that 23 hours for the graphics version?)
Yeah, why just last night I wanted to crack RC5 to, er, uh...
Just what use is there to cracking RC5? Assuming you are not a government, that is?
Anybody who understands the math knows that it is merely a matter of throwing enough CPU power at it. It is only interesting as a distributed computing test.
With Seti, you get both that and an interesting question that we don't know the answer to.
Since one of the biggest optimization problems seems to be in the graphics, and since only Windows (and Mac) boxes have graphics versions, I'd think a Linux advocate would be tickled about this. It certainly makes that OS look better than Windows. (I suspect it is also one reason why Team Slashdot is currently number one.)
If you've got the monitor off an Energy Star compliant system uses what, 30 Watts?
My god, that's nearly half of what my porch light uses. The Horror! The Horror!
Having tested on many machines, it is clear that there are optimization issues, especially with graphics. You pay a lot for those pretty graphs.
Here are some of the average times I've gotten:
(WU = Work Unit)
Windows NT 4, Pentium II 350 Mhz: ~25 hours/WU
Windows NT 4, Pentium II 350 Mhz, no graphics: ~12 hours/WU
Linux, Pentium 75 Mhz: 65 hours/WU
Windows NT 4, Pentium 150 Mhz (laptop): ~150 hours/WU
Windows NT 4, Pentium 150 Mhz (laptop), no graphics: ~50 hours/WU.
(All NT boxes had "run in background" set.)
With these numbers, it is clear that the graph greatly effect performance. I suspect that the relatively superior performance on the Linux box is because NT degrades the priority of any non-foreground process.
I do wish that Seti would make this more clear at their site. It isn't immediately obvious, and I probably wouldn't have noticed myself if I hadn't wondered why my Linux box (no graphic version) seemed to do so much better than the NT PII boxes.
Still, what a lot of people miss is that this is an experiment. We shouldn't expect perfection immediately.
As for the source, well, I agree with Seti on this. The danger of muddying the results is far too great. In essence, we are donating CPU time. In doing so, it is basically theirs to do as they see fit. It is not us running a program for ourselves. It is them running a program using us as helpers. If you don't like that, don't participate.
string GetName()
is less efficient than
string& GetName()
Too many programmers write the former without thought, see that it works, and declare themselves done and later wonder at the complaints of slowness. Yes, a profiler tells you what you did wrong, with a line like "90% string()", but why not learn to head the problem off at the pass?
The real trade-off is efficiency versus initial design time. Far too often, people speed through the beginning phases of a project at the cost of maintainability, flexibility and efficiency. You have to spend an hour or two thinking to save a hundred hours debugging, tuning and reworking in a year.
I agree in general, but then, there are times it is better to use the flat array rather than the vector. (Though believe me, having rolled my own dynamic arrays multiple times, I adore std::vector.)
Anyway, I'm talking about code I cleaned up, written by someone who had no concept of efficiency. It worked fine in a test environment, but in the real world, it became unmanagably slow.
I got paid a lot to clean that up, too.
Virtual memory has made people sloppy. I'm not talking about saving bits and bytes. I am talking about simply knowing that
new char a[100];
and
new char a[100000];
are different, performancewise. A lot of younger programmers have no concept of that, and so produce slower code. I've done the latter when it made sense. The key is knowing that there is a potential issue. It is part of good design to know all the issues.
I suspect that a big part of it is that if an older programmer were paid the salaray he was "worth" (given supply and demand) he would make more than his manager. Managers don't like that as it conflicts with the corporate class structure. So instead, they pay a contractor even more, but because this is outside the salary structure, they can pretend they are still more highly paid than their employees.
A company I used to contract for once offered me a salaried position. The salary they were offering me was quite literally 60% of what I was making as contracting full time for them (and my contract house had better benefits.) And they wondered why I laughed at them...
Talent -> Good programmer
Talent + Experience -> Great programmer
Like any of them would have...
Your lucky to get interviewed by a technical person at most companies, much less have a chance to present code.
(I did help hire a guy after seeing his source once, though.)
I don't know how many times I've come across code that was woefully inefficient and only ran because of the fast processors that were thrown at it. What both companies and young programmers don't always understand is that talent only takes you so far. You need experience to go the distance.
(Your post did bring back memories, though. When I came out of college, I immediately went to work at the current "hot technology" (TSR programming, for those who still know what that is.) and was screwed, salarywise, but a shady operator for about a year before I got smart.)
Maintaining a successful career as a programmer is not an easy thing. It is not like being a plumber, where you learn your trade and then perhaps do a little studying from time to time. You have to be careful and you have to be observant.
I found myself oh so close to trouble recently because while everyone else was moving towards Windows and the internet, I was spending my working time as an OS/2 programmer. Why? Well, they paid me gobs. It almost killed my career, though, as I found when I finally got fed up with that place. Recruiters looked not at my ten years experience, but at my relatively weak Windows experience. Fortunately, I was able to leverage what Windows I had and some application domain knowledge into a new job that, while is lower paying, will give me a killer resume.
The lesson? Money isn't everything. It is really easy to get sucked into high paying jobs that are death to your career. It is also very easy to become complacent, and say to yourself that you'll start looking for a new job in a few months.
Before the anti-Windows flames start, let me say that I am busy practicing my Linux programming at home. Which brings me to another problem. Off-time experience is no experience from the standpoint of most employers. You can be the biggest Linux expert in the world, but if you can't point to a job where your title was "Linux developer" or a test you passed with "Linux" in the title, many prospective employers won't want to hear from you.
(Actually, I suspect most Linux shops are better about this. My experience was with Windows, where I'd written much in my spare time only to be confronted with questions on my lack of Windows experience. However, as Linux grows in popularity, you'll find more "old-school" employers who think exactly like that.)
So even if you think you know technology "X", go take a class in "X". Sure, you'll be bored, but you'll have that all-important piece of paper saying you know it. Get any certifications you can, even if you think that tests are a poor indication of ability. Many employers don't, and that is what is important.
Another big cause of this problem is the way salaries top out for programmers. When I was younger, my salary grew with leaps and bounds. Now, I am pretty much near the top, which means most companies are loath to pay more. That can be hard psychologically if you've gotten used to the hefty raise every year. One way around it is to become a contractor, though that has its own pitfalls. (Biggest one: no one will pay to train you.)
Finally, don't wed yourself to a technology. Don't think of yourself as a linux programmer. Think of yourself as a programmer who is doing linux right now. Believe me, you'll be better off, regardless of how superior linux is, both because superiority is not a guarantee of survival and because something better may well come along. Lots of OS/2 programmers felt the same way. Stick your nose into lots of things, even Windows. (You'll need to hold it, believe me...) Take lots of classes. Try to get your employer to assign you a variety of tasks. And above all, keep a keen eye on those technological currents, even when you've settled down with a wife and a mortgage.
I concur bigtime. My worst "CTS" type pain has come from pathological mousing.
One thing that has worked real well for me is to teach myself to become ambidextrous when it comes from the mouse. It is not as hard as it seems and it helps a lot.
Track balls also seem to be worse then normal mice. I had to give mine up.
When I got my first modem in 1983, I soon ran into a heated post about a new "modem" tax.
Some things never change.
Whaddya know, that's when I bailed out, too.
I held off as long as I could, but Microsoft (sadly) seems to have won the development tool war on Windows. It makes me sad because Turbo C was the first piece of PC software I ever bought.