GNU/Linux
Google Earth trip video capture in GNU/Linux with Yukon/Seom
by plouj on Jul.15, 2009, under GNU/Linux, HOWTO, hacks, tools, video
This is documentation of how I used Yukon and Seom to video capture a Google Earth trip for a recent video project in Fedora 10. I used the official installation guide as a starting point.
Compile the Seom library
I choose to install both Seom and Yukon in a custom prefix /home/plouj/yukon, rather than the system wide /usr or /usr/local.
$ svn co https://devel.neopsis.com/svn/seom/branches/packetized-stream seom $ cd seom $ ./configure --prefix=/home/plouj/yukon --arch="x86" --cflags="-W -Wall" && \ make CC="gcc -m32" && make install LIBDIR="lib"
Note that “–arch=”x86″ and “-m32″ are only necessary for me because my operating system is 64bit and I need 32bit versions of seom and yukon (to work with 32bit Google Earth).
Compile and install Yukon
$ svn co https://devel.neopsis.com/svn/yukon/branches/rewrite yukon $ cd yukon $ ./configure --prefix=/home/plouj/yukon/ --libdir="lib" --arch="x86" && \ make CC="gcc -L/home/plouj/yukon/lib -I/home/plouj/yukon/include -m32" && \ make install
Install Google Earth for Linux
Obviously get it here: http://earth.google.com/
Modify the Google Earth startup script
Since I chose /home/plouj/bin/ as the “Binary path” for Google Earth I was editing /home/plouj/bin/googleearth. All I had to do was to add yukon/seom library and executable paths at the end of the script:
...
cd "${GOOGLEEARTH_DATA_PATH}/"
LD_LIBRARY_PATH=/home/plouj/yukon/lib/:$LD_LIBRARY_PATH \
PATH=/home/plouj/yukon/bin:$PATH exec yukon "./googleearth-bin" "$@"
instead of the original:
cd "${GOOGLEEARTH_DATA_PATH}/"
exec "./googleearth-bin" "$@"
Capture
Finally, the capture process is well documented on the Yukon website.
HOWTO increase Blender’s memory cache limit for command line renders
by plouj on Jun.08, 2009, under GNU/Linux, HOWTO, hacks
Blender sequencer gives the ability to optimize rendering of repeated frames by keeping the first result in memory cache and re-using it. Depending on the project, it might be necessary to increase this limit beyond the default 32MB. If the limit is surpassed while rendering a single frame, Blender clears the cache before proceeding to the next frame and the re-renders everything from scratch.
Increasing the cache limit is easy to do in the UI:

This setting is stored in the user’s preference file (~/.B.blend on Linux systems) and, therefore, applies to all projects. However, rendering from the command line requires using the -b argument, which explicitly ignores the user’s preference file. Apart from editing and re-compiling the Blender source code, I found only one way to increase the memory cache limit.
The trick is to use a Python script, like below, to change the user preferences before rendering the scene:
import sys import bpy def main(): bpy.config.sequenceMemCacheLimit=4096 if __name__ == '__main__': main()
Add the script to the command line like this:
./bin/blender -b sample-static-text.blend -P render_settings.py -a
Note that the order of arguments matters because first we need to load the scene (with -b), then change settings through Pythons (using the -P option) and finally render the animation (with -a). Also, you need at least version 2.49a of Blender for this to work.
For reference, here’s is the the source file which hardcodes the 32MB limit:
intern/memutil/intern/MEM_CacheLimiterC-Api.cpp:
...
static intptr_t & get_max()
{
static intptr_t m = 32*1024*1024;
return m;
}
...
OpenDNS in Fedora with corporate DHCP and DNS with NetworkManager
by plouj on Apr.20, 2009, under GNU/Linux, HOWTO, hacks
Here is how to configure a Fedora workstation to use OpenDNS nameservers in a network with corporate DNS and DHCP servers without loosing access to their services.
This was done on a Fedora 9 machine with dnsmasq being the local DNS server. It should also work on newer Fedora versions and even other GNU/Linux distributions.
The setup is actually very simple and unobtrusive. It is only necessary to properly configure a local DNS server and then force 127.0.0.1 to be used as the only nameserver instead of the corporate DNS servers.
First you need to configure dnsmasq as follows:
/etc/dnsmasq.conf
# don't use the /etc/resolv.conf file anymore no-resolv # OpenDNS nameservers: server=208.67.222.222 server=208.67.220.220 # Force corporate nameservers for corporate.domain.com lookups # OpenDNS wouldn't be able to answer such queries correctly # adjust to suit your network server=/corporate.domain.com/10.1.1.1 server=/corporate.domain.com/10.1.1.2 # only respond to queries from the local machine listen-address=127.0.0.1 bind-interfaces conf-dir=/etc/dnsmasq.d
Then you need to go into NetworkManager and set 127.0.0.1 as the DNS server to be used:

