$ reboot
-bash: reboot: command not found
$ /sbin/reboot
reboot: must be superuser.

In KDE / GNOME, you can just click reboot in the menu and your session sends a message to display manager, which runs as root and does the dirty job of rebooting or shutting down your machine. Unfortunately, things are not that easy if you are using a simpler window manager or want to shutdown from a script. Sure, there is sudo, but that has to be configured first to work without password. Luckily, after a couple of hours of googling (only to find helpful advice as “this can be done easily with ConsoleKit or hal”), reading documentation of dbus, {Console,Policy}Kit and hal and clicking in qdbusviewer, I finally found a way with hal+dbus:

$ dbus-send --system --dest=org.freedesktop.Hal \
  --type=method_call --print-reply \
  /org/freedesktop/Hal/devices/computer \
  org.freedesktop.Hal.Device.SystemPowerManagement.Reboot

To shutdown, just replace Reboot with Shutdown. I’m going to add this to the default icewm configuration, so that the logout menu finally works.

During the last years of university I spent some time wondering about my future job. After the degree I received  lot of offers (fortunately also good ones), but none of them matched with my “dream job” . There was always something missing/different. I was just trying to convince myself that the “perfect job” can exist only in our dreams when my feed reader pointed me here.

After reading these lines:

” We are exploring new technologies, creating prototypes of future systems, and trying to find and shape some of the features that will be part of upcoming SUSE products and the ecosystem around that. It’s a fascinating job, challenging, fun, and always exciting. For somebody like me who loves to create new things and enjoys working with an awesome team of innovative people this is a dream job.”

I realized the description matched with all my wishes!

I immediately applied for the position and now, after more than a month, I’m looking at a signed proposal.

I’ve waited a long time before spreading my joy to the rest of the world… but now I just want to say that starting from 1st August I’ll be part of Suse’s Incubation team! :D

I’m really happy, excited and honoured for this awesome opportunity.

I wish you’ll be able to realize your dreams too!
Just a funny note… While Cornelius was writing about the job offer on his blog, I was having a dinner with another Novell employee: Massimiliano Mantione. I was listening to his personal story, wishing to find a dream job like his one. I have to admit I was a bit jealous :)

openSUSE is great for the desktop, great for the server, and now it’s ready to take on appliances — and we don’t mean toasters and blenders. No, we’re talking about software appliances — virtual machine images that come pre-configured with the application you want to use, without any of the hassle normally associated with installing an application.

If you’re interested in building a virtual appliance, or have another use for a minimal operating system, read on to learn about openSUSE LimeJeOS.

What is LimeJeOS?

LimeJeOS is the openSUSE version of JeOS. The term JeOS (“Just enough Operating System”) refers to a customized operating system that precisely fits the needs of a particular application. LimeJeOS includes only the pieces of an operating system required to support a particular application and any other third-party components contained in the appliance. This makes the appliance smaller, more efficient, more secure, and offers better performance than an application running under a full, general-purpose operating system.

As the name suggests, “LimeJeOS” itself is not an appliance or an operating system; it is just the base for various possible appliances. LimeJeOS contains just the very basic parts of an operating system. The major goal is to make the system as small as possible while providing the possibility to install additional software. A LimeJeOS system itself is not very useful without additional packages. Besides an editor (a stripped version of vi) it just contains a package manager that allows the actual applications to be installed. Of course all the usual repositories can be used for that purpose; just with a regular, full-size Linux distribution.

What is the difference between SLE JeOS and LimeJeOS?

SUSE Linux Enterprise JeOS relates to LimeJeOS just like openSUSE relates to SLES. In fact, SLE JeOS is built from the latest version of SLES while LimeJeOS is built from the latest version of openSUSE. While LimeJeOS provides the latest state of the openSUSE distribution, SLE JeOS will offer all the services and support that is also available for SLES.

Which one should you use? If you’re working on a virtual appliance for a project that won’t require commercial support, and you want to track the latest in open source, openSUSE is the version for you.

If you’re working on a project that’s likely to need support, then you probably want to go with SUSE Linux Enterprise JeOS.

Where can I get LimeJeOS?

LimeJeOS is built using kiwi. The configuration files are managed via Subversion and are available at: https://forgesvn1.novell.com/svn/opensuse/trunk/distribution/images/LimeJeOS/

In the future we plan to create a regular package (RPM) and add it to the openSUSE build service, so that the latest version is always created automatically with the latest software versions in openSuSE.

How to build LimeJeOS?

Check out the current version of LimeJeOS using the following commands:

svn co https://forgesvn1.novell.com/svn/opensuse/trunk/distribution/images/LimeJeOS

Make sure you have the needed kiwi packages installed. You will need at least: kiwi, kiwi-tools and kiwi-desc-vmxboot and/or kiwi-desc-xenboot from http://download.opensuse.org/repositories/openSUSE:/Tools/. When those conditions are met, building the openJeOS images is accomplished by just running the “./build.sh” script from the LimeJeOS repository.

./build.sh

Please note that the build process will need at least twice as much diskspace as the final images, so you’ll need around 2 GB of free disk space at this time to build Lime JeOS.

After you have booted the virtual system, log in as user “root” with password “linux”.

From May 30th to July 4th we had a YaST workshop in Nuremberg. The workshop was basically a hackshop as we wanted to work on cool and new things for YaST during this week.

There is one big change in YaST in openSUSE 11.0 – yea, we found out that there are even more colors than gray, ok – but there is one that is not really visible to the end-user. Stefan Hundhammer, maintainer our YaST UI, completely separated the UI from the rest of the YaST infrastructure. This now makes it possible to use the UI directly, from anywhere, independent from our YaST-own-language YCP. So with a team of four hackers we wanted to prove that we can write a YaST module in plain C++ using the new modularized UI directly. And here is the outcome:

