Because modifying an initial ramdisk is something I had to do every once a while and I am pretty oblivious when it comes to “exotic” commands, I will persist the knowledge at this point.

First of all, modern linux kernels (like everything above 2.6 or so) use an initrd that is a gzipped cpio-image (use file to be sure).

Extract an initial ramdisk

1. Extract (i.e. gunzip) the gzipped image

   1 2	~ $ mv initrd initrd.gz ~ $ gunzip initrd.gz

2. Extract the contents of the cpio image

   1 2	~ $ mkdir extracted && cd extracted ~/extracted $ cpio -id < ../initrd

(Re-)build an initial ramdisk

1. Create the cpio image

   1	~/extracted $ find . | cpio -H newc -o > ../initrd.new.cpio

2. Compress (i.e. gzip) the image

   1 2 3

   ~/extracted $ cd .. ~ $ gzip initrd.new.cpio ~ $ mv initrd.new.cpio.gz /boot/initrd-2.6.22-some-kernel

It might be possible to simplify some steps of this howto, but I tend to clarify things to avoid confusion.

Note:
I stumbled over the newc format of cpio. Actually, I think that there’s not pretty much of a choice here.
The documentation doesn’t say much about that, just use it.

Have fun, take care!

if you might ever need something like ldd on windows to figure out the dependencies on dynamic libraries of some binary, the following link could interest you:

http://www.dependencywalker.com/

no, it’s not a dream, you can haz root on MacOS, too. First, out of security reasons, I recommend to use sudo to do all the nasty stuff on the console. If that ain’t enough, the root users needs to be enabled first. As on most modern Linux distributions, you can enable the root user by assigning a root password (works on Ubuntu et al.):

1

$ sudo passwd root

The second – more mac oriented – way is the following:

1. Go to System Preferences and then select Accounts
2. Click on the lock and authenticate with an administrator account.
3. Click Login Options….
4. Click the “Edit…” or “Join…” button at the bottom right.
5. Click the “Open Directory Utility…” button.
6. Click on the lock and authenticate with an administrator account.
7. Choose Enable Root User from the Edit menu.
8. Enter the root password you wish to use in both the Password and Verify fields, then click OK.

The steps to disable the root user afterwards are nearly the same, so I won’t repeat myself.

The second way was taken from here

recently I copied some files from one mac to another via network. At first, the access rights on the remote computer were messed up somehow. The nobody user had its finger in the pie. Finally, I’ve made it to copy the files. Now that the files were on my disk, they were still locked and the permissions were still messed up somehow. So, as a Linux guy, I just tried to chown the files, but this leads to an operation not permitted, although I was running chown in sudo mode. After some research I found out that the files were locked, which couldn’t be changed via the finder app. Fortunately, this can also be changed via CLI:

1

$ sudo chflags -R nouchg /path/to/files

Happy unlocking!

I’ve been stumbling on this so many times, so I decided to dedicate this post to the following issue:
If you connect an USB device to your computer, trying to access it under Linux, you might run into permission issues caused by the UDEV daemon.

In my case, I was trying to connect an Android smartphone in order to work with it.
However, somehow, I had no permissions to access it, due to UDEV.

Here’s how to fix such a problem:

1. Determine the vendor-id and the product-id of your device using lsusb:

   1 2 3 4 5 6 7

   Bus 002 Device 009: ID 0bb4:0c97 High Tech Computer Corp. Bus 002 Device 004: ID 04b3:310c IBM Corp. Wheel Mouse Bus 002 Device 003: ID 046d:c318 Logitech, Inc. Illuminated Keyboard Bus 002 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

2. Create a new udev rule for this device, i.e., create a file /etc/udev/rules.d/51-mydevice (for instance), with the following contents:

   1	SUBSYSTEMS=="usb", ATTRS{idVendor}=="0bb4", ATTRS{idProduct} =="41db", 2 MODE="0666", OWNER="%username%"

I’ve got another neat little feature of emacs for you today, it’s called quoted insert.
I stumbled on this, because I use spaces for code indentation in my emacs, but I needed to insert an actual TAB character.
So, in this situation, the combination C-q <TAB> is the way to go, which interprets the next typed character in a quoted fashion.

Also, refer to this link for further reading.

daddy’s got a brand new toy to play with. I’ve bought myself a macBook pro and this piece of pleasure impresses me again day after day. I’ve just discovered that one can sync the addressbook app with their google account.

Here you go:

1. Edit the file ~/Library/Preferences/com.apple.iPod.plist

   1	{ Devices = { red-herring = { 'Family ID' = 10001; }; }; }

   If the file is not present, then create it. If the file is present and too heavy to read, use some property browser.

2. Now, open up Mac addressbook and go to preferences. There, the “Sync with google” option should now be available on the “accounts” tab. Activate it and enter your Google credentials.
3. An actual sync can be triggered with the following command:

   1	$ /System/Library/PrivateFrameworks/GoogleContactSync.framework/Versions/A/Resources/gconsync --sync com.google.ContactSync

   I don’t know, if this only has to be done initially or anytime a sync is wanted… TBD.

I’ve just discovered another neat feature of gdb: command.
I was in a situation where I needed to watch a certain variable on each breakpoint hit.
Generally, this is pretty easy in gdb using its watch-feature. Unfortunately, the variable under consideration was a QString.
Now, we already have some experience with those little brothers. If we only would have a way to call functions on each breakpoint hit…

… and here it is: command:
Once you have a breakpoint, you can assign a command to it, which will be executed each time the breakpoint is hit. For example:

1
2
3
4
5
6
7
8
9

(gdb) b main
Breakpoint 1 at 0x804db90: file main.cpp, line 11.
(gdb) command 1
>p argc
>end
(gdb) r
[Thread debugging using libthread_db enabled]
Breakpoint 1, main (argc=1, argv=0xbffff184) at main.cpp:11
$1 = 1

In the example above, the command p argc is assigned to breakpoint #1, which will simply print the number of arguments. If a QString variable is considered, one would’ve to replace the p with some gdb macro that is able to print a QString. If no breakpoint number is given, gdb uses the number of the last created one. To tell gdb to leave the command mode, just type end

as we all know, Emacs has a very powerful (graphical) interface to our beloved debugger GDB. Until five minutes ago, I used to start a program in debug mode by first starting emacs and then invoking M-x gdb, which can take a long time to navigate to the desired binary. Furthermore, the directory where the binary resides isn’t the actual runtime-path in many cases. Fortunately, Emacs can be started in GDB-mode directly, by calling it with the --eval parameter on the command-line. What we want to evaluate during startup is the (gdb) function. Its only parameter is a string describing how gdb should be invoked. Thus, we can write the following bash function:

debug () {
    emacs --eval "(gdb \"gdb --annotate=3 --cd=`pwd` $*\")" &
}

Here, the --annotate option tells gdb to generate annotations that can be interpreted by the Emacs gdb interface (the integer argument is the annotation-level). Furthermore, the --cd parameter instructs gdb to change its working dir to the specified one, which is the current working dir in our case. Thus we can call debug ./bin/prog, for instance.