acogitosis

Mostly for my future reference. -threads 8 should be changed to the number of CPU cores (my i7 has 4 with HT, thus I set it to 8).

ffmpeg -i input.avi -acodec libfaac -ab 48k -vcodec libx264 -vpre fast -vb 500k -threads 8 -f flv output.flv

Mostly note to my self for future reference.

What they don’t tell You in the tar backup tutorial is that it’s not enough to edit /etc/fstab (and their instructions for grub are for grub-legacy).

Because after restoring you probably have new partition UUIDs, you must:

• boot livecd
• mount your root fs
• mount -B /dev /rootfs/dev, etc. (with proc and sys at least) to be able to chroot from livecd to your root fs
• chroot /rootfs
• edit /etc/fstab and change UUIDs there (new ones you can get using blkid
• do sudo dpkg-reconfigure -plow grub-pc to automatically upgrade grub config files, just let it install to the drive(s) it was on
• do update-initramfs -u so UUID stored inside initramfs get updated, too

Then you should be able to boot it.

Install VirtualBox Guest Additions in Windows’ safe-mode so system file protection doesn’t interfere with the installation, it’s that simple and fixed all my VirtualBox performance problems.

IE can’t do anything right. If you save some graphical elements to PNG, and try to put them on an area with CSS-defined color, there will be a difference even if you used the same color in the PNG — IE renders PNGs darker than it should. The reason for this is misinterpretation of gAMA frame saved in PNGs that makes it possible to better color-match pictures. The fix is to remove this frame, and doing it on Ubuntu is as easy as:

aptitude install pngcrush
cd your-graphics-directory
mkdir fixed
find . -type f -exec pngcrush -d fixed -rem cHRM -rem gAMA -rem iCCP -rem sRGB {} \;


Now you have a “fixed” directory where you have PNGs that will work properly in IE (and are a bit smaller which is a nice side effect). If you’re sure they’re ok, just do

mv fixed/* ./
rmdir fixed


That’s all.

Using Java Timer class one can schedule a task for recurring execution. Even though ScheduledThreadPoolExecutor makes it possible to create timers with nanosecond resolution (but beware of underlying operating system clock precision!), regularity of task execution is by default awful.

I have run into this once and had to explain the customer that it’s not fixable. When I measured the delay between timer executions, etc. it turned out that doing as much as new Thread(runnable).start() usually takes 1-5 milliseconds, but at times it takes two orders of magnitude longer: even half a second!

Same customer, other project and this time I thought of a reason for this behaviour: garbage collection. I started with calling System.gc() explicitly inside measured code and it takes 200-500 milliseconds! So it must be it.

Is there a solution? Of course there is. It’s called The Concurrent Low Pause Collector and has been in Java since version 5. Read the linked article for many, many details, but shortly just add:

-XX:+UseConcMarkSweepGC

to the usual java -jar command and the garbage collection will be done in parallel with your code execution. Of course it’s no golden bullet, it makes overall performance worse (now instead of 1-5 milliseconds, a single loop pass takes 4-10 milliseconds), but for this particular use, it makes Timer regularity better by two orders of magnitude.