Quickly Convert .webm Files to .mp4 Format [Fedora]

Recently I made a very basic screencast using the built-in tools on Fedora (how-to here).

Once I’d recorded everything I realised that my trusty Mac (well, iMovie to be specific), had no idea what to do with a .webm video file.

And neither did I.

Sigh.

Read moreQuickly Convert .webm Files to .mp4 Format [Fedora]

Find Files Installed by Yum

Yum is great isn’t it? All you do is tell it the name of the program or library and off it goes, installing files all over your computer, ready for you to use at the drop of a hat.

However, sometimes it’s nice to know a little bit more about what yum is up to. Have you ever found yourself hunting all over your hard drive, trying to find exactly where yum has installed something?

Me too.

Well, if you do ever need to quiz yum, the following commands will allow you to gather all the knowledge you need on what your latest install has done.

As with pretty much everything on Linux, yum keeps a record of what it does. This record lives in:

/var/log/yum.log

So you could take a look in this file and see what packages were installed on what date.

But wait!

Yum itself has a history command, so you can also see this information in a much prettier way by typing:

yum history

yum history

And then using the ID in the left column to get more information about each record:

yum history info 24

Finally, and most importantly, what if you need to know where yum has installed all the files from your latest update?

Well, yum uses rpm for installation, so you can use it to query the package, like this:

rpm -ql eclipse-cdt

Which will give you a list of the full path to every file that was installed onto your computer for the package in question (I’ve used eclipse-cdt, but obviously you can ask it about anything you’ve installed).

Handy!

The Biggest Programming Mistake I Ever Made

Well folks, as mentioned in How To Learn From Your Programming Mistakes, here it is.

The story that still makes me shudder when I think about it.

When it comes to all time, super-duper cock-ups, this is one I will never forget.

Strictly speaking I wasn’t actually trying to program anything when it happened. I was trying to…

Oh let’s just start from the beginning shall we?

The danger of embedded systems

Not long out of university, I was working on an embedded linux platform. The embedded OS, or target, was accessed via telnet from Linux desktop machines. At any one time your terminal window could be logged into your desktop, or into the embedded Linux platform (can you see where this is going?).

I was asked to help out a colleague who was having trouble getting his target up and running.

He pointed me to his machine in the lab, and then disappeared, leaving me to it.

Straight away I could see that the embedded board he was using was in a mess. Files were missing, some were corrupt, and it was basically unrecoverable.

I had several terminal windows open at the same time, and I was switching rapidly between them to check build version, firmware version, and to access my own machine remotely. I downloaded the latest build from my machine and logged into the target to reinstall it.

At least, I thought I did.

I typed:

rm -rf /

to delete everything, so I could start the install from scratch[1].

But as I pressed the return key, I realised I was using the terminal window for his desktop machine.

And I was logged in as root.

If I had to describe that moment using a movie scene, it would look like this[2]:

 

 

I cancelled the process immediately, but it was too late. I had totally destroyed his filesystem. Now he had no target and no desktop computer either.

What did I do?

After I’d finished reeling from the massive mistake I’d just made, I gathered myself together, went to find my poor victim and confessed.

And apologized.

A lot.

He very graciously took it in his stride (since there was bugger all he could do about it, I guess), and seemed happy enough once I promised I would immediately reinstall his operating system AND fix the target, as I had originally intended.

Now, to save face (and enhance my career prospects), I suppose I could have done the reinstall in secret, and feigned ignorance if he had asked where his local files had gone.

But I owned up, and it wasn’t as bad as I thought it would be.

And now I can laugh about it (just).

And of course, I have NEVER made the same mistake again.

 

[1] The command I used, for those of you that aren’t familiar with Linux, is the equivalent of selecting your hard drive and pressing the delete key.

[2] Jaws contains a classic example of the Dolly Zoom: that wonderfully abused effect where the background moves away while the actor appears to loom larger, usually accompanied by some tense string music.

 

GDB Core Dump Files

What’s a Core Dump?

It’s a file created when your program terminates abnormally. It contains a snapshot of the program’s state at the time of the failure.

What does it look like?

On Linux it will appear in the same location as the executable and will be named something like:

core.4196

Where the number is the process id of the program while it was running.

And what can I do with it?

You can have a look at it using GDB! GDB can read a core file to give you valuable information about a crash after the event.

Some Linux distributions have the ability to create core files disabled by default – you need to type:

ulimit -c unlimited

before running the program to allow the creation of the core file when the program terminates.

To examine a core file, just pass it to gdb:

gdb core.324

GDB will load up all the info and it will look as though you have just run the program and seen the error. You’ll be able to view a backtrace and a range of other information, but it will be a frozen “snapshot” of execution.

Instant debugging!