Amen, brother! Professorships are difficult to get, and until you get tenure, they are really crappy jobs too.
Overall a general problem is the number of jobs for a PhD in ANY particular field is going to be relatively small and subject to fluctuations. The parent must be a recent grad with a PhD in a field that is doing OK now. Good for him, but that is not typical, especially because graduate student production is completely insulated from any type of market response.
For a good primer on the topic, a somewhat obscure, but classic book from the mid-90's is "Soothing the Establishment: the Impact of Foreign-born Scientists and Engineers on America". Mildly controversial at the time, but filled with good facts and figures (very dry reading however) and useful for an overall picture of employment trends. One of my favorite little factoids, was that in 1965 doctors and lawyers made the same same as a scientist. By 1985, they were making almost twice as much. Hmmmm. Wonder why we are producing so many lawyers (although the salaries of lawyers and doctors are now declining relatively speaking).
I have a Ph.D. in Physics. Glad I have it. Wouldn't recommend it.
And one of the most underutilized features of screen is multi-user sessions. I have used this to do XP-style programming with a colleague who was working 900 miles away
The way I did it:
Start up screen with a temporary screenrc file that contains:
multiuser on
addacl other_username
detach
Note that I have the screen session detach. Type "screen -ls" to get the screen session name (for the other person), then type "screen -r" to reattach. The other person ssh'd into my machine and typed "screen -x session_name". It is possible to script all of this to make it easier.
We then talked over the phone (headphones highly recommended) while we could simultaneously edit in a vi session. It was hilarious because we'd start yelling at each other "No,no, let ME type." Still, these sessions are always among my most productive programming sessions because we catch each others mistakes and program the parts of the program that we have expertise in.
I highly agree that klipper is an awesome tool. Here are some other tricks:
Have global shortcut that pops up the buffer history at mouse position. Very useful for grabbing things quickly without using the mouse.
Here is a useful alias:
alias clip dcop klipper klipper getClipboardContents
Typed from the command line, it echos the most recent contents in your clipboard buffer. You can do something like (in tcsh):
urlview `clip`
if you have a web address highlighted, and it will pop it up from the commandline. In my opinion, the interface of shell and the windowing environment via dcop is one of the reasons why I'm a die-hard KDE fan. They need more of this type of stuff.
For example, I would love a technique to pull in klipper selections into vim. If I want to paste quotations from a web page, I can currently, highlight various selections sequentially, and then use my keyboard stroke to pop up klipper, choose my selection, and then middle mouse button it in. Not bad, especially since I can do the klipper selections without a mouse. But I want to get rid of that middle mouse button step. It slows me down.
Oh, and one more tip that I haven't seen mentioned:
People mention using CTRL-SHIFT-L to pop open the open URL dialog in Mozilla, but I have found the CTRL-t (open tab) to be better. Mozilla places the focus in the URL bar and you can do a CTRL-V to paste in your selected URL. Very handy.
Also note that the normal shell/GNU readline keystrokes work in the URL bar:
CTRL-a goes to beginning of line, CTRL-k deletes the line, etc. (in tcsh, you can use bindkey to see these settings. Not sure about bash).
The RadioTiVo idea got its own slashdot article awhile ago (too lazy to look up the article) so no, you aren't that original. From that discussion, I found out that you can use mplayer and your computer to do an easy radio Tivo. This is how I listen to NPR.
The key command is:
mplayer -cache 256 -ao pcm -aofile $wav_file http://someinternetradiostation/
This records a wav file (anyone know how to get mplayer to record directly to mp3? Couldn't find out how to do it from the docs). Note the cache option which wasn't mentioned in the earlier slashdot thread: I found that I get skips all the time without it.
I then set up a shell script and a cron job to record my shows after checking the listings on the web page. The nice thing about this option is that it is easy to understand and infinitely flexible - I have my script label my song by date and show so that I can access it easily. Here is my complete shell script for the geek-wannabee's out there (having problems with the lameness filter so it's not commented here):
suffix=`date +"%Y-%m-%d"`
wav_file=$1"_"$suffix.wav
mp3_file=$1"_"$suffix.mp3
seconds=$2
cd directory_where_I_store_my_files
mplayer -cache 256 -ao pcm -aofile $wav_file http://someinternetradiostation.net/ &
sleep $seconds
killall mplayer
lame -V -h $wav_file $mp3_file
/bin/rm -f $wav_file
artist=""
if [[ ${mp3_file:0:3} == TAL ]]; then
artist="This American Life"
song=${mp3_file:4:10}
elif
yadayadayada
fi
if [ ! "$artist" == "" ]; then
album=$artist
mp3info -a "$artist" -l "$album" -t "$song" "$mp3_file"
fi
And I'm surprised to hear that you are surprised since fluid modeling is one of the applications that do very well with the vector processors that the Earth Simulator uses. I attended a lecture by Dr. Sato, head of the Earth Simulator, who stated that the best application usage was 65% peak usage (the theoretical peak which assumes that the processor always has data to crunch and no branches) and the average was 30% of theoretical peak. By contrast, typical fluid-like codes on current U.S. machines typically get less than 10% of peak usage if they have any type of implicitness (currently the magnetohydrodynamics code I use gives about 6% usage on an IBM SP that is #5 on the Top 500 supercomputer list).
I get tired of seeing figures that compare peak flop rates and then don't mention that actually code usage isn't keeping up at all. The Japanese (and Europeans who are allowed to buy NEC machines) are absolutely spanking the US when it comes to fluid codes (for climate modeling for example) and it is largely because they are using vector machines with their old highly optimized Fortran (or High Performance Fortran) codes. The MPP revolution in the U.S. has been manna for the CompSci community, but has set the computational physics community back by 10 years (except for those lucky bastards with embarrassingly parallel jobs).
I would give up an unnecessary body part for an Earth Simulator.
I remember that being a family event for my house.
I remember it being a big family event at my house too. I was watching it with my mom and two brothers and we were on the final episode. I was in the back of the room, my mom was in a chair in front of me on my left, my younger brother was lying on the couch in front of me on my right, and my older brother was lifting weights in the middle of the room while watching TV (why? I don't know).
Well one of the clamps holding the weights had broken because my brother over-tightened it so he took off that clamp and then took off the other so that it was balanced. You can see what's coming.
During an extremely suspenseful moment, my older brother is standing there just holding the weights at chest level, eyes glued to the screen. The bar on the right slowly tips down to the right. My eyes are diverted from the TV screen by the weight which slides off the bar and "Bam!" right onto my younger brothers head.
"Oh, no!", my older brother cried and tilted the bar the other way causing a weight on the left to slide off and hit my mom's leg causing her to scream in pain. My older brother and I rush to my younger brother who has this dazed look on his face and is holding his head. He doesn't realize that his hand is filling up with blood. He looks at my older brother and says, "You dork" very softly. He then realized that his hand was all wet and pandemonium ensued.
As my family is rushing out the door to go to the hospital, I start arguing with my mom over whether I can stay and watch V. The argument didn't last long. I never did find out what happened.
Sigh!
I have been wanting to rent the whole series for the past 10 years to find out what I missed and if it's as enjoyable as I remember it, but it is too much of a commitment.
I can't believe the amount of crap being posted here, and this is fairly typical.
a) lack of dynamic memory allocation --- plain shit, nothing you can do about
You obviously don't know a thing about f90. Dynamic memory allocation is the first thing everyone converting an f77 code uses. Yes f77 is dated. Go pick up the f90 book by Cooper-Redwine and read the first chapter. Really, f90 is fairly clean.
b) everything is passed by reference - no recursion whatsoever
Inconvenient, but it makes for much easier optimization. For recursion, there are tricks in f90 now that allow you to overcome most of the obstacles.
The compilers are unbeliveably crash and bad. And I've tried both Sun and SGI f95 compilers... Sucessfully segfaulted them both within a few days of using them... Funnily enough NAG f95 compiler for linux seems to be quite stable.
I agree that Sun's f90 compilers are crap (although there f77 compilers are excellent), but SGI's is quite good. I use every advanced feature of F90 possible (derived types, pointers, allocatable arrays, operator overloading, etc.), and SGI's works quite well.
c) Surprisingly hard to interoperate with f77 or C, becaused modules get funnly pre/suffixes all over the place...
I've never had problems with f77 but I agree with about C. A bigger problem with f90 is that the array structure is compiler dependent. This was done to allow the compiler writers more flexibility in optimizing their code, especially for parallelization issues, but given the way high performance computing is moving (in the U.S. anyway), it is a pain.
If you want to use f90 on Linux, I highly recommend the Lahey-Fujitsu compiler. This produces nice fast code with good error checking. They seem to focus more on Windows than Linux which I dislike, but it is still a solid product. Also quite good is Portrand Group
Here is some recommended links from them that all of the "Fortran sucks" crowd should read:
prentice
In the U.S., the HPC community is clearly moving towards using C/C++ especially for the libraries (such as POOMA, Blitz,... that the parent poster mentioned). I've seen codes that have been POOMAized and they've run much slower than the original f90 versions. The POOMA guys talk about the fact that they will get their libraries further optimized, but it still remains to be seen. I saw a talk by the BLITZ people on how they are TRYING to get C++ as fast as C, which makes me think they should just use f90. My big complaint with these library writers is that they typically work with relatively simple problems -e.g., Poisson's equation- and then think that it will work for everything. I have yet to see a fluid code that uses these libraries and really fly.
As scientific problems become harder, the associated numerical algorithms become harder, and the codes more sophisticated and flexible. So agree that f77 is inadequate for any modern, real code, but that is hardly news. While the U.S. HPC community seems to be focussing on trying to get C/C++ up to snuff, it seems that Europe and Japan are pushing f90 or high performance fortran. I personally think we (the U.S.) are heading down the wrong path.
The basic reason why I use F90 is: I'm a physicist, not a computer scientist. Yes, I agree that you can have fast code with C, but it is much harder.
Slashdot Mirror
http://www.vimoutliner.org
If you are comfortable with vi/vim, then it really can't be beat.
Overall a general problem is the number of jobs for a PhD in ANY particular field is going to be relatively small and subject to fluctuations. The parent must be a recent grad with a PhD in a field that is doing OK now. Good for him, but that is not typical, especially because graduate student production is completely insulated from any type of market response.
For a good primer on the topic, a somewhat obscure, but classic book from the mid-90's is "Soothing the Establishment: the Impact of Foreign-born Scientists and Engineers on America". Mildly controversial at the time, but filled with good facts and figures (very dry reading however) and useful for an overall picture of employment trends. One of my favorite little factoids, was that in 1965 doctors and lawyers made the same same as a scientist. By 1985, they were making almost twice as much. Hmmmm. Wonder why we are producing so many lawyers (although the salaries of lawyers and doctors are now declining relatively speaking).
I have a Ph.D. in Physics. Glad I have it. Wouldn't recommend it.
The way I did it:
Start up screen with a temporary screenrc file that contains:
multiuser on
addacl other_username
detach
Note that I have the screen session detach. Type "screen -ls" to get the screen session name (for the other person), then type "screen -r" to reattach. The other person ssh'd into my machine and typed "screen -x session_name". It is possible to script all of this to make it easier.
We then talked over the phone (headphones highly recommended) while we could simultaneously edit in a vi session. It was hilarious because we'd start yelling at each other "No,no, let ME type." Still, these sessions are always among my most productive programming sessions because we catch each others mistakes and program the parts of the program that we have expertise in.
Have global shortcut that pops up the buffer history at mouse position. Very useful for grabbing things quickly without using the mouse.
Here is a useful alias:
alias clip dcop klipper klipper getClipboardContents
Typed from the command line, it echos the most recent contents in your clipboard buffer. You can do something like (in tcsh):
urlview `clip`
if you have a web address highlighted, and it will pop it up from the commandline. In my opinion, the interface of shell and the windowing environment via dcop is one of the reasons why I'm a die-hard KDE fan. They need more of this type of stuff.
For example, I would love a technique to pull in klipper selections into vim. If I want to paste quotations from a web page, I can currently, highlight various selections sequentially, and then use my keyboard stroke to pop up klipper, choose my selection, and then middle mouse button it in. Not bad, especially since I can do the klipper selections without a mouse. But I want to get rid of that middle mouse button step. It slows me down.
Oh, and one more tip that I haven't seen mentioned:
People mention using CTRL-SHIFT-L to pop open the open URL dialog in Mozilla, but I have found the CTRL-t (open tab) to be better. Mozilla places the focus in the URL bar and you can do a CTRL-V to paste in your selected URL. Very handy.
Also note that the normal shell/GNU readline keystrokes work in the URL bar:
CTRL-a goes to beginning of line, CTRL-k deletes the line, etc. (in tcsh, you can use bindkey to see these settings. Not sure about bash).
The key command is:
mplayer -cache 256 -ao pcm -aofile $wav_file http://someinternetradiostation/
This records a wav file (anyone know how to get mplayer to record directly to mp3? Couldn't find out how to do it from the docs). Note the cache option which wasn't mentioned in the earlier slashdot thread: I found that I get skips all the time without it.
I then set up a shell script and a cron job to record my shows after checking the listings on the web page. The nice thing about this option is that it is easy to understand and infinitely flexible - I have my script label my song by date and show so that I can access it easily. Here is my complete shell script for the geek-wannabee's out there (having problems with the lameness filter so it's not commented here):
/bin/rm -f $wav_file
suffix=`date +"%Y-%m-%d"`
wav_file=$1"_"$suffix.wav
mp3_file=$1"_"$suffix.mp3
seconds=$2
cd directory_where_I_store_my_files
mplayer -cache 256 -ao pcm -aofile $wav_file http://someinternetradiostation.net/ &
sleep $seconds
killall mplayer
lame -V -h $wav_file $mp3_file
artist=""
if [[ ${mp3_file:0:3} == TAL ]]; then
artist="This American Life"
song=${mp3_file:4:10}
elif
yadayadayada
fi
if [ ! "$artist" == "" ]; then
album=$artist
mp3info -a "$artist" -l "$album" -t "$song" "$mp3_file"
fi
Enjoy.
I get tired of seeing figures that compare peak flop rates and then don't mention that actually code usage isn't keeping up at all. The Japanese (and Europeans who are allowed to buy NEC machines) are absolutely spanking the US when it comes to fluid codes (for climate modeling for example) and it is largely because they are using vector machines with their old highly optimized Fortran (or High Performance Fortran) codes. The MPP revolution in the U.S. has been manna for the CompSci community, but has set the computational physics community back by 10 years (except for those lucky bastards with embarrassingly parallel jobs).
I would give up an unnecessary body part for an Earth Simulator.
Actually my mom suffered more pain. She had a bruise that took a long time to heal.
I remember it being a big family event at my house too. I was watching it with my mom and two brothers and we were on the final episode. I was in the back of the room, my mom was in a chair in front of me on my left, my younger brother was lying on the couch in front of me on my right, and my older brother was lifting weights in the middle of the room while watching TV (why? I don't know). Well one of the clamps holding the weights had broken because my brother over-tightened it so he took off that clamp and then took off the other so that it was balanced. You can see what's coming.
During an extremely suspenseful moment, my older brother is standing there just holding the weights at chest level, eyes glued to the screen. The bar on the right slowly tips down to the right. My eyes are diverted from the TV screen by the weight which slides off the bar and "Bam!" right onto my younger brothers head.
"Oh, no!", my older brother cried and tilted the bar the other way causing a weight on the left to slide off and hit my mom's leg causing her to scream in pain. My older brother and I rush to my younger brother who has this dazed look on his face and is holding his head. He doesn't realize that his hand is filling up with blood. He looks at my older brother and says, "You dork" very softly. He then realized that his hand was all wet and pandemonium ensued.
As my family is rushing out the door to go to the hospital, I start arguing with my mom over whether I can stay and watch V. The argument didn't last long. I never did find out what happened.
Sigh!
I have been wanting to rent the whole series for the past 10 years to find out what I missed and if it's as enjoyable as I remember it, but it is too much of a commitment.
a) lack of dynamic memory allocation --- plain shit, nothing you can do about
You obviously don't know a thing about f90. Dynamic memory allocation is the first thing everyone converting an f77 code uses. Yes f77 is dated. Go pick up the f90 book by Cooper-Redwine and read the first chapter. Really, f90 is fairly clean.
b) everything is passed by reference - no recursion whatsoever
Inconvenient, but it makes for much easier optimization. For recursion, there are tricks in f90 now that allow you to overcome most of the obstacles.
The compilers are unbeliveably crash and bad. And I've tried both Sun and SGI f95 compilers... Sucessfully segfaulted them both within a few days of using them... Funnily enough NAG f95 compiler for linux seems to be quite stable.
I agree that Sun's f90 compilers are crap (although there f77 compilers are excellent), but SGI's is quite good. I use every advanced feature of F90 possible (derived types, pointers, allocatable arrays, operator overloading, etc.), and SGI's works quite well.
c) Surprisingly hard to interoperate with f77 or C, becaused modules get funnly pre/suffixes all over the place...
I've never had problems with f77 but I agree with about C. A bigger problem with f90 is that the array structure is compiler dependent. This was done to allow the compiler writers more flexibility in optimizing their code, especially for parallelization issues, but given the way high performance computing is moving (in the U.S. anyway), it is a pain.
If you want to use f90 on Linux, I highly recommend the Lahey-Fujitsu compiler. This produces nice fast code with good error checking. They seem to focus more on Windows than Linux which I dislike, but it is still a solid product.
Also quite good is Portrand Group
Here is some recommended links from them that all of the "Fortran sucks" crowd should read: prentice
In the U.S., the HPC community is clearly moving towards using C/C++ especially for the libraries (such as POOMA, Blitz,... that the parent poster mentioned). I've seen codes that have been POOMAized and they've run much slower than the original f90 versions. The POOMA guys talk about the fact that they will get their libraries further optimized, but it still remains to be seen. I saw a talk by the BLITZ people on how they are TRYING to get C++ as fast as C, which makes me think they should just use f90. My big complaint with these library writers is that they typically work with relatively simple problems -e.g., Poisson's equation- and then think that it will work for everything. I have yet to see a fluid code that uses these libraries and really fly.
As scientific problems become harder, the associated numerical algorithms become harder, and the codes more sophisticated and flexible. So agree that f77 is inadequate for any modern, real code, but that is hardly news. While the U.S. HPC community seems to be focussing on trying to get C/C++ up to snuff, it seems that Europe and Japan are pushing f90 or high performance fortran. I personally think we (the U.S.) are heading down the wrong path.
The basic reason why I use F90 is:
I'm a physicist, not a computer scientist. Yes, I agree that you can have fast code with C, but it is much harder.