I was watching the silent science fiction epic "Woman in the Moon" (Frau im Mond) from 1929. I'd heard of and watched "Metropolis", also by Fritz Lang, but never this. This is by far the better of the two, even if the effects and such are grander in the latter. This one is more realistic, with no demonic man-eating machines and evil shaky-bitch robotic psychopaths set against a Wellsian Eloi vs Morlock class-warfare-nonsense backdrop. Instead, we have a normal society launching a rocket to the moon.
In the opening credits, my jaw dropped when I saw the name of one of the film's technical consultants, Hermann Oberth.
And indeed, the film clearly benefits. The completed multi-stage rocket is rolled out from a massive hangar on a rolling gantry platform (using rail instead of treads), and the launch plot revolves in part around the issues of escape velocity and the rocket's acceleration effects on those aboard.
The state of lunar science at the time included Hansen's notion from the 1850s that there might be atmosphere on the far side of the moon in a great depression in the surface. This, plus the idea that they were going there to find gold, are the silliest points to modern viewers, along with the divining rods being used to locate water in the form of muddy lunar soil.
But if we focus on the rocket, we see something all too familiar in the form of unrealistic special effects. Both the launch from the peculiar water bath on Earth and the launch from the moon's surface show the rocket suddenly zipping away at a constant, abnormally-high velocity. After all the talk of acceleration and the long, luxurious scenes of the rocket being rolled into place like a space shuttle, the warp-speed departure was jarring.
Reminds me of more than a few sci-fi scenes where the FX work, supposedly done a certain way for for audience benefit, just doesn't work for smart audiences.
2015-03-28
2015-03-26
QotD 2015-0326 - Tubes
From a post on Heir to the Jedi at SDN:
"Ch 15 pg 165 wrote:
Though the Empire strictly controlled the interstellar HoloNet, the Kupohans had a local system infonet set up almost of necessity to exchange weather information and help ships land safely.
The existence of planetary internets. No word on if they're a series of tubes or not."Thanks for the giggle, Balrog.
2015-03-08
Inside Baseball, Pt. II: New Site SitRep
So here is where I am now for those wondering.
All existing pages have been automagically converted to AsciiDoc and Markdown formats so the content is fairly readily usable whichever way I need to go. A few pages that are probably coming over unchanged have seen a little cleanup work done (the magic doesn't make them ready to just drop in, sadly).
Referencing the Inside Baseball post, I am currently building up the system by which I will publish the site.
The battle plan revolves around Pelican, a static site generator that accepts Markdown by design, and formerly AsciiDoc too (albeit now only via plugin). It won't work server-side unless you have a webhost that allows full Python execution, however, which would mean a virtual private server or Amazon S3 mumbo-jumbo with its buckets of unique jargon which I loathe. Both cost a little bit, and options can be found where server security is maintained automatically, but as a professional cheapskate and someone who didn't want to run a whole server for this (even a virtual one) I really didn't want to go that route. I could just use my desktop, but I've been trying to get away from leaving it running.
Enter the Pi. I acquired a Raspberry Pi some time ago for experimentation, and Pelican will execute on it happily. However, I don't want to develop content on it. The goal is thus to write elsewhere and leave the Pi as a headless Pelican execution server. With Dropbox integration (a pain in the ass on the ARM-based Pi but doable, I am told), I can write pages anywhere.
So, creating a page or post will look like this:
1. Make notes or pages saved in .txt format within my directory of choice. I can even leave them in the content directory that Pelican will later see, because it will ignore them.
2. Once complete, rename to the appropriate extension.
3. Dropbox will upload to their servers, and the Pi will download the new version based on a regular cron job.
4. Either another regular cron job or a file-change watchdog (haven't gotten there yet) will execute Pelican, rebuilding the static output of the site. (I most likely will want to do the latter.)
5. This static output will automatically be uploaded to my existing webhost.
6. Profit. And cake. (But both of those are a lie. I have neither ads nor frosting.)
7. Regularly back up the Dropbox folder.
Compared to the old 2002 era workflow, this has the advantage of allowing me to write from anywhere more readily and easily. All I need is a connection and a text editor (or even a browser through which I can log in to Dropbox) so I can make changes on the go. Even sans connectivity, if I make a change on a device of mine that can sync a Dropbox folder (e.g. a laptop) it'll hit as soon as I get back to civilization. I can even schedule when a page drops!
Pictures are a bit of a question, since I rather like my old sorting, but I can still link to old pics as-is.
But, the plan relies on two external objects (Dropbox and the Pi). However, even if one or both break, or if I do, the site is still there for as long as the hosting bill is paid up or as long as The Wayback Machine works, because it is static.
And, I don't see Dropbox going away (there are alternatives even if they break their API a la Twitter), and provided I can find an RPi B for sale I can go ahead and get backup hardware now. (Good idea ... I should write that down. Oh, wait ... does this qualify?)
One more option worth noting is that in the current plan, Blogger could go away in favor of keeping it all in-house. But then the only good way to do comments would be Disqus, at which point I might as well have it for pages, too. But that can be decided on further down the road.
The main hurdle will probably be getting my site to look just right. Jinja templates are a whole new animal for me, and I am not looking forward to that part of the Pelican build.
More to come ...
All existing pages have been automagically converted to AsciiDoc and Markdown formats so the content is fairly readily usable whichever way I need to go. A few pages that are probably coming over unchanged have seen a little cleanup work done (the magic doesn't make them ready to just drop in, sadly).
Referencing the Inside Baseball post, I am currently building up the system by which I will publish the site.
The battle plan revolves around Pelican, a static site generator that accepts Markdown by design, and formerly AsciiDoc too (albeit now only via plugin). It won't work server-side unless you have a webhost that allows full Python execution, however, which would mean a virtual private server or Amazon S3 mumbo-jumbo with its buckets of unique jargon which I loathe. Both cost a little bit, and options can be found where server security is maintained automatically, but as a professional cheapskate and someone who didn't want to run a whole server for this (even a virtual one) I really didn't want to go that route. I could just use my desktop, but I've been trying to get away from leaving it running.
Enter the Pi. I acquired a Raspberry Pi some time ago for experimentation, and Pelican will execute on it happily. However, I don't want to develop content on it. The goal is thus to write elsewhere and leave the Pi as a headless Pelican execution server. With Dropbox integration (a pain in the ass on the ARM-based Pi but doable, I am told), I can write pages anywhere.
So, creating a page or post will look like this:
1. Make notes or pages saved in .txt format within my directory of choice. I can even leave them in the content directory that Pelican will later see, because it will ignore them.
2. Once complete, rename to the appropriate extension.
3. Dropbox will upload to their servers, and the Pi will download the new version based on a regular cron job.
4. Either another regular cron job or a file-change watchdog (haven't gotten there yet) will execute Pelican, rebuilding the static output of the site. (I most likely will want to do the latter.)
5. This static output will automatically be uploaded to my existing webhost.
6. Profit. And cake. (But both of those are a lie. I have neither ads nor frosting.)
7. Regularly back up the Dropbox folder.
Compared to the old 2002 era workflow, this has the advantage of allowing me to write from anywhere more readily and easily. All I need is a connection and a text editor (or even a browser through which I can log in to Dropbox) so I can make changes on the go. Even sans connectivity, if I make a change on a device of mine that can sync a Dropbox folder (e.g. a laptop) it'll hit as soon as I get back to civilization. I can even schedule when a page drops!
Pictures are a bit of a question, since I rather like my old sorting, but I can still link to old pics as-is.
But, the plan relies on two external objects (Dropbox and the Pi). However, even if one or both break, or if I do, the site is still there for as long as the hosting bill is paid up or as long as The Wayback Machine works, because it is static.
And, I don't see Dropbox going away (there are alternatives even if they break their API a la Twitter), and provided I can find an RPi B for sale I can go ahead and get backup hardware now. (Good idea ... I should write that down. Oh, wait ... does this qualify?)
One more option worth noting is that in the current plan, Blogger could go away in favor of keeping it all in-house. But then the only good way to do comments would be Disqus, at which point I might as well have it for pages, too. But that can be decided on further down the road.
The main hurdle will probably be getting my site to look just right. Jinja templates are a whole new animal for me, and I am not looking forward to that part of the Pelican build.
More to come ...
Subscribe to:
Posts (Atom)