Home Home > 2012 > 07
Sign up | Login

Deprecation notice: openSUSE Lizards user blog platform is deprecated, and will remain read only for the time being. Learn more...

Archive for July, 2012

Optimizing a boot time, aka 2 second boot (part 2)

July 31st, 2012 by

Changes for upcoming openSUSE

As a result of my previous 2 second post I have submitted few changes to openSUSE to be included in a next release.

  1. purge-kernels.service patch has been accepted by our brave mkinitrd package maintainer
  2. requested a split of mkinitrd setup script from splashy package, so users can freely remove the initrd integration without breaking resume et al
  3. I opened feature 313851 to make NM the default network tool at least for laptops, because this expects a little more changes than add a package to laptop pattern

Run NetworkManager on demand

That is very uncommon user-case for *nix machines, but makes a perfect sense for consumer devices. My Amazon Kindle or today’s smartphone or tables works in the same way – device starts without a network connection and there’s a button or magic tap enabling it. On my laptop I already have such button – it is the Fn+F2 with a antenna symbol printed. This is the rfkill button turns my wlan card on and off.

So what I want is once I turn wifi on, NetworkManager should start and work. With systemd and it’s udev integration this is so simple, that I was not able to find a good howto for it. So here we are with a small howto for udev/systemd newbiew like me.

We need to know a sysfs name of wlan0 – simple find /sys/ -name 'wlan0' will say us all we need. Then udevadm info will tell you more

udevadm info --path=/sys/class/net/wlan0 --attribute-walk | less
  looking at device '/devices/pci0000:00/0000:00:1c.2/0000:01:00.0/net/wlan0':

That is all you need to know how to write a rule will match for all wlan cards.

# cat /etc/udev/rules.d/95-start-nm-on-wlan.rules
SUBSYSTEM=="net", NAME=="wlan?", TAG+="systemd", ACTION=="add", ENV{SYSTEMD_WANTS}="NetworkManager.service"

To explain it – SUBSYSTEM and NAME are taken from previous output and means that following rule matches for all devices in net subsystem named wlan-something. We should append tag systemd, because systemd sees tagged devices only. The ACTION=="add" says the rule will be evaluated only in case device will be added and the last part says to systemd which service should be started.

In case you will want to stop NM, the

SUBSYSTEM=="net", NAME=="wlan?", TAG+="systemd", ACTION=="remove", ENV{SYSTEMD_WANTS}="NetworkManager-stop.service"
# cat /etc/systemd/system/NetworkManager-stop.service
Description=Stops NetworkManager


WLAN cards

For onboard wlan cards following thing won’t work as they appear in a tree from early phase. Unfortunately I’ve found only one way how kernel exports the fact cable is plugged in and that’s changed /sys/class/net/eth0/carrier. But inotify does not work with a quantum-like fs like sysfs is. The trouble is values appears in time of read, but inotify react on writes, which never appear.

How much the removal of getting IP address from boot saved the time?

# systemd-analyze
Startup finished in 2719ms (kernel) + 4333ms (userspace) = 7052ms

which is about half of second.

Too much mounts in a parallel

The one thing surprised me was a long time until trivial mounts like debugfs were finished. The reason is that systemd (at least 44, recent version use generator+ .mount units) behaves differently to .mount units and things in /etc/fstab. In the first case, it executes the /bin/mount. Which means a lot of ld, stats, mmap, and the big delay of the system start.

So move things to fstab, or disable the systemd mount unit (I did that for sys-kernel-debug.mount and sys-kernel-security.mount). I already masked the remount-rootfs.mount, which calls /bin/mount -o remount /< only. That seems to me like a barrier for other mount units – iow this will be done as a last one. But who cares with a fast boot we have?

Way more changes

Then the systemd-modules-load.service delay a boot as it block sysinit.service, when basic boot ends. I read strace carefully, but it only load microcode_ctl module, but that took few seconds to be done. Thus I gently masked it.

The next change is backport from Factory package – this reduce the delay caused by all those tty devices to appear. Fortunately this will be part of next openSUSE as it is an upstream patch.

And as a last thing I wrote a simple xdm.service, instead of a big xdm init script. It will definitely need more love, but for me just works 🙂

cat /etc/systemd/system/xdm.service
Description=X Display Manager

ExecStart=/usr/bin/xdm -nodaemon


VoilĂ !

