Bedrock Linux - Momo (1.0alpha2) Unofficial Builds

Hello, if you don't know already, a new Linux distro named Bedrock has emerged. It brings a new concept to working with different distros at the same time.

Please visit the official website for more info.

First of all, I'll recommend you to go through the install instructions, as it will might earn you a good experience with managing such packages. It's the best and preferible way of getting a working Bedrock.

If you follow the install steps described there you might encounter with some difficulties compiling the packages. This mostly depends on your host's environment (gcc version, glibc version, etc... etc...).

PART 1: Unofficial Repository
The problem comes if you hit a compilation issue that you are not able to solve by yourself. In this case, we (a couple of volunteers) have created an unofficial repository. 

The repo's url is:

It includes:
  • Two supported architectures (for now): amd64 and x86
    • Static binaries (already compiled packages that are ready for use).
    • A couple of extra static binaries that might be useful for you (for example grub-static)
Reading the README file on how to use the packages is advised. With these, you should be able to get yourself a running Bedrock - just follow the install instructions and where you should compile/install the packages by yourself, just use the already compiled static binaries provided by the unofficial repo.

PART 2: rootfs and VirtualBox images.
As a try to make an even easier and faster way for users to be able to play with Bedrock's environment and functionality, I've tried to provide completely working solutions to the laziest people here ;).

What this contains: grub (0.97), 3.4 kernel (only ext4 support available), udev and a bunch of other useful tools provided by buildroot.

Unfortunately, currently only amd64 images are provided here:

  • BedrockLinux.vdi-VERSION.tar.xz - A VirtualBox .vdi image (used as a hard disk). Just create a VM and attach the this .vdi image as only hard disk (as SATA). 
  • rootfs-VERSION.tar.xz - It's a complete tree of files that you need to populate your Bedrock's partition.

Keep in mind that the two methods BedrockLinux.vdi-VERSION.tar.xz or rootfs-VERSION.tar.xz contain only a base Bedrock environment. You need to properly configure Bedrock and a Bedrock client to your liking.

The BedrockLinux+DISTRO-VERSION.vdi.tar.xz method is an already configured Bedrock base with an already configured client. You can use this as an example so you can configure more/others clients to your liking.

Bedrock boot process.

Here you can see a couple of chinese students trying out Bedrock following this blog post (no photoshop used, really! :-P).
Chinese students installing Bedrock Linux.


Kernel compile times: HDD vs. SSD vs. TMPFS

Hello, I've just done a 'benchmarking' on a kernel compilation, by compiling a kernel with the same .config on either HDD, SSD or TMPFS just to see the compiling times for my personal pleasure.

Some useful info:
CPU: i7-2600K OC @ 4.4GHz
Kernel version: 3.4.5
Command used: time make -j10

NOTE: To ensure equal conditions between each compilation I've used:
sync; echo 3 > /proc/sys/vm/drop_caches 

Here are the results:

Technical data
Model: Western Digital 500GB 64MB cache (WDC WD5000AZRX)
Bandwith: ~120MB/s read/write
Seek time: ~10-12msec

Compilation time
Kernel: arch/x86/boot/bzImage is ready  (#1)
real    2m13.178s
user    14m5.407s
sys     1m13.519s

Technical data
Model: OCZ Vertex 3 120GB 
Bandwith: ~480MB/s read, ~320MB/s write
Seek time: ~1msec (0.40-0.70msec)

Compilation time
Kernel: arch/x86/boot/bzImage is ready  (#1)
real    1m58.217s
user    13m3.937s
sys     1m2.879s

Technical data
Model: Kingston 1333MHz DDR3
Bandwith: ~18GB/s read, ~20GB/s write (actually useless data as tmpfs will never work at that speed)
Seek time: ~50nsec (0.00005msec)

Compilation time
Kernel: arch/x86/boot/bzImage is ready  (#1)
real    1m59.639s
user    13m15.891s
sys     1m3.722s

2m13s 1m58s 1m59s
14m5s 13m3s 13m15s
1m13s 1m2s 1m3s

This really is a little bit of a surprise, the compilation on an SSD disk performed better than the one on RAM. And generally the difference between all of them wasn't *so* big. On older CPUs this might not be the case and HDD perform a lot worse than SSD/TMPFS.

XChat/HexChat identify in Freenode (and other IRC networks)

Hello, if you're here that's because your XChat/HexChat doesn't wait enough for NickServ to identify you before joining all your favourite channels.

There are a couple of tricks to solve this, I'll post here just a few of them.

First way.
There is a variable with which you can control how many seconds you want your irc client to wait before it joins your favourite channels after connect. This is the irc_join_delay variable and you can change it with:
/set irc_join_delay
For example:
/set irc_join_delay 7
7 seconds is, in most cases, enough for the freenode services to ID you.

Second way.
This is the most prefered way among users. It doesn't need you to change the irc_join_delay variable because it identifies you upon connect and not after that. 

You can achieve that by setting your user:password (where user is your account nickname and password is your NickServ ID password) in the Server password: field of your freenode network options.

For example:
Like this:

Third way.
Using SASL. Have a look at:
Connecting with SASL (
Connecting to freenode using Tor: SASL (

Online Radio with Shoutcast Server and Winamp or S.A.M. Broadcaster or Virtual DJ

Just as the title says. Here's a very short sample video where you can see the base configuration to get your own online radio running in less than 5 min.