Hanging around on developer IRC channels and quite some mailing lists, I have answered "How do I create driver update disk?" question many times already. Usually a person asking was given RPM package with the fix and was asked to test it by creating driver update disk. Unfortunately, existing documentation leaves that poor fellow pretty helpless as for how it can be done.

There is this (almost) fossil how-to created by Henne and though it still holds up to these days, things were incredibly simplified in the meantime and now anyone can use driver update disk without any advanced technical knowledge. This post is an attempt to make up for missing documentation on the subject.

What is driver update disk and why do I need it?

Driver update disk is a mechanism to add or replace some functionality (binary, library, script, ...) in the minimalistic system of 1st stage of installation (inst-sys). Historically, it was a real physical media (CD/DVD) often used to extend inst-sys by new hardware drivers. Nowadays, its usage is neither limited to physical media, nor to deployment of device drivers.

Usually you would use driver update disk in one of following two situations:

1. Something in inst-sys is broken and you want to replace it with functional version
2. Something is not in inst-sys at all and you want to use it during installation anyway (e.g. a proprietary device driver).

OK, now how do I do it?

We will have a look at two use-cases - creating driver update disk from 1 RPM package (easy) and from two or more RPM packages (a bit more complicated, but still fairly easy), as the procedure slightly differs. We will need:

• replacement/additional RPM package(s)
• HTTP/FTP installation repository (no NFS/CIFS at the moment, sorry)

One package driver update disk

Example: during installation, you want to create /home partition with CrapwareFS which is already supported by YaST, but it fails because of bug in parted. A new parted-x.y-z.rpm seems to contain a fix for the bug. HTTP installation repository is on http://your.server.net/11.2/

1. Place fixed RPM package to HTTP installation repository (e.g. to its root directory)
2. Pass the path to fixed package (which will be one and the only component of our driver update disk) to the installer as follows:
   

   
   dud=http://your.server.net/11.2/parted-x.y-z.rpm
   

   (see picture below where exactly to type it in the installation screen)
3. Launch the installation and enjoy it, provided that updated package really fixes the bug

N packages driver update disk

Example: you have seen package slide show during installation many times already and in order not to be bored while packages are being installed, you would like to play chess (a bit artificially constructed example, but it serves the purpose of showing driver update with more packages fairly well :) ). You have already downloaded xboard-a.b-c, gnuchess-d.e-f and xorg-X11-fonts-g.h-i from contrib or other online repositories. HTTP installation repository is again on http://your.server.net/11.2

1. Place extra RPM packages to the root directory of HTTP repository (you may place it anywhere though, but then modify paths below accordingly)
2. Create a simple text file e.g. info.txt with one package per one line as follows:

   
   dud=http://your.server.net/11.2/xboard-a.b-c.rpm
   dud=http://your.server.net/11.2/gnuches-d.e-f.rpm
   dud=http://your.server.net/11.2/xorg-X11-fonts-g.h-i.rpm

3. Place info file to the root directory of HTTP repository
4. Point the installer to info file:
   

   
   info=http://your.server.net/11.2/info.txt
   





5. Launch the installation
6. As soon as you get bored, open xterm window (Ctrl-Alt-Shift-X), run xboard and play! :)

And we're done. Piece of cake, isn't it? :)

Some more notes: Currently, only HTTP and FTP repositories can handle these simplified driver updated discs. You can use, aside from RPM packages, cpio archives or fs images. If you find this functionality useful, send some beers to Steffen Winterfeld.

Yes, it's been a month since openSUSE Conference 2009 took place. And yes, I've been buried in other work to write my account of it any sooner. So - here it finally is. As there has already been a lot of posts like this, I'll just cherry-pick the things that were the most interesting for me.

I gave  "Libyui - three interfaces for the price of one code" talk and received some valuable feedback (on the conference and later too, as I reiterated the talk for SUSE Prague employees) on making the library even better - how to improve packaging (from Pavol and Martin) and how to modify event handling (from Reinhard). As evaluating myself and the things I do objectively has never been my strength (which means, in other words, that I really suck at it), I'll deliberately not say anything more on topic :) ;) Enjoy libyui slides

Software portal in new costume

I was really looking forward to Benji and Pascal's talk on Software portal as I'm YaST webpin frontend maintainer (which is, contrary to some beliefs, not a beta version anymore - it has its own package and also a brand new chapter in openSUSE 11.2 docu :) ) They introduced concept and architecture of new improved software portal and also described some issues they face. Too many package repositories, lot of package duplication and lack of concise rating system were among the most prominent ones. I was also happy to learn that susetags repo parsing and indexing is on the way, so soon also Factory will be webpin-searchable.

Cute (Qt) community

I couldn't have missed Alexandra Leisse's presentation on Qt community and contributions as it's always delighting to find some of one's own species among tech conference speakers and not to be the only one standing out in the crowd.
Alexandra is web community manager and we learned that even though uploading videos to youtube, tweeting and feeding news to Facebook looks like funny job, it can be hell of a hard work :) She explained how they manage public relations with wannabe developers (in a sense of well accessible developer documentation, contribution how-to, tutorial and feature videos etc.), which ways they took in opening up the code to public (their cooperation with gitorious.org was especially interesting bit) and how they handle community contributions and code reviews. She also described some of the problems they had to tackle.

opensuse.org in the eyes of eye-tracking device

With software usability being my area of interest, I decided to pick one of unconference tracks led by SUSE's usability expert Sigi Olschner. I've never seen usage of eye-tracking device in practice, so I was really curious what feedback it can provide to user interface designer (oddly enough, I couldn't be the guinea pig myself, as I wear contact lenses and the device just failed to calibrate my pupils with lenses on :) ). As sophisticated as eye-tracker is, it can record eye movement, mouse pointer movement and keyboard focus movement and later present data in various forms - such as heat maps, or "movies" (where one can replay the sequence of how user moved the mouse and where s/he looked during the test).

Test tasks this time were really simple. "Go to openSUSE forums and try to find some information on driver for Radeon gfx card" and "Go to openSUSE wiki and find out the date of 11.2 GoldMaster release".

Weeeell ... one does not need an expensive device to find out how much opensuse.org (in a sense - "anything on opensuse.org beyond the title page") sucks^W improvement would be needed and how cumbersome it is to find what you're looking for in there (you're far better off googling for "$searchphrase site:opensuse.org"). But seeing the final video of an attempt to find openSUSE 11.2 GM release date, with user's eye focus running chaotically up and down on the page in combination with mouse pointer zig-zag track revealed opensuse.org's bad usability in its essence (at the end, he was unable to find the date at all - from the title page he correctly navigated to the page announcing milestone7, but couldn't spot the link to full release schedule at its very bottom).

Suggestion: could Pascal's next release countdown applet be moved to some more prominent place e.g. to the opensuse.org title page?

Moreover, in the light of previous talk on Qt community I surfed on Qt community pages later at home and their proffesional appearance, easily accesible information and intuitive navigation were really in sharp contrast with our pages. I wonder how many more users would improved navigation and look&feel of opensuse.org (wiki and forums) win us ...

A movie with package dependencies as main stars

Everyone knows package dependency browser in YaST Qt package manager. So I was rather curious what more on visualizing package dependencies Klaus Kaempf has to show. And that was really something. More sophisticated 2D graph, 3D graph and even a movie, visualizing how GNOME basesystem is being installed and how packages are gradually pulled in (as it really looked like a star galaxy, we can say that GNOME packages were the main stars of the talk :)).
Klaus however left ideas where to use package dependencies visualizations up to the audience and at the end of the brainstorming, there were quite some useful proposals. I really liked one of the build service integration ideas, where I could view which packages block the build of my package when I see its status as "blocked".

