Novell, Microsoft ... and what think RedHat?

Today I read a article about a interview with Mark Webbink from RedHat. There is no denying that they feel inadequate:

... In the end, Red Hat's high customer satisfaction ratings will allow his company to ride the tide. In one year's time [...] Red Hat will be the only Linux commercial vendor left standing ...

I've rarely laughed so hard! We will see if this come true, next November and if SUSE, Ubuntu and e.g. Mandriva still standing ... or Oracle bought you. ;-)

Tags: Novell Microsoft RedHat Linux

KPowersave on the way to 0.7.0

Only some hours until deadline for openSUSE Beta2 and a new version of KPowersave, which no longer depends on the powersave daemon and use HAL instead.

In the last days I removed the complete powersave related code and replaced it with new classes and hardware abstraction. Today I finished the basic part and we have now a powersave independend version in SVN which runs. But this does not mean the new version work as planed ... there is enough work left.

Yesterday I added an pre-annoucement for the new 0.7.x development version at kde-apps.org planed for this week. And as you can see in the comments there are people which are not so happy about switch from powersave to HAL (as you can see in this post I'm not that happy too):

... going HAL is a real downer and ( at least to me ) it turns Kpowersave into just "another" solution, stripping it from what made it different ..

powersave was EXACTLY the way to go .. and to tell you the truth, knowing why Kpowersave is going HAL is what makes everything even worse. It makes me feel like mediocrity and disdain won once again.

And there is also this question in the comments here:

What are the benefits of changing from powersaved to HAL?

So, what are the reasons for change from powersave to HAL? As first: Since the powersave developer decided to kill the powersave daemon and integrate (the most of) the functions of the daemon into HAL and pm-utils, we have no choise. We have to use the new infrastructure or KPowersave die with the daemon. This was the main reason to rewrite KPowersave.

So what are the benefits?

• No dependency to the powersave daemon (the package is not in every distribution default).
• We can move the most of the scheme management from the daemon to KPowersave. This make KPowersave anymore flexible than before.
• We have now the chance to get KPowersave into the KDE SVN and maybe KPowersave could replace KLaptop as default KDE powermanagement solution.

And the disadvantages?

• We lose the great powersave daemon, but for more read this post.
  

Tags: KPowersave KDE Linux

How to cheat distrowatch ranking

You always wanted to know how to promote the ranking of your Linux distribution at distrowatch? Simply do the same as in the english version of the Fedora wiki start page and link against the page of your distribution at distrowatch.com instead of provide your own package list (as e.g. Debian or openSUSE do). And don't forget to name the link 'Packages' ;-) :

And whoso want to know which packages are available push the level of popularity for your Linux distribution in the 'Page Hit Ranking' with each click (checked google's cache and this link in the fedora wiki is new):

Tags: linux distrowatch

Novell and Microsoft ?

I'm not quite sure what to make of this news/rumors:

• (REUTERS) Microsoft, Novell reach agreement on Linux
• (WSJ) Microsoft Is Set to Give Linux a Boost Through Partnership With Novell

The best would be to wait for the offical annoucements from Novell and Microsoft (webcast), but sounds a littlebit like sup with the devil ;-) . We will see.

Update: Annoucement "Joint letter to the Open Source Community"

Tags: Novell SUSE Linux Microsoft

KPowersave status

Today a short update about the current status of the KPowersave development for the next stable version running with HAL instead of the powersave daemon:

We have a new deadline for the first running base version on KPowersave. It's openSUSE 10.2 Beta2, which means I need to checkin the new package at least Monday the 06.11.2006 to get a running version into the release. In Beta1 KPowersave is not in the default selection because of problems with the connection to D-Bus. I had no time to take a look at this issue, so thanks to Timo Hoenig for the patch to fix the problem in the old and new upcomming versions.

Unfortunately I could not commit the fix (and work on KPowersave) because of problems with the SVN server of Novell Forge. The server is down since Friday (27.10.) without any previous announcement from the admins. This is very annoying for the users and really unprofessional from the admins of Novell Forge, also because the service is down the complete weekend. Very good for the deadline for Beta2 if you host a project there.

Nevertheless we finished the most of the work on the hardware information and abstraction part of KPowersave. Now we can start with integrate the new base classes into the applet/GUI.

Tags: KPowersave development

HAL patch collection

There a currently some patches I send to the HAL mailing list which aren't included in the git repository so far. They should be included in the new HAL package for openSUSE 10.2 Beta2. Here a list of these patches (feel free to use them on your own distribution):

• fix build (hald-addon-macbookpro-backlight) against newer versions of libpci: here
  
• add support for Standby (S1) to HAL: here
• remove backend postfix from script filenames (need maybe rename files by hand, for more see this mail thread): here
• A performance fix for search in pci.ids for vendor and product information of PCI devices. This patch is a reworked version of a inital patch from Ihno Krumreich. I extended the patch to fix bug in the search algorithm and to stop search if found everything we looking for. This patch speed up the search in the list by factor ~8-15 if HAL starts up: here
  
• A new version of my patch to detect Tablet PCs (as e.g. with Wacom tablet devices and some Fujitsu Siemens machines) and to set the needed serial ports on boot: here

These patches are against current HAL git. You can find all my current HAL patches here.

Tags: HAL patches

KPowersave development for next stable (0.8.x)

Today a (short) brief/information about the current planed and already started development for the new KPowersave development tree (0.7.x) and the next stable version (0.8.x):

Preamble

Since Powersave starts to die and the powermanagement tasks going into HAL we need to change KPowersave to use HAL instead of Powersave.

Only for the log: I don't like this step and for me is the concept to put _all_ (hardware information, powermanagement, mounting, partition, format ...) stuff into one daemon, (into this crappy HAL and only because some desktop developer are not able to write a UNIX like daemon for special tasks) a really stupid idea.

I liked the old powersave. This was a great piece of code which contains several man-years of knowledge about ACPI/APM and powermanagement and did a great job over the years. I'm not happy about losing it.

This changes mean at least also more trouble in KPowersave.

Table of contents:

1. HAL/Powersave basics
2. Replace Powersave
3. GUI
4. Testing
5. Documentation/Translation
6. Timeframe

(1) HAL/Powersave basics

Currently KPowersave use Powersave and libpower from powersave to get hardware information, to switch schemes, to set CPU Freq and to trigger suspend2*/standby.

In general we need to connect now directly to HAL to get a signal if something on hardware changed, if we want to avoid permanent polling e.g. for battery information via libpower. There are two possible ways: listen to HAL for changes and call libpower to fresh up device information or listen to HAL and collect all device information directly in KPowersave.

I would go the second way. This should reduce the overhead of the library (libpower currently (old version KPowersave currently depends on) provide several info we never need and miss some other info we need now). If we implement this directly in KPowersave we can cache the information and need only to update the changed values (e.g. we need only call hal for current battery percentage and only for this key and only for this special battery) which should reduce the overhead on DBUS and allow KPowersave a finer grained signal and information pool.

Needed work:

implement a new class to:

• hold connection to the HAL interface via DBUS (done)
• to provide a layer to libhal to get device info (done)
• add methods to find devices by capability and property (done)
• to provide a layer to call DBUS methodes on HAL/DBUS interface (done)

implement a class to collect and abstract:

• battery, ac, lid information (75% done, need to think about the battery stuff)
• info about suspend, brightness, CPU Freq (done, TODO: add support for PolicyKit information)
• add function to update the related info if something changed. (in progress, Danny/Frank)

(2) replace Powersave

To replace currently by powersave provided functionality we need to change several issues in KPowersave:

suspend2*/standby:

Old Powersave provided a interface to trigger suspend2*/standby and to check if the user is allowed to call this methodes. HAL provide currently only a abstraction of the kernel interface, which mean we can only say if the machine/kernel can suspend in general, but we can't say if:

• the user is allowed to call these methodes
• the machine is really suspendable (or if the machine is e.g. not able to suspend2ram and is blacklisted e.g. in s2ram).

Problems:

• I have currently no idea how we can fix this. Maybe via PolicyKit, but this is not sure because we don't know if this go really in SUSE 10.2 or if PolicyKit is mandatory for HAL upstrean in the future. This situation is really bad and the sideeffects are annoying for the user.
• HAL only support suspend2* and not standby atm upstream (on SUSE we have a patch for this).

battery alarm states:

Powersave currently provide the battery alarm states and the config at which point which state is reached. We need to move this to KPowersave and make it configurable only in general and not per scheme. We need to configure the three states and the related actions (e.g. warn user, suspend, shutdown)

Problems:

• Several different users can be connected to the system and every user can define different states and different actions which results in a chaos. This is at least again the same problem as with CPU freq via HAL and fighting clients. Maybe we add this to a admin mode dialog as e.g. in KControl and allow only a systemwide config, but this is only a solution for KDE. (evaluate: discussion started by Holger at: g-p-m Mailing list)

CPU Frequency Policy:

Since CPUFreq settings are moved from powersave to HAL, we need also to replace the current settings in KPowersave. There are two issues:

• make the currently existing different CPUFreq Policies configurable
• make them configurable per scheme

Problems:

• Fighting Clients and other tools (see above).

Schemes:

Powersave currently provide some schemes (powersave, performance, presentation and acoustic), two of them are automatically switched if the AC plug is removed/inserted. We need to implement _real_ schemes in KPowersave. We have currently schemes in KPowersave (with brightness, screensaver, DPMS, autosuspend settings and so on), but we need to make them configurable. This mean we need this stuff:

• create new/remove/edit for current schemes
• make configurable default schemes for AC online/offline (and maybe other events as e.g. lidclose or if detectable adding a beamer to the machine for presentation scheme)
• per scheme CPU Frequency settings (see above)
• per scheme disk settings

Problems:

• There is currently no way to set the harddisk settings, but we need this on some machines which change the settings e.g. via the BIOS on suspend or if the AC plug is removed (which maybe increase Load_Cycle_Count and reduce lifetime of the disk).
• Fighting clients with different settings.

(3) GUI:

Based on the changes from (2) we need to update the configuration dialog to make all the settings configureable for the user. As a first step we don't need to implement this (first finish the basic stuff), we can do the config via the config file. Tasks to do:

• create/remove schemes, as first new schemes with a default config (first steps done). Later we can maybe add a wizard for inexperienced users
• CPU Freq stuff (per scheme, and per policy)
• AC state and actions (global settings)
• Battery states (global settings)

(4) Testing

Provide first working version as always on sf.net/freshmeat and kde-apps.org, send a mail to opensuse ML.

(5) Documentation/Translation

Need to extend, update and translate the documentation. We need also some new translations.

(6) Timeframe

A first stable running version - without not needed stuff from (3) - until openSUSE Beta1/2/final. With the new stable and without dependecy to powersave we can think about push KPowersave into KDE SVN as default KDE powermanagement applet.

You can find all already done changes in the KPowersave SVN at trunk.

Tags: kpowersave