Home Home
Sign up | Login

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

Author Archive

How developers see openSUSE

February 19th, 2009 by

You probably know that a lot of openSUSE developers are sitting in the SUSE office in Prague, Czech Republic. They are also openSUSE users.

The whole story started by a flame on a mailing list why some of us are not happy with the current state of openSUSE. It turned out there is a lot of different issues. So, we’ve met on a raining winter Friday 3 weeks ago to collect those issues as well as things that people consider to be good about openSUSE.

The result of the hours-long discussion is a list of positive and negative things about openSUSE, very subjective view of the group of developers in Prague. Go, look at the list. There is a lot of problems that I personally see lurking in our community, spelled out loud. The range is wide, from basic community issues to very technical problems that are basically missing features in the distribution.

So, we have collected the feedback. But the question is, what to do with it?

Firstly, I believe the lists are great food for thought. You might not agree with everything, but still, there is some truth in it. At least, those are problems that people consider important enough to try to solve them – encouraging.

Secondly, consider this blog as call for contribution. If you believe some of the areas are really worth improving, get in touch with people listed on the wiki, improve the description  in the wiki, propose solutions. One restriction though – please, do not add additional items to the page. We want to keep the ideas where they belong – features eventually to end up in openFate, project-related problems on the mailing lists, …Also, this is not a general list of issues the openSUSE project needs to address. As I’ve written above – the page is a subjective view of a group of people. If you think we need a more general approach, please, bring the idea on openSUSE mailing lists.

Looking forward to your feedback!

Do You Want Multiple Kernels on Your System?

February 3rd, 2009 by

Today, I’d like to mention another rather hidden feature of openSUSE 11.1. The package management is finally able to keep multiple versions of packages, if they support installation of parallel versions. A typical example of this is of course kernel. A lot of people want to keep the old, functional, kernel around when installing a kernel update and now there is a way to do it.

Open /etc/zypp/zypp.conf in your favorite editor and change this value:

multiversion = kernel-default,kernel-default-extra,kernel-default-base,kernel-source

The list contains names of packages to be installed via ‘rpm -i’ instead of ‘rpm -U’. Just adopt it to your the kernel flavor you are using.

Of course, there is a catch – there are no means to limit the number of package versions to be installed this way. The reasoning is that there is no automatic way to guess which versions to remove (in case of kernel, everyone has its own definition of working kernel) So you have to uninstall additional kernels you don’t need anymore manually.

Enjoy!

Webpin search in YaST for openSUSE 11.1

January 9th, 2009 by

This is just a short reminder that in openSUSE 11.1, it is possible to search online for packages in YaST as described in this blog (thanks to Lukas and Bubli for making this reality!).

In short, just type on command line:

/sbin/yast2 webpin_package_search

and you will get this UI for an online search and install of packages:

Webpin Search in YaST

Enjoy!

Integration of YaST Server Modules to YaST System Services

January 8th, 2009 by

Today, I’ve played a bit with an idea to allow starting of YaST Server module from the YaST System Services module.

YaST System Services (Runlevel) Editor

The only visible difference is the additional “Configure…’ button at the bottom of the dialog. This button would be active only if there is a YaST module associated with the entry. After clicking it, the respective YaST module would be started:

YaST Firewall module invoked from YaST System Services module

With this simple principle, the YaST control center ‘Network Services’ section would be reduced to:

YaST Control Center, Network Services section

And all those YaST modules would be available from ‘System’ section:

YaST Control Center, System section

This approach could be used even further. You can see that the ‘Network Services’ section contents do not really match the section name anymore. In fact, most of the items could be moved to other modules as well. E.g. introducing a module for authentication/authorization, which would cover Kerberos client, LDAP client, etc. The NFS client is in fact a part of the new Disk Partitioning module already. So, the section could vaporize completely.