.... and that's all, folks. I had to leave early on Saturday. But not early enough to miss out lunch, which was really excellent. Praise goes to conference catering.

openSUSE shop already got the wind of it:


(obviously, this item is so popular that by now, it is available in America's shop only, being sold out from Europe's one for quite some time already).
Surprisingly, so did root.cz, the most popular Czech Linux and open-source e-zine:



(those folks went even further and offered those cute penguin motives also on ladies thongs, check out their shop :))

Unfortunately, this year's openSUSE conference organizing team either assumed that all the conference participants will be male, or (more likely) deliberately chose not to take female minority into account. Ladies tees were sadly not among the conference swag. So I said no, thanks, I already have a shelf full of Linux/opensource/tech conference T-shirts I can hardly wear, because they simply do not fit (those of you who happened to meet me at the conference know that I look drowned even in men's S size ;-) ). I see no point in handing them to friends/relatives either, after all, it was me, not them, who participated at the event, right?

It is a tiny little detail (compared to e.g. lack of wi-fi connection at the conference site), you may say, and you're actually right. But often it is a tiny little detail that can make you feel welcome and accepted in the community (and absence of which, on the contrary, can contribute to the feeling of being marginalized and invisible minority).

I don't believe this is all about money (and saving some cents on T-shirt print run). Some fraction of the T-shirt pool can well be a ladies model, those do not cost more. I also don't believe that majority of ladies tees would be left after the conference as participating ladies simply did not match organizing team estimate when it comes to the sizes. Come on, two years ago really cute ladies tees were handed out on SUSE Labs conference (even though only up to 5 of the participants were female) and they were gone in the first two days. Reason? Hackers simply took them home for their wives/girlfriends.

Imho, this is more about the least common denominator, minimalized effort and that sort of things. But - even if conference swag is just a cherry on the top of the cake, it can speak volumes. About how much you care about your community and how much you value users as individuals.

To conclude, instead of repeating obvious and anything that has been already said, read more on topic

• on Kathy Sierra's blog and
• on geekfeminism wiki

I couldn't say it better. And hey, conference team, for the next year, help openSUSE folks (all of them - including 4% female minority - 10 out of ~250 registered participants were women) look good in your T-shirts. After all, it is a form of community marketing, isn't it?

Now that I'm back from vacation (some breath-taking climbing in Italy), it's time to pamper penny-a-liner side of me and give some publicity to few fresh openSUSE 11.2 features. Here is one of them:

Back in the times of KDE3, I used to find the fact that I can search KCM modules by keywords (that is, in addition to module names, it looked for a match also in groups of tags, describing the function of the module in detail) rather handy. My colleague Pavol, the user of Most Awesome Computer OS X, seemingly appreciates that Apple's System Preferences (equivalent of YaST) can do the same, so he requested feature #305845. It was then a matter of one afternoon to teach Qt4 Control Centre to do the same.

Now let's have a look at some real example. I want to share my vacation photos with the others by exporting the folder, so that they can mount it (or alternatively, I want to mount somebody else's shared folder with photos). After typing 'share' keyword, I can see a selection of YaST modules which I can possibly use:



Now I can choose between samba and NFS server if I want to export my shared folder, or NFS client if I want to mount somebody else's one.

Contribution needed

To make the search effective (better, to make it find at least something ;)), it is necessary to assign sets of suitable keywords to as many YaST modules as possible and this is exactly the place where community contribution will be useful.
So - if you feel that certain YaST module does not match the keyword even though it should, please do one of the following:

• Use bugzilla to file an enhancement request and assign it to the mainteiner of that module
• For that particular YaST package, do a Factory submit request, extending its .desktop file with the keyword(s)

For the latter, use X-SuSE-YaST-Keywords .desktop file entry and add a comma-separated list of words. E.g it can look as follows:

X-SuSE-YaST-Keywords = disk, partition, LVM, RAID, NFS, mount,format, encrypt, fstab 

(guessing which module this could belong to is an exercise for the reader :) ) Anyway, any help will be appreciated ...

"Ladies and gentlemen, now the moment you've all been waiting for - the world famous ..."

... YaST webpin package search client!

It is already quite some time since I blogged about YaST frontend to webpin package search, which enables user to search packages in online repositories and install them via one-click handler later. I proposed some solutions of integrating it with the rest of YaST, but did not particularly like any of them (that's the perfectionist side of me ...). After being (just a little bit :)) poked by some openSUSE users, I decided to implement two of the less perfect solutions ;-) in the first part of Hackweek IV.

In order to use the client and search packages in online repositories, you will need a new yast2-packager-webpin package (which has been splitted off the "main" yast2-packager). It contains the module, the client and the .desktop file, which effectively adds the icon to YaST control centre. The idea behind creating a new package is rather simple - not to clutter software section of CC with (similar) modules/icons by default for all users, including those who don't want to make use of that functionality. Now I guess I've made this package (originating from Packman) rather obsoleted .. :)


In addition to that, you can launch webpin package search from package manager's menu (Qt and ncurses so far), just as you would do with repository manager or online update configuration.

Call for contribution

These are the things that still need to be done in order to get webpin search integration even better:

   1. A new icon for webpin client is needed - as you can see, I recycled package manager icon for the time being
   2. Gtk package manager (yast2-gtk-pkg) can't call webpin client currently - should be simple and straightforward to add the functionality to it.

If any of those sounds appealing to you, please let me know and I'll give you all the necessary information on how, what, where etc. :)

FAQ's

Q: Why haven't you made webpin search separate filter view of package manager/integrated it into regular search in existing package manager(s) GUI?
A: Because neither of package managers (Qt/Gtk/curses) speaks XML and webpin search engine does not speak libzypp. Learning PMs read XML and adjusting their data models to feed it, along with libzypp data, to UI is work for few hackweeks in a row (for me, a person with zero experience with C++ XML libs - yast2-packager-webpin uses Perl XML::Simple). However if anyone's willing to hack on this ...