Startup finished in 2698ms (kernel) + 1513ms (userspace) = 4212ms

Using dracut

Because our brave systemd maintainer, FrĂ©deric Crozat, chooses dracut as his hackweek project, I was curious if dracut can make some gain for me. I installed dracut and rebuilt and installed hardlink from his branches and try to investigate it. I would say the biggest advantage over mkinitrd is that dracut is configurable from command line. This is in a contrast with mkinitrd, where you have mostly no way how to exclude something – at least I did not find anything.

As Fréderic also pointed me, there is a --hostonly switch, which include only things needed for boot of current machine only. For instance dracut module kernel-modules will pull only things needed to mount rootfs (and if usrmount is included, then it will add things for /usr as well). Then I have excluded at least everything I can to have a working initramfs via -o, --nofsck and --strip. And that is the resulting time

# systemd-analyze
Startup finished in 726ms (kernel) + 1609ms (initramfs) + 1581ms (userspace) = 3917ms

openSUSE 12.2 boot with initramfs made by dracut

Disabling way more things

As we are now versed in a looking at diagrams, there are still few ms we can save, even those changes are not sane ;-). The first one follows the NetworkManager.service – now sshd.service delays the boot a lot, because it systemd-update-utmp-level.service waits on it’s finish. So let’s start it on demand

# cat /etc/udev/rules.d/95-start-nm-on-wlan.rules
SUBSYSTEM=="net", NAME=="wlan?", TAG+="systemd", ACTION=="add", ENV{SYSTEMD_WANTS}="NetworkManager.service sshd.service"

and disable it. Then mask all few remaining things – systemd-login.service, systemd-remount-api-vfs.service, systemd-user-session.service and rc-local.service. But only in case you are pretty sure what you are doing, because you might loose an important functionality, especially if you use a DE expected such things.

And that is the last time I will post

# systemd-analyze 
Startup finished in 726ms (kernel) + 1502ms (initramfs) + 1112ms (userspace) = 3341ms

With a kernel with SATA+ext support builtin, I would reach the two second goal – 1839ms. Of course on a system, which functionality was extremely cut down, but my goal was to boot as fast as possible. In reality, hunting of ms does not makes your feeling better a lot (until you will type systemd-analyze, of course)

This is the diagram of the really fast boot

openSUSE 12.2 close to two second boot as possible

AMD/ATI Catalyst fglrx & fglrx legacy news

July 31st, 2012 by

AMD/ATI Catalyst fglrx & fglrx legacy news

Explanations of Hell

During June, with the version 12.6 (8.980) AMD decide to drop support for legacy radeon chipset from its main fglrx package and drop the time based release cycle.
So now if you are the owner of radeon hd2xxx to hd4xxx chipset family you will have to use the -legacy- version of fglrx, and
consequently if you have a radeon hd5xxx or above, you have to use the standard fglrx driver.
Then start the hell. After getting the new developed script from Sebastian Siebert, I will be able to offer the two versions. Unfortunately the two drivers can’t coexist in the same repository, the legacy drivers wants to install in place of normal one. This imply another limitation, you can’t have two graphics cards with differents generation at the same time.
So I decide to clarify (is that possible? :-)) the mess, and split the drivers in two distinct repositories. I use that excuse to also change the ati (deprecated brand name) and use new names: amd-fglx and amd-fglrx-legacy.
Don’t worry about your exiting installation, I will provide a symlink during the next 6 months at least for the old repositories. But read carefully the rest of the story, and apply any changes needed to your installation to be sure to continue to safely use the right driver.
I also decided to remove any version below 12.4 (8.961) in all repositories, except for openSUSE 11.2.

I need your help to spread those informations around the internet, and be sure that every user that need this driver know where and how to use it right. Tweet FbLike G+ forums, mailing list, private blogs Go now!

Release note about 12.6 and legacy 8.97.100

Both version can handle kernel 3.4 and 3.5

Sebastian Siebert warn us about the state of legacy

AMD catalyst control center and fgl_glxgears

These cards with the unofficial support of openSUSE 12.2 can run in the ideal case, just under 2 more years. However, one must keep in mind that the legacy driver is looked after, while AMD continues and eliminates errors found, but will not add new features. This can mean, among other things, that the next version of GNOME or KDE will not run with its 3D effects, especially when used with a desktop or Tumbleweed extra repository.

Sebastian’s post