We went for rewriting the registration module (well, we chose it because I know it well, as I am the maintainer, and it will change anyhow for the next release). This module is not that integrated in the overall YCP world, so it should be feasible. First we had to find an alternative way to access system configuration files, as this is done by so-called SCR agents in YCP. To make life easier (and future development faster) we had to look for a replacement of our YCP Wizard Seqencer. And of course we redesigned all dialogs to make them more intuitive.

We solved all the issues and now have

• a wrapper class for accessing different configuration files (currently only ini files)
• an automatic wizard sequencer equivalent (using the advantages of an object oriented language, btw YCP is not)
• three clear and intuitive dialogs, every user should understand

And as everybody wants to see screenshots, here they are:

The code is just a proof of concept and not yet reusable for new YaST modules but everything we wanted to show works great. We will continue to work on such kind of modules and in that process move the generic parts out into single libraries so that they can be reused and even may be exposed to scripting languages.

Writing YaST module this way has lots of advantages

• YaST modules evolved into the object oriented world and can make use of it (the automatic sequencer is the first benefit)
• the code is reusable
• a huge bunch of documentation and lots of tools exist for C++
• its a compiled language and has a better performance than an interpreted one
• we can bind automatically to the most important scripting languages and give them access to the modules logic

If you are interested in the source code, have a look at my svn repo and if you want to help join the team and contact us on our mailinglist.

openSUSE 11.0 failed detect this hardware and wrong identifying the device as AR242x 802.11abg Wireless PCI Express Adapter. I usually uses madwifi driver for Atheros chipset instead of ath5k but the standard madwifi driver could not be applied for the device. After Googling for a while, I could make it works with the special AR 5007 EG madwifi driver, http://snapshots.madwifi.org/special/madwifi-ng-r2756+ar5007.tar.gz.

How to make it works ?

1. Disable or blacklist ath5k driver by add the blacklist ath5k to /etc/modprobe.d/blacklist
2. Open konsole or terminal
3. Install the driver

su
zypper in kernel-source make gcc gcc-c++
wget -c http://snapshots.madwifi.org/special/madwifi-ng-r2756+ar5007.tar.gz
tar -zxvf madwifi-ng-r2756+ar5007.tar.gz
cd madwifi-ng-r2756+ar5007
make
make install
modprobe ath_pci
reboot


After reboot, you should be configure the wifi from YAST | Network Devices | Network Settings

What has my new haircut to do with David Beckham? Not much if you asked me. But yesterday I got this dubious compliment that I look like a tomboy with my new David Beckham cut. DAVID Beckham? Would have been strange enough to be compared with his starving wife, but with him..? To make things worse I had to dance to this duck song again. With a Bob the Builder helmet (the tomboy proof) and a troop of plush toys. And soon I have to paint fishes. And dolphins. Fishes for my nephew and dolphins for his best friend. My first contract work. I'm so proud. And so scared. I can't paint animals. Any animal. Not even amoebae.

Support for the RV770 chipsets has now been added to the GIT master
branch of xf86-video-radeonhd at freedesktop.org.
So far this support has only been available in the AtomBIOS branch.
Now some investigations have unveiled that the display engine blocks
have not changed since RV620/RV635. Therefore AtomBIOS is not a strikt
prerequisite to get the latest AMD/ATI hardware to work.
Some bits to get RV770 to work have been cherry picked from the
'atombios-support' branch. These involved mainly memory controller
register programming and some small fixes to the I2C code.
Thus it was possible to provide support for this new hardware generation
without having to wait for the AtomBIOS support branch to be ready for
merging into the master branch.
Some word on the atombios_support branch: Most of the work on that
branch has been finished so that this branch will be merged into
master after some further testing and once some cleanup has taken
place.
We have been asked to provide AtomBIOS support for the RadeonHD
driver to speed up the driver bring up for future generations of
graphics hardware. It relieves ATI of the burden to have register
specification available at the time of release of new graphics hardware
and thus allow it to focus on the publication of documentation for
3D programming.

One of the functional menu that make my life more easier with KDE 3 are the Compress and Extract Menu. With this function, I could make an archive or extract zip file with Konqueror without opening Ark for manually extract or compress the file. Now, I enjoy the KDE 4 on openSUSE 11.0, with Kwin desktop effect and a lot improvement in various area, but I still missing the above menu.

How to add the similar function to KDE 4 so we could compress some file or folder, or extract a zip file both in Dolphin and Konqueror ? Here is the tips :

1. Download the plugin here :
   http://www.kde-apps.org/content/download.php?content=84206&id=1&tan=96989998
2. Open konsole / terminal
3. Extract the plugin
4. Go to the extract folder
5. Copy all of .desktop file into /usr/share/kde4/services/ServiceMenus
6. Copy the content of script folder into /usr/bin
7. Test with dolphin or kde4

The above tips will make a system wide configuration. If you wish to make a local changes, just execute INSTALL_1.0.sh on the extract folder.

NOTE : The programs p7zip, bunzip2, bzip2, gzip, rar, unrar, tar, zip and unzip must be installed.

I don’t know if the function will be added into KDE 4.1 by default, but I hope so

A while back I posted about Mango Lassi and how awesome it was compared to synergy. I still think it is awesome, but every now and then something would freak it out and cause the association between machines to drop. I’ve fixed at least one cause of that problem now and published it in a git repo here: http://www.snorp.net/git/mango-lassi.git/

BTW, thanks for all of the great comments on the NAS situation. I’m looking at several of the options mentioned there along with a couple others. I think I’ve ruled out rolling my own, though, as I don’t want yet another linux box to maintain.