Translate

Archives

Image of Beginning Google Maps API 3
Image of Advanced Programming in the UNIX Environment, Second Edition (Addison-Wesley Professional Computing Series)
Image of Modern Operating Systems (3rd Edition)
Image of Android Wireless Application Development

UEFI Memory V E820 Memory

In this post I discuss the differences between how UEFI hands off memory to the Linux Kernel and how old-fashioned BIOSes handled off memory via E820.

Understanding Output From free Command

Consider the following simplified example of the output from the free command: # free -m total used free shared buffers cached Mem: 1000 900 100 0 350 350 -/+ buffers/cache: 200 800 In the above example, units are in Mb and the total physical memory is 1000 Mb. An inexperiencied system administrator might think that the system was running short of memory since the physically used memory is shown as 900 Mb. This is not the case. As far as applications are concerned the system is using only 200MB of memory and has 800MB free and available for use if

EFI Boot Stub Added to Linux 3.3 Kernel

The 3.3 Linux kernel added support for an EFI boot stub that allows an x86 bzImage to be loaded and executed directly by EFI firmware. The bzImage appears to the EFU firmware to be an EFI application. Both BIOS and EFI boot loaders can still load and run the same bzImage, thereby allowing a single kernel image to work with both BIOS and UEFI firmware. Here is the commit message: There is currently a large divide between kernel development and the development of EFI boot loaders. The idea behind this patch is to give the kernel developers full control over

Bash XOR A String

Here is an example of how to XOR a string variable using the Bash shell. Each character in the plaintext string is XOR’ed with decimal 90. #!/usr/local/bin/bash plaintext="abcdefg" echo "Plaintext: $plaintext" cyphertext="" for ((i=0; i < ${#plaintext}; i++ )) do ord=$(printf "%d" "’${plaintext:$i:1}") tmp=$(printf \$(printf ‘%03o’ $((ord ^ 90)) )) ciphertext="${ciphertext}${tmp}" done echo "Ciphertext: $ciphertext" # now XOR again and we should get the original string back plaintext="" for ((i=0; i < ${#ciphertext}; i++ )) do ord=$(printf "%d" "’${ciphertext:$i:1}") tmp=$(printf \$(printf ‘%03o’ $((ord ^ 90)) )) plaintext="${plaintext}${tmp}" done echo "Plaintext: $plaintext" The key lines are the ord= and the tmp=

Retrieving a Property using Python and GDbus

The documentation on retrieving or setting an D-Bus object’s properties using Python is pityful and mostly inaccurate. Recently GDBus has replaced dbus-glib as the preferred way to interface with D-Bus on GNOME platforms. The central concepts of D-Bus are modelled in a very similar way in dbus-glib and GDBus. Both have objects representing connections, proxies and method invocations. However there are some important differences: dbus-glib uses the D-Bus libdbus reference implementation, GDBus does not. Instead, it relies on GIO streams as transport layer, and has its own implementation for the the D-Bus connection setup and authentication. dbus-glib uses the GObject