If you have any comments, be do on his blog. Don’t be shy, you can leave there the result of test in english too 😀
or ask in forums, irc and ping freespacer.
See below what to do in case of troubles.

12.2 Factory rpms are presently available, use at your own risk, and report bugs in forums and Sebastian blogs.
Anyways, factory and 12.2 should keep their effort on debuging and testing widely the free radeon driver.


[gsoc] osc2 client – summary of week 10

July 30th, 2012 by


here’s a small summary of the 10th (coding) week. Last week I worked
mostly on the new fetcher code which I finally pushed into the git
repo. Apart from this I did some refactoring here and there.
The todo for this and the next week is to start with the new osc
user interface (that is the client code). As I already wrote in the
proposal the new osc client will be based on python’s argparse module
and the Jinja2 template engine.


Optimizing a boot time, aka 2 second boot

July 26th, 2012 by

During the hackweek, I have decided to take a look onto a boot process to realize, how fast can be boot of the system. This metric is considered as a not important, especially in a geek community. But I am sure that this is an important part of user experience. Following text is mean to share my investigations with you – but you should be aware what you are doing, since I have been focused on reducing the boot time as much as possible.

A bit of theory

Basically you have three possibilities how to make your boot fast.

  1. Start things in a parallel.
  2. Start things on demand.
  3. Start less things.

… root of all evil …

“Premature optimization is the root of all evil.”

And I will modestly extend Donald Knuth’s sentence, that the blind optimization as well. So if we have to optimize something, we have to know what to do. Fortunately systemd comes with an excellent tool called systemd-analyze, which show us our boot in several ways.

The simple run of command prints the time we spent in a boot and in which phase.

# systemd-analyze
Startup finished in 8480ms (kernel) + 30873ms (userspace) = 39353ms

That was the default (minimal X system) 12.2 installation on my EEE 701 netbook, which is probably not suitable to work as nowadays cellsmarphone, because is pathetically slow. On the other hand is it a perfect playground, so let’s continue with an investigating.

The overall time is nice, but won’t help to know what’s going on. There are two more subcommands, blame and plot shows us more information about the boot. The first shows the services sorted by the start time. The ones boots so long are those we should kicked off as a first ones.

Let see what slow the boot down a most

$ systemd-analyze blame | head
 11385ms network.service
  5664ms SuSEfirewall2_init.service
  5575ms systemd-vconsole-setup.service
  3032ms ntp.service
  2840ms remount-rootfs.service
  2230ms postfix.service
  2021ms network-remotefs.service
  1925ms cpufreq.service
  1661ms SuSEfirewall2_setup.service
  1506ms xdm.service

And take look at the output of systemd-analyze plot command

openSUSE 12.2 boot diagram

You can see, that there is a long chain of SuSEfirewall2_init -> network -> network-remotefs -> SuSEfirewall2_setup tooks several dozen seconds to be finished. And nothing is wrong with that, but that is the server solution, not what I want to have on my tiny laptop.

Making a laptop boot twice more faster

So having the complex dependencies of several services in mind, I decided to mask some of them. Masking in systemd world means the service cannot be started using systemd, so it becomes invisible for it. I masked those

  • network.service – will be replaced by NetworkManager, which is more suitable for laptops usage
  • SuSEfirewall2_init and SuSEfirewall2_setup – even if it’s a security feature, a risc for laptop, which is mostly offline and running only sshd is pretty small.
  • ntp.service, network-remotefs.service – those does not makes a sense on my laptop
  • postfix.service – I do not want to send emails via /usr/bin/sendmail
  • cpufreq.service – it is even not supported by my CPU (grep rc.cpufreq /var/log/messages)

Do not forget to install NetworkManager and the applet and change the /etc/sysconfig/network/config and reboot.

Now we have

$ systemd-analyze
Startup finished in 8528ms (kernel) + 11123ms (userspace) = 19652ms

Using an strace with systemd

Now we have a list of worse services

$ systemd-analyze blame | head -n 10
  5476ms xdm.service
  4172ms systemd-vconsole-setup.service
  3950ms systemd-modules-load.service
  2781ms remount-rootfs.service
  1848ms NetworkManager.service
  1439ms media.mount
  1426ms systemd-remount-api-vfs.service
  1419ms dev-hugepages.mount
  1411ms dev-mqueue.mount
  1371ms sys-kernel-debug.mount