Q: Why does webpin search not work in Factory?
A: Because Factory is not a rpm-md repo. See bug #431939 for gory details

Picture (and even more so action) speaks louder than words. So ... voilà:



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

Recently I've discovered a secret feature in AutoYaST. Well, probably not so secret, because a SLES11 user (from our Two-Letter Customer) discovered it as well and reported a bug about it :) But all in all, if you googled for the keyword (keep_install_network) a week ago, the only hits were an AutoYaST changelog with short notice "I've added this feature" and few questions about it on opensuse-autoinstall mailing list. The documentation did not reveal any more details.

So - what does keep_install_network parameter, set to 'true' and inserted into <networking> section of AutoYaST profile, do? One can intuitively guess that it will preserve network configuration - that is, interfaces setup, resolv.conf bits, static routing, udev rules & co. - from 1st stage of installation (of course, only if the installation actually runs over the network) and it is indeed like that. Uwe blogs about it in more details

But unless you use openSUSE Factory, please don't try this at home :)

<networking>
  <keep_install_network config:type="boolean">true</keep_install_network>
</networking>

Network interfaces setup (ifcfg files) from the installation will be successfully preserved, but due to a bug, your static routing configuration (if you have any) will be moved into backup file and YaST won't create a new one and you will lose most of the information in /etc/resolv.conf. Unfortunately, nobody got the idea to test with the profile containing nothing more but keep_install_network entry in networking section so far :(

The bug is fixed now for openSUSE 11.2 and SLE11 SP1 (if nothing in particular sub-section of networking section is defined, the setup from installation is used, but AutoYaST profile is the higher authority here). However, if you use SLE11, you'd better install with profile containing at least minimal DNS and routing info, for example like this (set search domain, 1 nameserver and default gateway):

<networking>
    <keep_install_network config:type="boolean">true</keep_install_network>
    <dns>
      <dhcp_hostname config:type="boolean">false</dhcp_hostname>
      <domain>home.net</domain>
      <hostname>dolphin</hostname>
      <nameservers config:type="list"> 
        <nameserver>192.168.0.2</nameserver>
      </nameservers>
      <searchlist config:type="list">
        <search>home.net</search>
      </searchlist>
    </dns>
    <routing>
      <ip_forward config:type="boolean">false</ip_forward>
      <routes config:type="list">
        <route>
          <destination>default</destination>
          <device>-</device>
          <gateway>192.168.0.1</gateway>
          <netmask>-</netmask>
        </route>
      </routes>
    </routing>
  </networking>

Or use a workaround post-script Uwe posted to bugzilla, to backup your setup and to restore it later.

One good thing about these bugs is that not only it broadens your knowledge (when user comes up with scenario you never thought of) ;-) but it also helps us to improve things. keep_install_network feature is now documented and not secret anymore. Enjoy it!

Disclaimer: The information value of this posts tends to zero. Take it as an example of girlie chit-chat.

And now repeat after me:

To begin with - for those who don't know it yet, I got myself a new toy and installing openSUSE 11.1 on it and playing with it looked like a cool way to spend Friday night, now didn't it? Foolishly enough, I decided that I want to have dual boot with pre-installed Windows and I don't want to lose ThinkVantage stuff. Thus, before leaving the office for the weekend, I was briefed by our YaST bootloader wizard which options in bootloader configuration to tick and which leave blank - basically, I must not let YaST overwrite master boot record if I ever want to be able to use ThinkVantage. He did not forget to add that if anything went wrong, I should bring the box over to him on Monday and he'll fix it up for me ...

A small intermezzo: though I've been pretending that I'm doing some YaST development for almost 3 years already ;-) I'm not really a technical person. I know a lot about widgets, user interface, usability and all that fancy stuff, but my knowledge of the system configuration ends in /etc/sysconfig or /etc/fstab at most. When it comes to something like system boot, I'm completely lost. At least I admit to it :-) :-D

The installation went on fine - I picked KDE4 as my default desktop environment, had the partitioner shrink Windows partition, created root and /home partition, double-checked whether I got the bootloader installation options right ("Boot from root partition" - check, "Boot from MBR" - uncheck, "Set active flag for boot partition" - check, "Write generic code to MBR" - uncheck) and watched the slideshow. The standard set of 1st stage finish scripts followed and then bang! - "Failed to install the bootloader. Try the configuration again?" (or something along those lines). Hm, if I answer "Yes" now, I'm smart enough to figure out it'll fail again, I thought, unless I change something - but what? Looking at y2log did not make me any less helpless - the last thing I saw was how bootloader uses some cryptic Perl script (/usr/lib/YaST2/bin/tp_mbr, to be exact) to detect ThinkVantage sequence in MBR and preserve it.

Nevermind, I rebooted, picked "Repair installed system" from the installation options and hoped that yast2-repair will help me find out what went wrong. Not surprisingly, it did not. It only showed me already well-known message about failed bootloader installation - quite a cruel joke :) At this point, I gave up. Trying to solve a problem where I don't understand a single bit of its principles is not that much like me. And after all, there are more pleasant ways how to spend Friday night - dancing salsa, for example ... :)

But don't get desperate, my friends - this story has a good ending. I brought my laptop to the wizard :-) I was not looking over his shoulder as he was working, so I don't know what magic spells and potions he used, but I know he did the following:

1. Created partitioning setup with separate /boot partition and told the bootloader to boot from it (that was maybe the crucial point)
2. Added a repository with openSUSE 11.1 updates as an add-on during installation
3. Made extended partition (with swap, /, /home and /boot) 1 cylinder smaller, as ThinkVantage partition at the very end of the disk did not begin exactly at the cylinder boundary

The last two steps were probably superfluous and it could've well worked out without them, but ... now I can't tell. Anyway the installation finished, the system booted and now I have shiny new ThinkPad with openSUSE 11.1. In this post, I'm writing about interesting host naming schemes people use - as for me, all my machines have animal names. So, say hello to Dolphin - he is named after one of my favourite books by Eric Lambert (it is so little known that even Google does not find it ;-) )

In conclusion, I consider myself to be quite lucky that I'm surrounded by many wizards (bootloader wizard, installation wizard, KDE wizard, some wireless stuff wizards, suspend wizard, ... ) ;-) What do normal openSUSE users who can't grab their machine and bring it to a wizard do, if the same (or similar) thing happens to them? "Oh, they go to #suse and cry there. Or they simply give up and go using Ubuntu" says Darix (whom I sometimes chat with when I suffer from insomnia and he stays at work at night). Sad to say that, but it's probably true ... :-(

LinuxExpo is one of the biggest Czech Linux and open-source software events. It takes place every year in Prague and openSUSE project is for several years already one of the event regulars. In our openSUSE booth visitors can see and try the newest openSUSE release, get openSUSE DVD for free or buy a T-shirt. At the same time, talks and presentations of folks from Prague SUSE office are part of the event program.