However, there are drawbacks. The biggest one I see is a ‘starting point’ problem. Just imagine you want to have a Apache2 running in your system. Until now, the YaST HTTP module is installed and can be used to bootstrap your configuration – it will install the packages and help to set up the basics. But with the new approach, the apache2 package is not installed, therefore System Services module would not see the apache2 service (init script) and does not show it at all! I’m not sure how to address this. Maybe the best would be to attach the YaST  module to apache2 package or HTTP server pattern and the Software Management module would become such starting point. Would it be better? I don’t know.

Then, there is an issue of a quick access – if you are moderately experienced user, you know what you are looking for and you start a proper module right away. But to figure out what is the configuration starting point if it’s hidden in another module, that might be a blocker.

I’m sure there are more problems. Anyway, I find the idea quite useful for reducing the number of YaST modules. What do you think?

YaST releases independent of openSUSE releases?

November 7th, 2008 by

YaST is one of the cornerstones of openSUSE. It is developed for openSUSE and is released as part of openSUSE. There never was a release of YaST independent of openSUSE. Even the versioning of YaST is tied to openSUSE – the versions are 2.X.Y, where X is increased for every openSUSE release (17 for 11.1) and Y is simply a patch level, whenever a new fix or feature is added. Even more, every YaST package has its own versioning, so the only way to ensure you have a consistent set of YaST packages is via dependencies set in the .spec file of the YaST packages.

But in principle, YaST is a tool that can be used across distributions and there are people interested in this to happen. There are technical barriers to do releases independent of openSUSE (e.g. a lot of openSUSE-specific knowledge and behavior coded in YaST) as well as procedural. During past years, a lot of these non-technical issues has been addressed as we opened up the YaST development (re-licensing the code under GPL, opening up source control system and mailing lists, etc).

But still, there is one big thing left: YaST packages are released in concert with openSUSE. Yes, it is very convenient for openSUSE, but it makes it almost impossible to track the development during for people outside of our great distribution.

If one looks at the way the YaST packages are updated during the hotphase of an openSUSE release, the core parts of YaST (yast2-devtools, yast2-core, libyui, …) are rarely updated, they get a bug fix here and there. However, the distribution specific parts (yast2-pkg-bindings, yast2 common libraries, bootloader, storage, networking, …) get a fast flow of patch-level releases, typically several between openSUSE milestones.

Thus, the way forward I like the most right now is a compromise: a core YaST system should be released independently of the openSUSE release cycle while specific modules could keep their crescendo during openSUSE hot phase. How to do that?

For core YaST packages (a list to be defined) would be released independently of openSUSE and during hot phase, they would be handled the way other FOSS parts of openSUSE are – by patching the code in the package. The rest of the YaST, current practice would stay untouched.

There are clearly advantages – the YaST developers can do a proper release management of the core code and it is much more predictable how the core part of YaST will be released. On the other hand, people would need to be aware of the split.

However, I can imagine there is a lot of I did not realize. I’m definitely interested in comments about this topic.

Unifying Progress During Installation – Continued…

September 3rd, 2008 by

So, my code from the hackweek is now in the YaST Subversion and the packages submitted for build.

Now the fun part begins, as some YaST developers noticed very quickly. There are several parts of YaST that got broken – e.g. YaST Partitioner on the running system spotted by Arvin, or sw_single not really adapted spotted by Bubli, …

Thanks to those I’m working with Kobliha to fix the issues as they come. So, if there is a progress in YaST (typically related to package installation) that does not behave as expected, it is certainly worth a bug report.

Unifying Progress During Installation

August 27th, 2008 by

This might not be that useful, but it’s fun.

If you look at the openSUSE installer during the time it’s busy, you can see at least 4 types of progress bars shown:

  1. Disk preparation
  2. Image deployment
  3. Additional package installation
  4. Writing final configuration before reboot

My goal for this hackweek is to unify them as much as possible. So, now I have something to show. The prototype works on openSUSE 11.0 Alpha2 and unifies steps 1-3. Here is a screenshot:

Installer deploying images, switched to the details view