and a proper boot chart

bootchart w/o network.service

It shows us an another botleneck, which is the systemd-vconsole-setup.service, because it delay the sysinit.target, which is very early boot stage. In case like this, we can only use strace to know, what is taking too long. And debugging is pretty straightforward in systemd world. All we have to do is copy service file to /etc/systemd/system and change the ExecStart

ExecStart=/usr/bin/strace -f -tt -o /run/%N.strace /lib/systemd/systemd-vconsole-setup

and reboot. Then you will find the output in /run/systemd-vconsole-setup.strace with a timestamps. Looking there it’s obvious calling hwinfo --bios is extremely expensive in this stage. You can speedup the unit by setting the KBD_NUMLOCK to yes or no in /etc/sysconfig/keyboard, or you can try to mask it completely I did.

The next service needs to closer look was system-modules-load – then strace says that it spent 2(!) in init_module() for module microcode. I disabled it as well, even for CPUs needs it can’t be recommended.

Native systemd units

There is one tiny init script called purge-kernels, which starts for 300ms according blame. And in this particular case systemd alternative will be way more effective

$ cat /etc/systemd/system/purge-kernels.service
Description=Purge old kernels


because systemd only do one stat on the file and do not run it at all, so this service disappears from the blame at all.

The kernel time

There is one interesting thing about kernel time – 8 seconds spent there seems to be a lot to me. Simple ls on /boot gave me a pointer

$ ls -lh /boot/vmlinuz-* /boot/initrd-*
-rw-r--r-- 1 root root  14M Jul 24 11:03 /boot/initrd-3.4.4-1.1-desktop
-rw-r--r-- 1 root root 4.7M Jul 10 15:48 /boot/vmlinuz-3.4.4-1.1-desktop

The initrd is huge, around three times bigger than kernel? So let’s try to find what caused that. Every package can add it’s own setup script into /lib/mkinitrd/scripts/ thus let ask rpm whose did that

$ rpm -qf /lib/mkinitrd/scripts/setup-* | sort -u

So I went through a list and try to uninstall things I do not need

  • cifs-utils – if you do not have any windows disc to mount, you can remove, but no impact on initrd size
  • cryptsetup – this is a popular service for laptops, but I do not have any luks device, so let skip that. It removes a half of Yast as well, so I saved 18M of space, but a little in initrd.
  • device-mapper, dmraid, kpartx and lvm2 – cannot be easily removed as too much low-level stuff depends on it
  • mdadm – no linux md devides, skip that
  • mkinitrd – removal can reduce initrd to zero, but we would need own kernel
  • multipath-tools – no multipath device, let skip that

  • plymouth-scripts – who would need the “fancy” boot when booting so fast? – reducing initrd to 8.9M
  • splashy – the same – and reducing initrd to 6.6M

So the things intended to provide fancy boot actually bloats the system. Let’s measure the impact of those changes

$ systemd-analyze
2781ms (kernel) + 4999ms (userspace) = 7780ms

bootchart w/o network.service

And that’s all folks …?

There are a lot of factors slowing our boot – reducing it to 8 seconds is not that bad. One have to go carefully through blame and plot output to see what delays his computer in start. I would say making NetworkManager default one at least when installing laptop pattern would be nice and simple change as well as continue on “systemdifization” of openSUSE.

There are few other tricks, which get us closer to the target time, but I’ll post them next day.

Snapper and LVM thin-provisioned Snapshots

July 25th, 2012 by

SUSEs Hackweek 8 allowed me to implement support for LVM thin-provisioned snapshots in snapper. Since thin-provisioned snapshots themself are new I will shortly show their usage.

Unfortunately openSUSE 12.2 RC1 does not include LVM tools with thin-provisioning so you have to compile them on your own. First install the thin-provisioning-tools. Then install LVM with thin-provisioning enabled (configure option –with-thin=internal).

To setup LVM we first have to create a volume group either using the LVM tools or YaST. I assume it’s named test. Then we create a storage pool with 3GB space.

  # modprobe dm-thin-pool
  # lvcreate --thin test/pool --size 3G

Now we can create a thin-provisioned logical volume named thin with a size of 5GB. The size can be larger than the pool since data is only allocated from the pool when needed.

  # lvcreate --thin test/pool --virtualsize 5G --name thin

  # mkfs.ext4 /dev/test/thin
  # mkdir /thin
  # mount /dev/test/thin /thin