This year, I also participated. With Miso Zugec, we had a joint talk on network-based installation and AutoYaST. Miso opened the talk by saying that for installing openSUSE on your machine neither you necessarily need any of the usual pre-requisities such as DVD, hard-disk or monitor, nor you have to spend 1 hour in cold server room clicking and answering installer's questions. He has shown some practical examples of how to use installation repository on network, install on iSCSI disk, or remotely via SSH or VNC.

I went on to introduce AutoYaST - a tool that comes in really handy when you install often, install lot of machines and you want to automate great part of the process. I introduced the basic concept of AutoYaST, showed folks the smallest AutoYaST profile in the world, how to clone your system and mentioned even some advanced AutoYaST usage, such as "<ask>" feature (a simple way of interactively asking for user input - such as root password or hostname - in the beginning of installation), or AutoYaST scripts.

In general, the talk was a success and I'm not saying that just because the presentation room (with ~100 seats) was so full that people had to stand on the corridor as they did not fit in. For me, much more significant measure was the number and meaningfullness of the questions people were asking in question time. At the end, I was really sorry that I did not have more time, so I could have introduced even more AY features, such as rules.

We spent the rest of the day in our openSUSE booth. To attract more visitors, a quiz question on openSUSE (Did you know when the openSUSE project was founded?  Or how many binary packages is there in our BuildService?) was published every hour or so and folks could submit their answers. At announced time, three correct answers were drawn and winners got openSUSE T-shirts, plush geekos and other presents.

Other open-source project also participated on the event. For example, our booth was just next to Ubuntu's one (it was funny to see how people used Ubuntu machines in there to google for correct answers to openSUSE questions :) ). All in all, Pavol has some interesting pictures from the event (these are from Day 1) and there is also an article on LinuxExpo on root.cz (in Czech only, I'm sorry).

P.S. root.cz could definitely benefit from hiring a better photographer ... and I'm not saying that just because I, unlike the photo, don't look like zombie in real life :D In general, much of the photos from the talks are of rather bad quality, considering the fact that you can do much better with my beloved Canon EOS 350D (which is what their photographer also had).

I must admit I've been waiting with this post until today, the reason being that it is not supposed to be 1st April joke, like for example this one (thanks, captain Arvin, you really made me laugh) :D
As you probably noticed, for openSUSE 11.2 our goal is to significantly improve usability of YaST partitioner. I want to show you a feature that is in partitioner for quite some time already, yet it is quite little known. It helps you to customize the partitioner to best suit your needs.

One of the frequent complaints about partitioner was that it is "overengineered" and it presents so much information that it is really confusing for the (home) user i.e. the "1 laptop, 1 hard disk" usecase. While there are some other problematic areas, this particular one can be fixed rather quickly and in a simple way. And by "fixed" I of course do not mean that from now on, we will tailor the partitioner only to the needs of Aunt Tillie (Oma Krause), leaving the power users high and dry. Let's have a look at partitioner settings (that is, we'll switch to the branch labeled "Settings" in the left tree panel), especially at "visible fields" selection box:



Here you can set which information on storage devices you want to see, that is, how many columns the tables are going to have and how much details the overviews are going to contain. The less boxes you tick, the less details that only uselessly fill up the screen you'll see. For example, if you use neither LVM nor RAID setup, seeing "used-by" field is probably of no use to you. Similarly, if you have laptop with one hard disk, you don't need fiber channel ID bits of information. And since these settings are written to sysconfig, they are persistent. This is the default sysconfig configuration shipped with openSUSE 11.1 (and SLES11):



Too detailed and not much home-user friendly, now is it? This is the new, simplified default for openSUSE 11.2:



If you are a power user who uses advanced setup and wants to see more detailed information, you now know where to go and make it visible again :) Besides data presentation details, you can also pick a default filesystem or default mount-by method for newly created devices here.

Everybody else is doing it, so why can't we?

If you have ever used partitioning GUI tools in other distribution, even on other operating systems (GParted, PartitionMagic, DiskDruid,...), you have noticed that almost every one of those has some graphical representation of how the disk is partitioned. From now on, even YaST partitioner does:



However, compared to other partitioners, our bar graph is rather dumb. It is not interactive (if you click on a partition in graph, nothing happens) and it does not even highlight current partition as one scrolls down the table. At least a tiny little improvement is that it can do tooltips now, so if the partition description text is too wide it does not fit the graph segment, the text is still replicated in a tooltip.

Do you like the graph? Do you want to have it improved? If so, please vote for feature 303534 in openFATE. I'd really like to have at least highlighting the current partition implemented (preferably, by thick pink border :) :D

When it comes to software, its users are usually very picky creatures :-) Put feature X in and hear them complaining how bad and user-unfriendly you actually made it. If they complain long/loudly enough, finally decide to remove it and be sure that so-far silent majority starts to complain even more.

It was the same with YaST package manager and pop-up question from the title of this post. I'm sure we all remember that one:



It was introduced in openSUSE 10.1 (aka BrokenSwManagement edition) in order to alleviate suffering of the poor users forced to use our package management (powered by zmd and baby-libzypp) with ultra-slow start-up. libzypp grew faster and faster over the time, but the pop-up question remained and (quite reasonably) it started to annoy users. "Why do I have to click to have this crappy pop-up disappear?" they asked. "I've made my choice, installed all packages I wanted, so I want to answer no further questions."

After many heated discussions, we finally made the pop-up go away in openSUSE 11.1 After clicking on 'Accept' and installing all packages, package manager simply ended. That, of course, made the other half of the users speak up: "Why YaST does not ask anymore whether I want to install more packages? I don't want to start package manager anew each time. I simply want to have an option to install something more I forgot about in the first round."

In openSUSE 11.2, my colleague lslezak (now the link to his blog should be here, but he is too shy to have one :)) used really ingenious way of cutting the Gordian knot - he made the behaviour on exit from package manager configurable. And not only that - besides an option to close package manager (for those who want to be done with it) and option to restart it (for those who may want to come back and select something more), he added a third one. When the package installation is over, you can choose to display a neat summary of what has been installed/deleted, how long did it take and view some detailed logs. Then, you can either finish, or go back to install more packages:


Now all you have to do is to open /etc/sysconfig/yast2 file in your favourite editor and set PKGMGR_ACTION_AT_EXIT variable to some reasonable value. Please find more detailed information here.

"But I don't want to edit some cryptic file manually," you might think. "Isn't there any other way?" Well, of course there is. YaST ncurses package manager has a brand new menu that allows you to pick the exit action of your choice in a few key presses:


There are some minor things left to polish, but it basically works by now. Better don't ask me how the sysconfig variable is actually written :-) It took me by surprise to realize that libzypp's interface to sysconfig is read-only, so I'm impatienly waiting for Augeas ;-)

Recently Stano blogged about YaST interface to webpin package search, which is a joint work of me and Kobliha. Most of the responses and comments he got were something around these lines: "Wow, this is really cool feature, where can I find it? How comes it is so hidden?".

Well, yes, the webpin client is hidden - 'yast -l' does not show it and there is neither an icon in control centre, nor a menu or a button in other YaST module one could simply click and search the packages using webpin service from within YaST. You simply have to know the command (yast2 webpin_package_search) and type it in the shell. One of the reasons we did not make it more visible in openSUSE 11.1 was that the tool was not in the state we could be exactly proud of :) (due to lack of time to polish it in SLE11 bug typhoon :) ) There were two major flaws of yast2-webpin:

1. It did not remember selected packages in multiple queries - the user could do many searches and select several packages in each of them, but only packages selected in the last query were forwarded to OneClickInstall wizard at the end
2. "All Selected Packages" tab (intended to be used for viewing all packages selected so far) did not do anything bad, but did not work either. It always showed a blank list.

Making it all work

Good news: none of the above will be true anymore with pending yast2-packager check-in into Factory. How does it all work then? Suppose I want install some additional games into my openSUSE system. I'm a devout chess player and playing with computer is fun (especially when there are no human players around), so let's search for "chess" expression and pick something then - brutalchess will do. Fish Fillets is another of my favourite games and after hitting Search button for the second time, I'm voting for fillets-ng and fillets-ng-data packages:


Now let's check if webpin client really remembers user's selection from both queries and switch to "All Selected Packages" tab. Yes, all three are there and they're succesfully forwarded to OneClickInstall Wizard later (after clicking on Next):

Where to place it?

Bad news: I still did not find, what I was looking for - a decent shelter for webpin_package_search client :-( Now it all works so well ;-) it would be really nice to let all users (not only those who waste^Wspend their evenings reading PlanetSUSE blogs :-)) know the functionality is there and they can use it. There are three options I can (and certainly many more I can't) think of so far. But the thing is, I don't particularly like any of them as they all have certain drawbacks. Here they are:

1. Place a new icon into YaST Control Centre, Software section. Drawback: there is already too many icons in Software section, which is certainly very confusing for the users, so we're trying to reduce number of them as much as possible. Adding a new webpin icon would contradict this effort.
2. Make search using webpin accesible from package manager's menu (I'm using ncurses PM as an example here as Qt packager is being rewritten atm). Drawback: it is just a little bit less hidden than now - you have to know the menu item is there so you can use it:
   
   
    
3. Add a new button to package manager's search screen. Drawback: in my H.O., it looks ugly :)
   
   

Feedback wanted

To solve this problem, I need your feedback and your ideas. What is, in your opinion, the best place for YaST webpin client? Do you like any of ideas I presented? Or do you have your own idea from where would you like to access webpin client? If yes, don't hesitate to drop me a comment.

Recently Jozef approached my desk and asked for help with "unsolvable" partitioner problem: during installation, he opened a console and created custom partitioning setup using fdisk. Then, not suprisingly, he wanted the partitioner to discard proposed setup and pick up the one he made. I must have had a blackout at that time (too little coffee, maybe :) ), but I was simply unable to help. We ended up clicking just about everywhere, mostly on "Back" buttons in installation workflow, without much success.

It was only the next day as I was having my lunch (I know it sounds surreal, but it was really so) when it finally dawned on me. We have "Rescan Disks" button, hidden in "Hard Disks" configuration screen and it does exactly what Jozef wanted to do: re-reads partitioning configuration.



Not that I would want to encourage you to use different tools than our partitioner *, but sometimes you really want/need to do it. Perhaps you don't feel comfortable with clickety interface, you are much more familiar with CLI tools and you want to use GUI just for some minor adjustments (e.g. defining mount points) ... Whatever, if you want the partitioner to pick up your hand-made configuration, press "Rescan Disks" button.

( *) it is not a supported scenario and if you do so anyway and run into problems, you should not ask us for help in Bugzilla :) in other words, do what I suggest here only if you know exactly what you are doing )

Come to think of it, hard disks and partitions are not the only two types of storage devices. You might want to use CLI utilities to create e.g. LVMs or RAIDs (even during installation, necessary tools are in inst-sys because partitioner calls them for you if you use clickety approach) Wouldn't the "Rescan" button be better off on the main partitioner screen? Like this:

Bright future ++

In openSUSE 11.2, we will be (among other things) working on improving the usability of partitioner interface. That includes resolving currently opened usability-related bugs, but for example also reducing the time user spends in the interface searching for the right dialogs and right buttons performing the most common tasks (which is, in my opinion, one of the most prominent usability flaws of the partitioner).

As for the new feature set, partitioner plans for 11.2 are still mostly up in the air, but you can already try an hors-d'oeuvre from our YaCHT kitchen, brought to you by the main cook captain Arvin. Coded with love and passion, try it :D A nice tool to visualize the structure of storage devices on your system, to show where the volumes are mounted and how are they bundled into LVMs/RAIDs. The whole thing will look even cooler in the future and the graph nodes will be clickable.

Oh, and before I forget: there are two "easter eggs" in the screenshot in Arvin's blogpost. Let's see if you can find them :) I found one and, looking for some well-known mathematical constant, such as π or e, I did not see the forest for the trees :D

Once upon a time, in the country of Novell-land, there was a happy community of openSUSE users who once in about six months installed a shiny new openSUSE operating system onto their magic boxes. To do that, they used a powerful tool called YaST, brought to them by group of hardworking goblins called YaSTees whose work has been closely watched by Good Project Manager Stano and team leads Duncan and Jiri.

In most of the cases, installation went on smoothly and users really appreciated a panel with the list of installation steps that was visible at all times, showing them where exactly in the installation workflow they were. But sometimes, it was necessary to make a side-step from the main workflow and open a new dialog, which covered the steps. That was something Good Project Manager Stano did not like. He said: "Installation looks ugly without steps" and asked YaSTees do to something with it. So they did and since then, no dialog ever made the steps invisible again.

But things weren't always so idyllic in openSUSE community. An evil and very, very old creature - Ancient Screen Resolution from the Last Century, nicknamed 800x600, lived in Novell-land and sometimes it was sent by mischievous X11 gods to squat in the magic boxes of ordinary openSUSE users. As installation steps occupied almost one third of user's screen, little of space was left for the rest of installation clickety stuff in such case. Users were unhappy, as partitioning the disk or configuring the printer was now rather cumbersome for them. Here is what they've seen:



