Ext to the power of 4
YaST partitioner can now (since feature #305691 is implemented) do ext4 and in addition to that (to really stress-test the feature and have possible bugs reported asap), ext4 has been made a default filesystem for openSUSE 11.2. And though I'm not in the position to really appreciate and make use of all the cool ext4 features, I'm sure there is bunch of our users that will.
Now don't thank me, thank captain Arvin as it was him who did the work and added ext4 support to the partitioner (in one afternoon, so to say). And while you're at it, you can send him some beer :) :D
cat /usr/local/bin/osc
Until the Build Service supports git natively (see the GSoC project) , here is what I use to track my changes locally:
#cat /usr/local/bin/osc :
#!/bin/bash
/usr/bin/osc “$@”
if [ -e .osc/_files ]; then
if [ ! -d .git ] ; then git init ; echo “.osc” > .gitignore ; echo “.gitignore” >> .gitignore ; fi
mydate=$(date)git add `find -maxdepth 1 -type f | grep -v “.git”`
for i in $( git status | grep “deleted:” | cut -d” ” -f7 ) ; do
git rm $i;
donegit commit -a -m”$mydate”
fi
LiveCD Performance (clicfs vs. SquashFS)
When Coolo looked into how to get rid of (Another) UnionFS for Live CDs and came up with the DoenerFS (now clicfs) idea, I remembered that my friend Arnd has workded on fake write support for cramfs. So I took his code and ported it to SquashFS to see how that goes. My expectation was that it might be faster than Coolo’s clicfs using FUSE. Here are some results using openSUSE-KDE4-LiveCD-i586-i686-Build0098 booting into runlevel 3:
- clicfs: 637MB ISO Image booting in 1:28 min (0:24 min from RAM)
- squashfs-rw: 751M ISO Image booting in 1:50 min (0:28 min from RAM)
The difference in the sizes of the ISO images are due to the fact that clicfs is using LZMA compression while SquashFS is still using the in-kernel GZIP implementation. Surprisingly the clicfs image isn’t only smaller but is also faster booting on real media and from RAM (using KVM). So even if we ignore the fact that clicfs is optimized for limiting the number of seeks on disk the SquashFS implementation is still slower. It would be interesting to see if it is just the LZMA compression that is making the difference or something completely different.
The patches for the SquashFS fake write support are here: http://git.infradead.org/users/jblunck/linux-2.6.git?a=shortlog;h=refs/heads/squashfs-rw-v1.
openSUSE-GNOME BugDay: “Community Effort”
PSA sent to opensuse-gnome@opensuse.org, opensuse-project@opensuse.org, opensuse-announce@opensuse.org
Greetings!
Please join us for the openSUSE-GNOME BugDay code named “Community Effort” tomorrow
(Friday 14 MAY 2009) at 1100EDT/1500UTC.
We’ll be squashing blocker, critical, and major bugs in 11.1 related to GNOME.
More information can be found on the wiki:
http://en.opensuse.org/GNOME/BugDays/20090514
A Gobby session will be announced at the beginning of the meeting to assign/close
bugs. Should you have any questions, feel free to ask in #openSUSE-GNOME on Freenode,
or email me directly.
We hope to see you there!
—
Christopher M. Hobbs [chobbs@siloamsprings.com]
Network Administrator, City of Siloam Springs
Ruby on rails, Ajax and memory watching
As work on webinterface for YaST is in progress we must learn new technologies suitable for web development. WebYast will be written in ruby and ruby on rails framework. Also because WebYast is new interface it could contain AJAX features for better user comfort. Today I found that ajax support in RoR is on good level and with documentation it takes few minutes to create first example which show current used memory on server. It is not connected anyhow to YaST because I want to focus on AJAX.
And here is a code. It update page every fifth second (but not refresh only update div, on bigger page it is really significant):
/views/home/index.html.erb:
<%= javascript_include_tag :defaults %>
<h1>Hello world!</h1>
<%= periodically_call_remote(:url => { :action => 'get_averages' }, :update => 'avg',:frequency => '5') %>
<div id="avg">
Memory usage is X MB </div>
controllers/home_controller.rb:
class HomeController < ApplicationController
def index
end
def get_averages
output = `free -m` # bash solution - | sed 's/Mem:[^0-9]+[0-9]+[^0-9]+([0-9]+).*$/1/;2q;1d'`
output = $1 if (output =~ /.*n(.*)n.*n.*n/) #let live second line
output = $1 if (output =~ /.*:s+S+s+(S+)s+/) #second field
render :text => "Usage mem is "+output+"MB RAM."
end
end
And thats all to watch your server usage.
Join us translating the special edition !
Today, the openSUSE Weekly Newsletter team will have the translation sessions for the special edition created yesterday.
Join us from 12:00 UTC to 15:00 UTC in #opensuse-newsletter on freenode. (Schedule)
Cloning multiple git repos
For example I have clones of
Linus Torvalds's repo:
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Block Maintainer, Jens Axboe's repo:
git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git
...
If I do individual clones of all these repositories, it downloads and maintains duplicate copies of same objects wasting disk space, and network bandwidth.
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
git clone git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git
So I was looking for a way to share the common objects so that duplicate objects wont waste disk and network. And no surprise, git has a way to do that. Just that I was unaware of a simple option, "--reference".
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
git clone --reference linux-2.6/ git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git
Difference between cloning Jens' git with and without --reference to Linus's git.
# git clone git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git
Initialized empty Git repository in /home/knikanth/labs-sw/linus/linux-2.6-block/.git/
remote: Counting objects: 1180249, done.
remote: Compressing objects: 100% (295444/295444), done.
remote: Total 1180249 (delta 984716), reused 1073684 (delta 878311)
Receiving objects: 100% (1180249/1180249), 289.32 MiB | 496 KiB/s, done.
Resolving deltas: 100% (984716/984716), done.
Checking out files: 100% (27842/27842), done.
# du -sh linux-2.6-block/
714M linux-2.6-block/
# git clone --reference linux-2.6/ git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git
Initialized empty Git repository in /home/knikanth/labs-sw/linus/linux-2.6-block/.git/
remote: Counting objects: 111061, done.
remote: Compressing objects: 100% (19021/19021), done.
remote: Total 100463 (delta 84138), reused 95679 (delta 79959)
Receiving objects: 100% (100463/100463), 23.21 MiB | 1209 KiB/s, done.
Resolving deltas: 100% (84138/84138), completed with 8189 local objects.
Checking out files: 100% (27842/27842), done.
# du -sh linux-2.6-block/
468M linux-2.6-block/
--reference automatically sets up .git/objects/info/alternates to obtain objects from the reference repository. Now I wonder whether it is possible to have circular references, multiple references, etc.. The plural file name, "alternates" suggests it should be possible, but "git clone" ignores multiple --reference on the command line!
BTW git uses SHA-1 digests to identify objects. I wonder what is the chance of a SHA-1 collision and how git handles it? The SHA-1 digest has 40 Hex-digits == 160 bits.. So at most, only 2160 objects are possible. :-)
Power Management in openSUSE and SLE11
Power Management in openSUSE and SLE11
Wanna know what we're doing to make your laptop run longer? Have a look at the new wiki page I have just finished. It talks about three major topics:
- What is done
- What can be done better
- What is not done
It might give you some hints to tease even more out of your battery runtime.
Discussion welcome!
Kolab on its way back
After a long time, with lots of not visible activity Kolab, the groupware server build with many known open source components, is slowly getting back into openSUSE. For a year or so it was not possible to use Kolab on openSUSE versions newer than 10.3. That was due to the move from openldap 2.3 to 2.4. The latter does no longer support slurpd as replication mechanism, but uses syncrepl instead. Hence, kolab had to be extended to be able to work with new replication protocol. After that the way the webclient horde was packaged, changed from (to make a long story short) 1 big package, to many small packages. This in preparation for horde4. Today, the following message was posted to the kolab-user e-maillist:
after a lot of tests on a virtual system I finally upgraded my
productive Kolab server to 2.2.1 with the Suse packages.
Now you should now, that kolab-2.2.1 was released about month in April 2009. Although we (Marcus Huewe, Alar Sing, and the author of this article) are not there yet, seeing this message means a lot to us. We’re making good process!