Finally we can create a snapshot from the logical volume.

  # lvcreate --snapshot --name thin-snap1 /dev/test/thin

  # mkdir /thin-snapshot
  # mount /dev/test/thin-snap1 /thin-snapshot

Space for the snapshot is also allocated from the pool when needed. The command lvs gives an overview of the allocated space.

  # lvs
  LV         VG   Attr     LSize Pool Origin Data%  Move Log Copy%  Convert
  pool       test twi-a-tz 3.00g               4.24
  thin       test Vwi-aotz 5.00g pool          2.54
  thin-snap1 test Vwi-a-tz 5.00g pool thin     2.54

After installing snapper version 0.0.12 or later we can create a config for the logical volume thin.

  # snapper -c thin create-config --fstype="lvm(ext4)" /thin

As a simple test we can create a new file and see that snapper detects its creation.

  # snapper -c thin create --command "touch /thin/lenny"

  # snapper -c thin list
  Type   | # | Pre # | Date                          | Cleanup | Description | Userdata
  single | 0 |       |                               |         | current     |
  pre    | 1 |       | Tue 24 Jul 2012 15:49:51 CEST |         |             |
  post   | 2 | 1     | Tue 24 Jul 2012 15:49:51 CEST |         |             |

  # snapper -c thin status 1..2
  +... /thin/lenny

So now you can use snapper even if you don’t trust btrfs. Feedback is welcomed.

[gsoc] osc2 client – summary of week 9

July 23rd, 2012 by