Two of YaSTees' wizard friends, old QFrame and his son, QSplitter gathered and were thinking about how to help YaSTees to make their users (especially those who were hit by 800x600 beast) happy again. Old QFrame wizard knew how to group all his children widgets horizontally side by side and passed all his knowledge to his son, but QSplitter went even further. He learned how to insert small knobs between his children, and with the help of user's mouse, he could change the proportions of the window occupied by each individual widget, eventually make some of the widgets completely disappear and appear again. QFrame said: "I am very old now and I grew tired in YaSTees' services over the time. And this task is already too much for me and my abilities. It will be better, if you take over, my son, and from now on, it will be you who is responsible for arranging all those misbehaving widgets in the installation". And he retired, packed his luggage and went travelling around the world.

It was a great challenge for QSplitter wizard. The task was easy with the dialogs of the main installation workflow, but taming the dialogs of sub-workflows was much more difficult quest. As unlikely as it may seem, what can be seen here is not one "window", but two of them, overlapping each other in such a way, that only the side panel with steps is visible from the bottom one:



But QSplitter finally succeeded. What did it mean for openSUSE users? Now even if 800x600 evil creature resided in their magic box, thanks to QSplitter they could use their mouse, hide installation steps for the time being and give more space to the tool for partitioning their disk (configuring their printer). Then, they could of course recover the steps again. Here is how it looked like:




At the end, everyone was happy. And that, dear children, is the end of this fairytale. We have proven that the solution exists and we can go back to sleep :-) :-D

Acknowledgements: to HuHa for his YDialogSpy (excellent debugging tool), to Good Project Manager Stano for his spiritual support :) and to captain Arvin for the final impulse, so I stopped lazying around and finally got down to doing something

I have no clue how RSS feeds are supposed to work, however when fixing just a typo in Mr. PratchetT's name ;-) in this post (written in quite a stress just before leaving for vacation in certain warm-climate country), it got pushed into RSS anew. Oh well, sorry for bothering with that boring real-life joke again ... But that's not what I wanted to write about. Some small bits and pieces from my YaST development agenda accumulated over the time. None of them deserves a separate entry though, so I'm placing them all here.

First some bad news for 11.1 openSUSErs (SLES/D ones, on the other hand, can celebrate):

Changing hostname with YaST

It has always been fascinating for me to observe computer naming schemes people choose. Middle-Earth geography, hard-to-pronounce spider genus names (a colleague of mine is a devout spider breeder), coolo's female characters from Shakespeare plays ...
When it comes to setting the hostname of your machine so that it fits your naming scheme :-) there were two important milestones in YaST development:

1. Since 11.0 you can opt for installation with automatic configuration. In other words, the installer asks minimum of questions and proposes some reasonable default values otherwise, so you don't have to click 'Next-Next-Accept' so much.
2. YaST and NetworkManager marriage tied together via sysconfig bound has been officially divorced in 11.1. NetworkManager now uses its own settings system independent of system-wide /etc/sysconfig. Therefore, if NetworkManager is in charge of controlling the network and you run YaST network configuration module, most of the fields for inputting some values will be greyed-out.

What does it mean? If you install with automatic configuration, you won't have an opportunity to set your hostname during the installation and you'll end up with 'linux-$random' instead. And since YaST network setup is inaccessible when NetworkManager controls the network (which is the default proposal for laptops), you will not be able to change it, unless you manually edit /etc/HOSTNAME file. Bothersome, isn't it?

Fortunately, allowing to change hostname in YaST is a question of un-disabling two widgets (compared to more work with adding related UI to NM connection editor). Don't be scarred off by this pop-up message:



Just switch to Hostname/DNS tab and set the hostname of your choice:


But unfortunately, only in SLES/D 11 and in openSUSE 11.2. It was too late for 11.1 :-(

Punycode? What the ...

If the world was ideal (in this particular case - composed of ASCII-characters only ;-)), it would be certainly quite boring. As non-ASCII characters in hostname and domain name would drive hostname resolvers crazy, smart people came up with punycode, which is a schema for converting such hostnames into RFC-compliant character set. Thus, a domain names příliš.žluťoučký.kůň.cz * or 我爱你.zh ** become, after converting to punycode xn--pli-rma35ctb.xn--luouk-uva4it5a4g.xn--k-qla0j.cz or xn--6qq986b3xl.zh respectively. Which is certainly more machine- than human-readable. Good news is that SLES/D 11 YaST will now do the conversion for you:


Many thanks to Lukas for this Punycode YCP module (originally written for yast2-dns-server, because we support punycode in DNS zones, too), without it, it would be much more difficult to add punycode support to hostnames configuration. And again, this candy is only for SLES/D users :-( (or those patient enough to wait for 11.2)

i18n in yast2-apparmor - saga continues

Ok, so I thought I was particularly smart when I thought I made yast2-apparmor finally see the right translated strings, as I describe it here. Well, not surprisingly, I wasn't. Two programs - AppArmor UI frontend (YaST) and AppArmor CLI backend (genprof & friends) - talk to each other, but use different textdomains (originally, they didn't, I changed it in order to have yast2-apparmor pot files generated together with those of other YaST modules).
The key to make strings from both sources correctly translated is not to overwrite textdomain to 'yast2-apparmor' on global level, but to use customized gettext function for YaST UI strings and 'apparmor-utils' otherwise (globally). In case you'll ever need it, here is 'mygettext', doing the job:

setlocale(LC_MESSAGES, "");
my $dom = Locale::gettext->domain_raw("yast2-apparmor");
$dom->dir("/usr/share/YaST2/locale");
$dom->codeset("UTF-8");

#bubli's own variation of gettext, because we need to
#translate strings in two textdomains
sub mygettext
{
    my $msgid = shift;
    return $dom->get("$msgid");
}

Oh, and if you happen to see the strings coming out in incorrect encoding, please vote for this bug.

*) it means 'a horse too yellow' - not very meaningful phrase even in czech, but it is used to demonstrate as many accented czech letters in as few words as possible
**) decrypting this is a homework for watchful reader :-)
***) if you use some interesting host naming schemes, you can drop me a comment :)

Using associative containers (be it Perl hashes, C++ std::maps or YCP maps) may be certainly fun. Inserting/retrieving/changing values is efficient and easy, once we know the key. However, elements of every associative container are ordered, one way or the other, and one cannot really retrieve them all back in the order of insertion. Though it is certainly beneficial feature sometimes, it makes associative containers unusable in other cases, especially in those where the order matters.
Recently I had particularly excellent time with STL C++'s maps while fixing bug #439088 (a.k.a. "How to make hierarchical structure, which I cannot visualize, flat and keep the ordering of elements at the same time") ;-) :-D but that's not what I am going to write about. Now listen to the story of yast2-sudo:

Juggling with sudo rules