This will result in the following important settings added to your network scripts:
DNS1=127.0.0.1 PEERDNS=no
I’ve noticed two minor problems with this setup:
- the corporate DNS server names are hardcoded in the configuration. Usually they are determined automatically by the DHCP client.
- restarting the dnsmasq service sometimes shows this error:
dnsdomainname: Host name lookup failure
Lexmark E250DN IPP Printing in CUPS
by plouj on Jun.22, 2008, under GNU/Linux
I just finished setting up my newly purchased monochrome duplex network printer – Lexmark E250DN. It took me a while to figure out how to configure CUPS on my GNU/Linux/Fedora machines to communicate with this printer. The problem was that I just didn’t know what URI to use for the printer. Unsurprisingly, the PDF and HTML documents that came with the printer didn’t mention such information. After all, why would Windows users need to know that if they can simply run the printer-specific utility to configure everything for them? Sheesh… Anyways. The CUPS manual was actually quite useful in listing common printer URIs. It turned out that the Lexmark URI lpd://printer-address/ps and a Generic PostScript driver worked quite well. In fact, the “/ps” part seems to be irrelevant, so simply lpd://printer.lan worked for me. However, the CUPS manual also suggested avoiding the LPD protocol if the printer supported other protocols. Using nmap I confirmed that my printer has at least something running on the IPP port (631):
$ nmap printer.lan Starting Nmap 4.53 ( http://insecure.org ) at 2008-06-22 20:39 EDT Interesting ports on printer.lan (10.1.1.7): Not shown: 1705 closed ports PORT STATE SERVICE 21/tcp open ftp 79/tcp open finger 80/tcp open http 515/tcp open printer 631/tcp open ipp 5001/tcp open commplex-link 8000/tcp open http-alt 9100/tcp open jetdirect 10000/tcp open snet-sensor-mgmt Nmap done: 1 IP address (1 host up) scanned in 0.396 seconds
After a bit of trial and error, I discovered that simply using the http://printer.lan:631 or ipp://printer.lan URI and a Generic PostScript driver worked without problems with E250DN.
Apart from these initial pains I am quite happy to be able to print double-sided black-and-white documents from all of my home computers.
Side Note:
During the investigation process, I noticed that Fedora’s system-config-printer utility prints the following information to the terminal when I tell it the IPP printer hostname:
...
printer.lan: /usr/lib/cups/backend/snmp "${HOST}" 2>/dev/null
printer.lan: hp-makeuri -c "${HOST}" 2> /dev/null
No ID match for device ipp://printer.lan:
<manufacturer>Lexmark</manufacturer>
<model>E250dn 6216N4G LE.PM.P121 -- Part Number -</model>
<description>Lexmark E250dn 6216N4G LE.PM.P121 -- Part Number -</description>
<commandset></commandset>
Using textonly.ppd
...
I wonder how I could get that XML-ish output myself. It doesn’t seem to come from hp-makeuri.