here’s a small summary of the 9th (coding) week. Last week I worked
on the fetcher and cache manager code. In order to support all
features some of the existing classes had to be enhanced with some
more parameters.


  • cache manager code
  • BinaryList class supports view=cpio
  • RORemoteFile class supports lazy_open
    parameter (by default the file is opened lazily that is when a
    read request is issued) (for the fetcher code we use
  • minor changes in the httprequest module (AbstractHTTPRequest
    supports the same query parameter more than once)
  • The fetcher code is more or less done (not yet committed) and will be
    finished by friday evening (I’ve some exams this week…).


We can do better

July 20th, 2012 by

Maybe it is just me, but lately it appears that there is a lot brewing on our lists. Generally I try to stay out of the fray, but of course we, as members of our community, are all in the middle of it in one way or another. With a very recent endless thread on the opensuse list fresh in memory, not that I read all or even most of the messages it generated, and the follow on thread of the original poster bidding his farewell to the list, supposedly because the poster didn’t like the responses, I feel compelled to share some of my own thoughts on the topic.

My feeling is that a good number of people that complain about the noise on our lists are also those that contribute to that noise at a good rate. Thus, I can only say that sometimes it is nice to exercise some restraint and not hit that “Send” button; who hasn’t had the “I shouldn’t have sent this” thought? The bottom line is, that it is almost impossible to write anything that does not step on somebody’s toes somewhere along the way and if everyone that feels the least bit uneasy about some comment would respond all the time we would really be in an endless loop. I am certain, this post will make someone uneasy, upset, angry or worse. If that’s the way you feel right now, I am sorry, I am not trying to make you angry or upset on purpose. Please accept my apology.

That said, who hasn’t been frustrated out of their mind by some perceived dumb software problem or other issue? Even worse when it is our own hurdle we cannot cross. In the end we just wanted to yell and scream and the result is too often a message with: pick your “Emotional state appropriate inflamatory subject…” and rant your question to the list. Everyone gets emotional, and frustration happens to be a very strong reaction. However, the question that should come to mind before hitting that “Send” button to a list of volunteers is this, “Will an emotional reaction with moaning, groaning, whining, and complaining, that hides the real problem, give me the feedback needed to resolve my issue?” The answer is simple; No it will not. A post charged with negative energy will, and there is plenty of proof on our lists, solicit emotional, mostly negative, responses. These do not contribute to resolving the problem at hand. However, once this storm is set in motion there is, for better or worse no stopping it and it just has to run its course, i.e. eventually people will be tired of feeding the storm that should have never happened and things will go back to “normal”, whatever that may be.

I believe that the people, volunteers, on the opensuse mailing lists are generally willing to help solve problems others encounter. Yes, there will be the occasional cynical remark here and there, but I do not believe these remarks are ushered in a mean spirited way, and in the end we do not really have to nit-pick everything to death. It is one thing to yell at someone because the product or service you purchased from them does not meet your expectations, it is another thing to go bananas on a list where answers are provided by people with generally good intentions that volunteer their time. As posters of questions we all have a responsibility to keep this in mind before we go down the emotionally charged road to the abyss of not getting our questions answered.

However, putting the onus completely on the question poster is a bit too easy, isn’t it. While we as helpers would all love to get the “perfect” problem description, that is completely factual and contains no mistakes in description and actions to reproduce the problem, we have to realize that this is just not going to happen. By the time an issue hits the list the person posting probably is charged up in one way or another and ready to get rid of some of that stored energy, some more than others. Thus, as helpers we have to develop a bit more tolerance and let things roll off our backs a bit more. As potential helper we can just ignore the ranting posters. If you have it within you to provide the answer to the hidden problem and can rise above the fray, fantastic! help and do a good deed. However, if you know the answer to the hidden problem but feel the urge to feed the emotional storm it may be best to just ignore the message and not respond. In the end a raging answer hides the kind deed of help just as the raging question hides the problem.

No we do not have to have boring and no fun lists, but in the end flame wars or endless bickering threads are not fun and having people leave the lists or even not using openSUSE because of silly things is just not helpful to anyone. If we as posters, seekers of answers and providers thereof can just tone it down a bit things will probably work better for everyone.

How to peek into remote isos

July 17th, 2012 by

When people want to provide a collection of files, they sometimes choose to do so by providing a .iso image file. But if you only want to look what files are in there or only need a few files, e.g. kernel and initrd for PXE-booting, you still had to download the whole thing to loop-mount it.

But you don’t have to anymore. Because modern web servers support delivering only parts of a file (using the “Range” header field), that allowed me to implement curlwwwfs that mounts remote HTTP directories into your local filesystem. And then you can use fuseiso on top to access the actual content within the .iso. All without root access.

This is how it works:

First you have to install the required packages (replace 12.2 with your version of openSUSE (or if you use a different Linux distribution, do git clone git://github.com/bmwiedemann/curlwwwfs and “make install” in there)):

zypper ar http://download.opensuse.org/repositories/home:/bmwiedemann/openSUSE_12.2/home:bmwiedemann.repo

zypper in curlwwwfs fuseiso

# Then you start it:

mkdir mnthttp mntiso

curlwwwfs http://zq1.de/bootcd mnthttp &

ls -la mnthttp/

fuseiso mnthttp/bmwinux-8.2-040808.iso mntiso

cat mntiso/isolinux/isolinux.cfg

# and later you clean it up with

fusermount -u mntiso

fusermount -u mnthttp

[gsoc] osc2 client – summary of week 8

July 16th, 2012 by


here’s a small summary of the 8th (coding) week. The last days I
was working on getting build support into the osc2 library. I just
checked in a BuildInfo and Builder class (+ testcases). Here’s a
brief example how they can be used:

# example how to use the Builder class
builder = Builder(su_cmd=Builder.SUDO, root='/var/tmp/build-root')
builder.rpmlist = '/path/to/rpmlist'
builder.dist = '/path/to/buildconfig'
builder.without = 'feature1'
builder.without += 'feature2'
builder.arch = 'x86_64'
# run the build:
# this executes:
sudo /usr/bin/build --arch x86_64 --dist /path/to/buildconfig \
   --root /var/tmp/build-root --rpmlist /path/to/rpmlist \
   --without feature1 --without feature2 /path/to/osc.spec

Basically Builder is just a wrapper around the build script
(all options will be passed to the build script; if an option contains
a “-” character like “vm-type” it can be set like this:
“binfo.vm_type = ‘xen'” (a “_” will be replaced with “-“)).

Additionally here’s a small example how to utilize the BuildInfo

# fname is a path to a spec file
binfo = BuildInfo('openSUSE:Tools', 'osc', 'openSUSE_Factory', 'x86_64',
# print preinstall packages
for bdep in binfo.preinstall():
    print bdep.get('name'), bdep.get('version')
# save binfo xml in a file

The next thing on my TODO is the fetcher and cachemanager code.


Linux Kernel built with clang boots into openSUSE

July 14th, 2012 by

Whatch this:  http://youtu.be/Jp04DMXH2Rg

The kernel was compiled with Clang (C frontend of LLVM)  and boots into a running openSUSE desktop!