openSUSE 10.2 was the first release that came with user-friendly way of creating/editing sudo rules in YaST. If you ever wondered what are these for, they enable 'normal' (non-root) users to run specified commands as root (or other user), without actually knowing his password. The rules are stored in /etc/sudoers file and ... yes, right, the order really matters there. What does it mean? As the user invokes sudo, sudoers file is searched for matching rules. If multiple rules happen to match our user, the last one of those is taken into account. Which may not, unfortunately, be also the best one ;-)

Consider the following example: on your machine, you want to enable Tux the Penguin (user tux) to install additional cool software from openSUSE repositories by running YaST software (sw_single) module, but you don't want disclose root password to him. Easy as that, you will add a new rule to sudoers file that will enable Tux to run yast sw_single as the user in root group (and we won't ask him for password, too) as follows:

# don't try this at home, it will not do what you want :)
tux  ALL = (%root) NOPASSWD: /sbin/yast sw_single
ALL  ALL = (ALL) ALL  

Now, will this really do the job? As mentioned above, out of multiple matching rules, the last one is applied. Tux matches the first rule, but also the second one, which will be unfortunately used in this case ('ALL' is a catch-all alias for any user - the rule basically says that everybody can do anything, but needs to enter the target user's password in order to do so). So this does not really help us. We want to do something like this:

# this is the right way
ALL     ALL = (ALL) ALL  
tux  ALL = (%root) NOPASSWD: /sbin/yast sw_single

In other words, we want to place our rule to /etc/sudoers in such a way, that it will be the last matching one. And, last but not least, it would be also good if a configuration tool respected the order and didn't re-shuffle the rules whenever it sees fit, now wouldn't it?

Being an inexperienced greenhorn

yast2-sudo was the module that made me jump headlong into YaST development and, at the end, made a real YaSTie out of the shy girl I was before ;-) Writing it from scratch was the best way to understand how the components of YaST cooperate together (if you want to know more on this topic, here is some useful reading for you). However, it took almost two releases of openSUSE to discover the fundamental error I made in its design.
In YaST-speak, agent is the part of YaST module that grabs the configuration file, parses it and stuffs the data into some (more or less) reasonable data structure. As an inexperienced greenhorn, I wrote an agent in Perl that parses sudoers file. So far, so good. But as you might have already guessed, I used associative container (Perl hash, in this case) to hold sudoers data, not knowing that it will cause the rules to change their order, and mess everything up if the user is unlucky enough.

Cleaning up the mess

Now I had two options how to make yast2-sudo behave and preserve the order of sudo rules:

1. Use Perl's tied hash in agent and make sure YCP preserves the order as well
2. Store sudoers data in non-associative container and rewrite YCP stuff not to use maps, but lists

At the end, I opted for the second way. Though it was much more work for me, it was somehow cleaner solution. It meant throwing away not only parts of Perl agent, but also major portion of business logic, so that only user interface remained, but on the other hand, it simplified things quite a bit. The final diff has 1597 lines and I hope it will make it to openSUSE 11.1 RC1. Then, please, give it a good deal of testing and do not forget to report bugs :-)
One more thing, though. I've added a small aid to user interface for you to help you prioritize your sudo rules:

Once upon a time, there was a powerful tool called Autoyast. Using single Autoyast XML profile, one could easily install one hundred identically configured computers, exact clones of the first one. All that in (almost) unattended mode, so the sysadmin could go to the pub and have a beer (or two) in the meantime.
If you want to know more about Autoyast and how the cloning works, you'd better ask Uwe or read the official documentation maintained by him. This fairytale, liebe kinder, is about something slightly different.

In some cases, installing the whole system from scratch using Autoyast is not exactly what you have to (and want to) do. You might want to re-use only some well-defined bits and pieces of configuration that are proven to work on an old machine with a new one. And, of course, neither you want to browse the documentation, find the needed configuration files and copy-paste the lines there once again, nor you want to click through all the YaST modules for hundredth time over.
For example, you want to set up a shiny new workstation, with your home directory on local NFSv4 server with Kerberos authentication:

<nfs config:type="list">
   <nfs_entry>
     <mount_point>/home</mount_point>
     <nfs_options>sec=krb5i,intr</nfs_options>
     <server_path>nfs.myserver.net:/home</server_path>
     <vfstype>nfs4</vfstype> 
     </nfs_entry>
</nfs>

Your company stores user identities in LDAP, so you'll need a working LDAP client as well:

<ldap>
    <base_config_dn></base_config_dn>
    <bind_dn></bind_dn>
    <create_ldap config:type="boolean">false</create_ldap>
    <file_server config:type="boolean">false</file_server>
    <ldap_domain>ou=users,dc=myserver,dc=net</ldap_domain>
    <ldap_server>ldap.myserver.net</ldap_server>
    <ldap_tls config:type="boolean">false</ldap_tls>
    <ldap_v2 config:type="boolean">false</ldap_v2>
    <login_enabled config:type="boolean">true</login_enabled>
    <member_attribute>member</member_attribute>
    <pam_password>crypt</pam_password>
    <start_autofs config:type="boolean">false</start_autofs>
    <start_ldap config:type="boolean">true</start_ldap>
</ldap>

And, last but not least, you are behind a proxy and you want to set it up, too:

<proxy>
    <enabled config:type="boolean">true</enabled>
    <ftp_proxy>http://proxy.myserver.net:3128</ftp_proxy>
    <http_proxy>http://proxy.myserver.net:3128</http_proxy>
    <https_proxy>http://proxy.myserver.net:3128</https_proxy>
    <no_proxy>localhost</no_proxy>
    <proxy_password></proxy_password>
    <proxy_user></proxy_user>
</proxy>

Now we gathered all the pieces of configuration we want to transfer to the new machine, so let's save it, e.g. in /var/lib/autoyast/repository/mycoolprofile.xml

ayast_setup CLI in practice

ayast_setup is a commandline client designed exactly for the purpose of applying configuration stored in a small custom Autoyast XML profile to already running installed system. Let's see what it can do (some lines from the listing have been omitted for the sake of simplicity):

tux@pleczka:~> /sbin/yast ayast_setup help

YaST Configuration Module ayast_setup
--------------------------------------

Client for autoyast configuration on the running system

Basic Syntax:
    yast2 ayast_setup interactive
    yast2 ayast_setup <command> [verbose] [options]
    ....
    yast2 ayast_setup <command> help

Commands:
    setup  Configure the system using given autoyast profile

We can see it supports only one possible command - setup. Let's have a look how to use it (just substitute 'setup' for <command> keyword above):

tux@pleczka:~> /sbin/yast ayast_setup setup help

YaST Configuration Module ayast_setup
--------------------------------------

Command 'setup'
    Configure the system using given autoyast profile

    Options:
        filename  [string]  Path to autoyast profile
        ....

    Options of the [string] type must be written in the form 'option=value'.

    Example:
        setup filename=/path/to/profile

