Technical downs and ups...
Jul. 26th, 2008 08:32 amTurning the Eee into an alarm clock (which worked marvelously yesterday morning, even though I had already awakened when it went off) was actually pretty simple. Basically, one uses a Unix facility called cron to cause a command line to be exectued at a certain time. (Specification of so-called "cron jobs" is pretty flexible; the syntax allows specification of minutes, hours, days, months, days of the week, and combinations thereof.) The only other requirement at this point is to keep the Eee running until the cron job executes.
The command line I caused to be executed was a very simple script wherein I invoked the "beep" command at 1-second intervals for somewhere under two minutes, in a file that had no programmatic structure, outside of line-by-line execution (you can take what I know about bash shell programming, stick it in your eye, and barely feel any irritation).
I dug around some more on the Internet and found a how-to that invoked the Amarok music player via a facility called DCOP. Figuring I'd much rather wake up to the sound of something musical, I explored this approach. Along the way, I eventually realized that the line
However, do what I might, the command line above does not have the desired effect when run from cron (either directly or inside of a script). Scraping the 'net for information showed that others have experienced this problem, too, but I was not able to find a solution.
Ah, well... it looks like I'll just have to settle for a flock of beeps whenever I need waking. (I seem to wake up at around 5:30 am every morning anyway.)
Getting the information I need to switch domains from one hosting company to another was breathtakingly simple. In fact, I was on the verge of assigning new nameservers to the domain before I realized that it might not be a bad idea to FTP my data from the servers at the old hosting company before assigning new nameservers.
In fact, the ideal time to make the switch would be next Friday night, Colorado time, so that the 48 hours recommended for the change to propagate occurs over the weekend. Alternatively, if I download the files by tonight (this morning, Colorado time), I could make the change tonight and likely have all the dust settle by the start of business Monday morning. One thing I can do to accelerate the process is to eyeball the content in the directory structure and delete stuff that's either outdated or most certainly backed up. We'll see.
Today is a work day for the campaign, but since Alex P. and I were working the past two days (while the rest of the team basically took it easy), we are officially on "standby" status, though I think both of us are on the list of people who signed up to go into town today at 10 am. The two of us go "back to the face" tomorrow for two days of fuel loading, after which comes the phase of joint operations, during which everything comes together.
I got to talking to the prop team yesterday, as they were preparing to engage in another marathon Guitar Hero session in the TV room downstairs (how these guys can still hear anything is a miracle, if you ask me, though it might explain the system of arm signals that they use, but I digress...). It turns out that if you were to let a drop of fuel fall into a bucket of oxidizer, you'd hear a pop as the fuel was consumed in a hypergolic reaction with some oxidizer.
On the other hand, if you were to let a drop of oxidizer fall into a bucket of fuel, you'd get a gout of flame from the bucket until the fuel was exhausted. If I understood the explanation correctly, the drop of oxidizer would start things off by igniting a small amount of fuel, whereupon the oxygen in the air would be drawn into to react with more fuel, and so on, until all the fuel was consumed.
For this reason, explained Adam W., the senior prop engineer on the job, you always load the spacecraft with oxidizer first, just in case. His team is having a busy year (six campaigns, instead of the usual three), with the next job hard on the heels of this one.
Cheers...
The command line I caused to be executed was a very simple script wherein I invoked the "beep" command at 1-second intervals for somewhere under two minutes, in a file that had no programmatic structure, outside of line-by-line execution (you can take what I know about bash shell programming, stick it in your eye, and barely feel any irritation).
I dug around some more on the Internet and found a how-to that invoked the Amarok music player via a facility called DCOP. Figuring I'd much rather wake up to the sound of something musical, I explored this approach. Along the way, I eventually realized that the line
dcop amarok player playrelies on Amarok to actually already be running for the command to work. Other commands worked as expected once this conceptual stumbling block was overcome.
However, do what I might, the command line above does not have the desired effect when run from cron (either directly or inside of a script). Scraping the 'net for information showed that others have experienced this problem, too, but I was not able to find a solution.
Ah, well... it looks like I'll just have to settle for a flock of beeps whenever I need waking. (I seem to wake up at around 5:30 am every morning anyway.)
Getting the information I need to switch domains from one hosting company to another was breathtakingly simple. In fact, I was on the verge of assigning new nameservers to the domain before I realized that it might not be a bad idea to FTP my data from the servers at the old hosting company before assigning new nameservers.
In fact, the ideal time to make the switch would be next Friday night, Colorado time, so that the 48 hours recommended for the change to propagate occurs over the weekend. Alternatively, if I download the files by tonight (this morning, Colorado time), I could make the change tonight and likely have all the dust settle by the start of business Monday morning. One thing I can do to accelerate the process is to eyeball the content in the directory structure and delete stuff that's either outdated or most certainly backed up. We'll see.
Today is a work day for the campaign, but since Alex P. and I were working the past two days (while the rest of the team basically took it easy), we are officially on "standby" status, though I think both of us are on the list of people who signed up to go into town today at 10 am. The two of us go "back to the face" tomorrow for two days of fuel loading, after which comes the phase of joint operations, during which everything comes together.
I got to talking to the prop team yesterday, as they were preparing to engage in another marathon Guitar Hero session in the TV room downstairs (how these guys can still hear anything is a miracle, if you ask me, though it might explain the system of arm signals that they use, but I digress...). It turns out that if you were to let a drop of fuel fall into a bucket of oxidizer, you'd hear a pop as the fuel was consumed in a hypergolic reaction with some oxidizer.
On the other hand, if you were to let a drop of oxidizer fall into a bucket of fuel, you'd get a gout of flame from the bucket until the fuel was exhausted. If I understood the explanation correctly, the drop of oxidizer would start things off by igniting a small amount of fuel, whereupon the oxygen in the air would be drawn into to react with more fuel, and so on, until all the fuel was consumed.
For this reason, explained Adam W., the senior prop engineer on the job, you always load the spacecraft with oxidizer first, just in case. His team is having a busy year (six campaigns, instead of the usual three), with the next job hard on the heels of this one.
Cheers...