We need to specify a path to profile as setup's command filename option. So let's do it:

tux@pleczka:~> /sbin/yast ayast_setup setup filename=/var/lib/autoinstallation/repository/mycoolprofile.xml

And we're done. Depending on the size of your custom Autoyast profile, you can now leave and have a coffee and/or something else while the system is being configured. It usually won't take more than one portion of the brain-stimulator of your choice :)

Some more notes

ayast_setup has been written by Uwe and polished by /me during HackWeek 3. Most of the time I use it for testing Autoyast-related bugs in my modules.

And for those not feeling comfortable in CLI, since openSUSE 11.1 also a clickety stuff can be used to do the same :) Just run 'yast autoyast', open the profile of your choice and then click on 'Apply to System'

... but were afraid to ask :-)

When I used to maintain YaST ncurses frontend, I often heard people complaining how clumsy and hard to use it actually is. So I decided to do something against it, but at the same time I realized that people often do not use the full potential of user interface and many of kludges and gimmicks it offers simply remain hidden to them. This post is an attempt to broaden the education of those who live in console world only.

Hackers never read help

In the stone ages of openSUSE <= 11.0, on opening YaST window, there used to be a tiny little Press F1 for Help note in the top right corner. But ... have you ever seen a real hacker reading help? I haven't :-) Anyway, if you had opened the window, here is what you would have seen:

Quiz question: how to close the help window? :-)

If you were smart enough, you might have figured out that in order to create a new user in this dialog, instead of pressing eight (!) times Shift-Tab key to jump to the Add button, you could simply press F3 key and you were there. The thing is, however, that most users didn't figure out, kept pressing Shift-Tab relentlessly and complained afterwards.
So - how to show F-keys to the users and tell them how to use them, if they never bother to open help window? Yes, make them visible permanently! (I admit being strongly inspired by Midnight Commander). In openSUSE 11.0 a contrast bottom line listing available F-keys for current dialog appeared for the first time:

Lists, tables, trees, multi-selections & other beasts

These are basically UI elements (widgets) listing several items of one kind (e.g. all network cards in the system, RPM groups the packages can belong to, all system users and daemons,...). Using common sense, it is pretty easy to infer that up-arrow key moves the keyboard focus one item up, down-arrow key does the same in the downward direction, PageUp/PageDown key jumps one screen up/down, End key jumps to the last item (Home to the first one) and left-arrow and right-arrow scroll the pad horizontally.

Ok, ok, this belongs to openSUSE I-am-newbie-and-I-am-totally-lost guide, but practice makes perfect :) There are however certain cool things that make tasks in UI easier and that are not obvious at the first sight

(Un)packing tree branches

Tree is an ideal widget to visualize something hierarchical - a nice example of that can be a directory structure. Take for example a sysconfig editor:

Besides jumping back and forth between the items, you need to pack or unpack tree branch to see what is hidden below (or to make the content of currently visible branch invisible again). Arrow keys have already different function (scrolling), so what to use here? SPACE key is not the only option to toggle branch state, you may press also Insert or '+' to unpack and Delete or '-' to pack the branch.

Sorting the tables

Tables in graphical UIs (Qt, Gtk) usually allow users to select a column that will be used as a key for sorting data in the table simply by clicking on that column. YaST ncurses UI enables you to do that, too. Don't you believe?
Consider for example table, listing system groups. By default, they are sorted by name. But now I want to sort them by group ID. How do I do that? Well, simply by pressing Ctrl-O over the table and by selecting GID line in the small pop-up window that appears:

Quick multiselection

Multiselection box enables you to select more than one of several items. Like, in this example, you have one system group and you want to add several users to it:


Using SPACE or ENTER key to toggle user's group membership is an obvious choice. But if you want to select many users in a row, '+' key may come in handy. Not only it selects the user, it also jumps to the next one in the list, so you don't have to do it with arrow key yourself. '-' key works in pretty the same fashion for deselecting.

Don't peck 65536 times into up-arrow key

YaST uses so-called IntField widget for inserting integer values. Consider for example that you have 256 MB large swap partition and you want to double its size. That would mean ... gee, pressing up-arrow key 256 times! Fortunately, there is an easier way. Just press any number (0-9) over the number input field, enter the exact value into the small pop-up window that appears and you're done.



It is also helpful to see the minimum and maximum value of the number you can enter in the very same window.

And that's all, folks. ... and they used serial console with 80x25 linux term happily ever after :-)

For openSUSE 11.0, ncurses package manager got entirely different look and feel. To list at least few changes, let me mention for example menus reorganization or easier accesibility of package filters, as you can see in the screenshots here or here
However, as a developer, I mostly only 'view' the software and do some quick testing, instead of really using it :-) (which is sad, but unfortunately true due to time constraints). Thus, to make the software better, I need some valuable feedback from the users i.e. those who use the software in real life situations and with real data.
It was only after release of openSUSE 11.0 I started to get this feedback (mostly through bugzilla) and based on it, some important changes took place. Here is an overview of them:

Easier accesibility of package search

In the previous version of package manager, filtering packages by patterns was a default view (very simple reason being that it was the first one in the list). However, it is package searching function that users probably use the most often. It was therefore not surprising they complained that package search - accesible with a single keypress (Alt-S) before - is now hidden in the filter menu and accessing it is very clumsy (Alt-F for Filter, then scroll down the keyboard-shortcut-less list). Moreover, user had to insert the search expression, tab to the search button, hit it and only then got some results. Let's see what we have now:



Search filter is the default one and after package manager startup, keyboard focus is right on the search expression field, so you can start typing right away. Search button is gone as well, simply hit Enter over the text field when done. To make it even more comfortable, package table will be focused after that to enable you to pick the packages (change their status) without the need of further keypresses. And, as a small bonus, you will see how many packages has been found:




Extended search modes

In ncurses, it has always been possible to search for packages in "contains substring" mode (using C++'s find() string builtin) only, while Qt offered much broader options. Now you can additionaly search for exact match, or even using regular expressions, or wildcards in ncurses, too.



Making it all work code-wise was simply a piece of cake, due to new libzypp application layer API, or PoolQuery if you want to. Big thanks to Jniq and Michael Andres for implementing it.

Installation Summary (aka Filtering packages by status)

Again, there has been no ncurses equivalent of Qt's installation summary (a view that shows packages which status has changed e.g. which have been marked for installation/update/deletion in this session). Additionaly, in this view user can select from the different package statuses only those s/he is interested in (s/he may, for example, to choose to display only installed packages, i.e. those whose status is set to Keep). So here we go with text-mode version of the same:



And that's all, folks. Let's hope together for better user experience in openSUSE 11.1 (and SLES11) even for those who live in console-world only :-) Of course, should you have any suggestions and ideas for improvement, don't hesistate to send in a patch :-D Or at least, poke me in bugzilla