All 13 entries tagged Suse

openSUSE 10.3 metareview

So a few days now since openSUSE 10.3 release. I reviewed the reviews of 10.3 that my RSS feed agregator has accumulated in the last 5 days. The results somewhat surprised me as I thought we had addressed the most common complaints with 10.2 and previous versions of openSUSE. Also reviews of the pre-releases had seemed very positive. The reviews were divided as follows:

Bad: 11
Neutral: 2
Good: 2
Invalid*: 4

• Simply re-pastes or rehashes of Novell/openSUSE press release.

Not including reviews published by openSUSE community members.

The good news is that it seems we are competing on technical merit again, The MS-Novell FUD has mostly been dropped.

Comments on news sites, IRC, and mailing lists seem considerably more favourable but are a more biased source.

Anyhow it seems we have an entirely new set of most frequent complaints for 10.3…

Most annoying issues [ Going by reviews ]

1: Installation issues caused by mirror infrastructure problems.

Hopefully will somewhat resolve itself as demand decreases, but clearly a problem that needs to be addressed.

2: Codec installation still too difficult.

I am at this point unsure how this can be improved:
– MP3 support installed is by default with dvd / cd + internet.
– Attempting to play codecs which arn’t available leads to page with instructions involving just a click to install. Perhaps need to monitor some users to see where this process is failing.

3: Enabling compiz too difficult.

It seems everyone expects compiz to be enabled by default nowadays, probably thanks to ubuntu enabling it by default in gutsy. In my opinion it is still not appropriate to enable by default as I’ve not seen any hardware on which it doesn’t cause instability with long periods of running (nvidia or ati). However, it seems most users don’t like having to find a checkbox to turn it on, and or experiment with whether AIGLX or XGL works best with their hardware.

4: Java crashes with gnome.

A conflict between gnome’s crash handler and java’s seems to be causing java applications to crash for gnome users. Fortunately this is not affecting KDE users.

5: No live-cd

This is a misconception – livecd with live-installer will be available in a few days once some critical bugs have been fixed. Although the traditional installer will still be more functional & more reliable.

6: Online repositories included by default during installation.

This was in response to user demand for easier network installs, and 1 cd install media while still having all the software they were used to installed by default. To not utilise the online repositories One simply has to uncheck a box. Not having it selected by default would break “click next” network installs, and mean that users of the 1cd install media would not have any of the features that many users want such as codecs, flash etc.

7: Unspecific performance complaints

Rarely substantiated with benchmarks or analysis it’s difficult to comment on this one. It is clear that in the average case 10.3 both boots faster and package management operates significantly faster. Perhaps people are comparing performance with beagle in suse to without beagle in another distribution, etc.

8: Too complex installer

Somewhat puzzling as the “click next” approach should work completely, now that we have separate KDE & GNOME media. Sure removing functionality from the installer is possible, but would break use cases. Some things can be made friendlier, but as long as you can click next repeatedly you should at least get a working system, and if you need to customise the install you have full control over the procedure.

What can we do about these?

(1) Will improve as the mirror infrastructure load decreases, and as improvements are made to the redirector, It’s a shame it has given some people a bad impression at release, hopefully it will mature quickly.
(2) Could be improved for 10.3 if the problem is with http://software.opensuse.org/codecs design, or the YMP composition etc.
(3) Could perhaps be improved for 10.3 by additional packages which can be easily installed, but we obviously can’t go back and enable it by default.
(4) Should be fixed by an online update first.
(5) Should be partly fixed when the livecd is released, although I’m skeptical about the maturity of the livecd installer, it might cause more problems.
(6) I think this is just a case of “you can’t please everyone” and we did pick the right default for 10.3. Users do want most of the software that is installed, people still complain that the entire double-dvd worth of software is not included on the 1cd. Also network install difficulty was a big complaint in the past, which is now a non-issue. Hopefully this will be complained about less when (1) is improved.
(7) Not really anything that can be done about this one except optimisations where specific problems are obvious or reported.
(8) Not something that can be fixed for 10.3

Anyway, try it out for yourself and let us know what can be improved on the mailing lists ( http://lists.opensuse.org ) and on bugzilla ( http://bugzilla.novell.com ).

: 09 Oct 2007 03:21 |  Tags: Opensuse Suse |  Comments (9) |  Close comments |  Report a problem

Package Manager + WebServices = ?

One of the things it would be nice to do in future versions of openSUSE (after 10.3) is connect the package management user interface up to webservices such as the openSUSE buildservice api , my package search api , or the software portal api once it is ready.

This would enable users to find and install software whether or not they have previously subscribed their package manager to the relevant repository. Potentially in the event of a dependency resolution failure a webservice could also be used to attempt to find a solution.

This evening I knocked up a quick functional demo YaST module which talks both to the local system package management, and the package search api. This screenshot shows it with search results for “tux” from:

• The local system rpm database
• The package manager’s repository cache
• Webpin search results

and actually installing a package.

This took about 1 hour from conception to the screenshot above. With a little time some quite exciting features could be developed utilising webservices.

The main challenges to making use of webservices from client like this are:

• Defining the API carefully enough so it can remain constant for the lifetime of the product.

• Hosting to cope with the potentially large number of requests arising from integrating web services with client-side software.

: 15 Aug 2007 01:52 |  Tags: Opensuse Suse |  Comments (0) |  Close comments |  Report a problem

YCP syntax highlighting for kate

Most people see YaST [0] as an application used for configuring the operating system. Relatively few people know that it is a development platform with its own language, libraries, and user interface abstraction layer that enables the developer to write a configuration module that will display using Qt when run in KDE, GTK when run in GNOME, ncurses when run on the command line. [1]

Although there are very nice features of the YaST platform, there are also disadvantages. YCP (The language most [2] YaST modules are written in is quite archaic in some respects, and there is limited library support. Also as YCP is only used by YaST there is little tool support for developing in it. In an effort to make developing in YCP a little easier for the remainder of its lifetime I wrote some kate-part (Used by kwrite,kate,kdevelop,konqueror etc) syntax highlighting rules for the YCP language. Screenshots: Here -> and here .

To use them simply save http://bw.uwcs.co.uk/kateycp/ycp.xml in ~/.kde/share/apps/katepart/syntax or `kde-config—prefix`/share/apps/katepart/syntax for all users.

It should be possible to create some kdevelop templates for YaST projects, and possibly even a tool for automatically generating the framework for common modules such as wizards.

[0] http://en.opensuse.org/YaST

[1] http://forgeftp.novell.com/yast/doc/SL10.2/tdg/id_big_architecture.html

[2] Yes modules can be written in Perl too, and now Ruby. At present the user interface components must be written using YCP though. Also I personally dislike Perl and Ruby more than YCP.

: 28 Jul 2007 19:28 |  Tags: Suse Yast |  Comments (1) |  Close comments |  Report a problem

First week of freedom

Last week I finished my work placement year, and I am now back to being a Student \o/. After losing a couple of days failing to move due to the flooding here in Britain, I have begun catching up on all the things I have had too little time to complete over the past few weeks.

I have spent quite a bit of time re-writing the YaST based wizard I for simple software installation from web pages. Although there are only minor changes to the user interface. It is now considerably more powerful.

The XML format used for the single click install has been discussed over the past few weeks and is now nearly finalised, it should now be potentially usable by other distributions too.

Amongst other improvements it is now possible to:

- Have one “install now” link that will work for multiple distributions & versions.
- Have translatable descriptions/summaries etc.
- Install patterns
- Have conflict resolutions specified in the xml format.

The user interface has been simplified somewhat and there is now better reporting of installation status / errors.

Hopefully the new version will find its way into one of the next openSUSE 10.3 alpha or beta1.

Implementing this was an interesting challenge due to limitations in the YaST platform. Particularly challenging was parsing non-trivial XML and communicating between multiple instances of YaST (One running a limited user, one running as root). The latter was required as we do not want to request root privileges until the user has been able to review the changes that will be made to his or her system.

Next week I am off on holiday, hopefully the rain might stop for at least some of the week.

: 28 Jul 2007 19:06 |  Tags: Suse |  Comments (1) |  Close comments |  Report a problem

Hackweek & Software Portal

Last week I was privileged to be invited with some other community members to join in Novell hackweek with the SUSE engineers in Nürnberg. During hackweek all the Novell engineers had an entire week to work on whatever projects they wished. You can see some of these at http://idea.opensuse.org

Some of the projects I found most interesting were:

http://idea.opensuse.org/content/ideas/yast-as-a-webservice
http://idea.opensuse.org/content/ideas/add-a-buildservice-project-that-recompiles-debian-packages
http://idea.opensuse.org/content/ideas/laptop-access-panel

I had a fantastic time during the week, meeting and discussing with many of the people who work at SUSE in Nürnberg, and some of the YaST team from Prague.

It turned out, there were so many people to speak to that I found there was surprisingly little time to actually write code. With the time I did have I worked on the software portal during the week.

For those who are unaware of this project the aim is to index the available metadata from package repositories and other sources, and to marry that trawled content with user-supplied content such as tags, screenshots, comments, improved descriptions etc.

As of the end of hackweek the following were functional to some degree:

• Importing of application details from package repository metadata & buildservice api
• Manual adding/editing of application details
• Tagging
• Rating
• Screenshots & thumbnailing
• Commenting

See screenshot

Special thanks to Andreas Jaeger and Ralf Flaxa for making our visit possible, and to Adrian Adrian Schröter and Martin Lasarsch and so many others for giving up their time to show us around and look after us during the week.

: 02 Jul 2007 20:28 |  Tags: Hackweek Opensuse Suse |  Comments (0) |  Close comments |  Report a problem

Speeding up package management.

Package management enables users to easily install software while the package manager handles locating and downloading all the dependencies of the software. Software itself is stored in so called “Package Repositories” which typically consist of:

- The software packages themselves
- MetaData

The metadata lets the package manager know what software exists within the repository and information about each piece of software. Such as which other packages an individual package depends on, along with descriptions and package contents.

In RPM based distros the rpm-md (rpm metadata) metadata format is becoming fairly standard, although there are many other formats.

When the package manager is to be used it must (either manually or automatically) check whether any of the available repositories have been updated. If they have been updated it must update its local cache of the repository metadata so that it knows the correct locations of packages. This update operation can be slow (especially for dial-up users) as the metadata for a large repository can be quite large, particularly with the rpm-md format of [binary] xml. For example the main openSUSE repository has 55mb of compressed rpm-md metadata, and that’s with the source and non-free packages stripped out.

This slow repository refresh operation becomes most annoying when the package manager is dealing with largish repositories which change frequently, such as the online update repository, packman repository, and guru repositories for SUSE. For example: Last night the guru repository was updated with a half-dozen new packages. This would mean a 1.7mb download of metadata for all users subscribed to this repository so that their package manager knows that these 6 new packages are there.

Most of the data downloaded in each refresh is often redundant, the package manager must re-download it all to know that 99.9% of the packages are exactly the same as they were last time it checked. Clearly it would be preferable to only download the differences in metadata. Various solutions have been considered. Duncan is looking at zsync which looks very interesting. Intrigued at how much improvement users might see from metadata diffs I thought I’d investigate the potential gains.

Using last night’s guru metadata change as an example I wrote a simple utility to read the xml and create a new xml file containing those packages which were added, and those which were deleted in the last update. This turned out to be trivial as rpm-md identifies each package by its checksum. The result:

Complete metadata (currently downloaded on each update: 1.7mb total
Differences to last metadata (in same xml format): 5.4kb total.

Time to refresh on dialup would decrease from about 5 mins, to less than a second.

The time to refresh a repository would be proportional to the number of changes, rather than the size of the repository.

Diffs would either have to be maintained on the server from every revision of the package repository to the current revision, or just have a new diff created on each update from the previous version and the client side could chain the diffs together to work out the cumulative changes.

Unfortunately this method would not be beneficial to repositories where everything changes at once (e.g. factory, build service KDE). Zsync should provide a better all-purpose solution. This experiment has enlightened me as to the potential benefits of metadata diffing though.

The input and output files, and code used Please note this was only written to investigate the potential gains and is not suitable for actual use.

There are also other simpler ways that the amount of data downloaded can be reduced.

- Reduce data downloaded

Much of the data such as the package changelogs is irrelevant to the package management operation and few users are likely to need to view changelogs of packages which are not yet installed.

- Include metadata on the install media

The metadata for the static repositories could be shipped along with the install media, so the user doesn’t have to download 50mb of data at the end of the installation process.

: 18 May 2007 21:46 |  Tags: Opensuse Suse |  Comments (1) |  Close comments |  Report a problem

Another simple software install demo.

Writing about web page http://benjiweber.co.uk/installdemo/

I have created some example link buttons to trigger software installation from a web page.

e.g.: .

And set up a demo page with 3 working examples people can use to try out the concept. See http://benjiweber.co.uk/installdemo/ for the demo page. If you’re on openSUSE give it a try and let me know your comments & ideas. You’ll need to install the demo package as per instructions on the demo page.

If you have installed it correctly you should be able to click one of the links and get a wizard like this which will add the required repositor(y|ies) and install the software for you.

There are also the “Install now” links on the testing package search page which are automatically generated, and should work the same way.

You can also try out the package search YaST client which allows you to use the package search from within YaST, and select any package on any repository for installation with the aforementioned wizard. Simply run ”/sbin/YaST2 PackageSearch” after installing the package linked from the installdemo page.

: 06 May 2007 00:17 |  Tags: Metapackage Opensuse Suse Webpin |  Comments (19) |  Close comments |  Report a problem

More metapackage possibilities

Today I found some decent examples of how to use Wizards in ycp (for yast) and re-implemented the proof of concept meta-package handler I made a couple of months ago.

While I was at it I thought I could demo the possibility of triggering package install directly from a web page. To do this I added an “Install now” link to search results on a test webpin page which will trigger an install of the specified package via an association of the appropriate mime-type within the browser.

The end result is best illustrated with images one and two

The updated demo yast module

: 02 Feb 2007 03:07 |  Tags: Opensuse Suse |  Comments (0) |  Close comments |  Report a problem

Webpin; 10.2 release; and Community meeting.

Webpin

Today I updated my package search page to include openSUSE 10.2 repositories. I also modified the repository trawler to use the openSUSE buildservice api to locate repositories, and had it index all the valid 10.1 and 10.2 repositories in the build service.

This was quite straightforward as https://api.opensuse.org/source simply returns a list of repository names which can be easily converted to the appropriate URLs on http://software.opensuse.org/download/ .

Some Statistics:

There are now 221 valid 10.1 repositories indexed, and already 88 valid 10.2 repositories. Approximately 13,000 packages per architecture for 10.1. Only about 8100 packages per architecture built so far for 10.2 , but it was only released on Thursday. That translates to about 5 million files for 10.1, 3 million for 10.2.

openSUSE 10.2 release

As I mentioned above openSUSE 10.2 was released on Thursday, and it is looking like it could be one of the best SUSE releases to date. Few issues remain in the final release, and there are lots of user-visible improvements over previous versions. Some of these are shown in the screenshots page: http://en.opensuse.org/Screenshots/Screenshots_openSUSE_10.2 It is certainly a relief that pain of supporting users with 10.1 will soon be mostly over.

A tip to those installing 10.2, deselect the “Enterprise Software Management” pattern and select the “openSUSE Software Management” software pattern (pictured at http://en.opensuse.org/Image:Screeny102_software_patterns.jpg) during or after install. (The former pattern contains software that was partly responsible for many of the problems in 10.1, and still has issues: http://www.desktoplinux.com/articles/AT5310810296.html). I disagreed with the decision to leave it in the default install, and it looks like my fears were justified here.

Community meeting

With the release of 10.2 out of the way, now is an ideal time to start setting some goals and starting some projects for openSUSE 10.3 and beyond. To this end we have organised a community meeting to help increase community involvement in improving the distribution. This will be held in 1 week (Saturday 16th 18:00 GMT) in #opensuse-community on the freenode irc network, see announcement and explanation here: http://lists.opensuse.org/opensuse-announce/2006-12/msg00003.html

This is the first time anything like this has been attempted, so it would be great if as many people as possible could turn up. It gives you the opportunity to find out what is already going on, help brainstorm improvements to openSUSE, and perhaps even get involved yourself.

: 10 Dec 2006 00:20 |  Tags: Opensuse Suse |  Comments (2) |  Close comments |  Report a problem

Next generation package management.

Link to screenshots for the impatient.

It seems to me there are several generations of package management:

• 0th Generation – No package management, user must place individual files in the correct place on his/her system.

• 1st Generation – Software is packaged for easy installation on the target system, user can just extract/run the package and files are placed in the correct place, but there is no dependency checking. If something the programme requires to run is not available it will simply fail to work when run. Examples: old style windows installers, zip files, slackware packages.

• 2nd Generation – Builds on 1st Generation by adding dependency/prerequisite support, so user can know what prerequisites he/she must install in order to use the programme. Examples: MSI, dpkg, rpm.

• 3rd Generation – Builds on 2nd generation by adding automatic dependency resolution from software catalogues/sources/repositories. This means that if all the software & dependencies that the user might wish to install are available in the pre-configured repositories he/she can easily install anything. Examples: apt/smart/urpmi/yast sw management .

We seem to have remained at the same basic concept of 3rd generation package management for quite a while. However, there are a remaining issues that stop it from being as useful as it could be. Problems I see with 3rd generation package management:

• User has to learn how to use a package management frontend. Be it apt-get, synaptic, yast, smart, or whatever. The design of these interfaces vary in ease of use, but even the best designed may still seem foreign to windows users conditioned into double clicking an install file and clicking next repeatedly until done.

• The packages may not be in the standard preconfigured repositories. This can happen both for legal and practical reasons. Some software is not legal to distribute freely everywhere in the world, and no repository can contain all software in any case. In the situation where the software the user wishes to install is not available in the already configured repositories, he or she will have to locate the repository where the software is located, and then learn how to add it as a source to whichever package manager he/she is using. All of which is a lot of effort for someone who just wanted to install something.

So, how can we solve these issues?

Well one solution is to make use of some form of meta-package file which simply contains information about software, and the repositories where it can be located. On top of a 3rd generation package management system this could enable:

• Single click adding of software catalogues, without the user having to worry about where they are located, or how to add them.

• Single click installation of software, whether the repository the software is located in is currently configured in the user’s package manager.

Today I had some spare time so I knocked up a proof of concept for how this could work:

Using an xml file in a format like

With a YaST module to interpret the above, and a default association for the file type in my file manager/web browser I have a working proof of concept for easy package installation.

Here is an example file to install tuxsaver from packman

So the user sees a link to “install tuxsaver” on a website or otherwise obtains the above installation file. And decides he/she wishes to install it. User clicks the link, and the appropriate repository can be added and the appropriate packages installed.

Screenshots of this process.

Alternatively if no packages are specified for installation, the same file handler could act as an easy way to add additional package repositories to the package manager.

Example screenshot of this.

If the module were opened without a file as a parameter it could grab a regularly updated list of available software catalogues from a central location. Obviously repositories hosting packages with dubious legality could not be listed here. However it would enable a project such as packman which is in this situation to host a “Click here to add our project catalogue” link on their homepage, and a “Click here to add mp3 support to your SUSE Linux” etc.

Link to the ycp for this proof of concept.

I think a proper implementation of this concept, included in the distro install by default would have potential to greatly simplify the package management experience for users.

A few issues were raised while I was looking at this which will need addressing:

• de-duping repositories.
  There is no sense in a user having the same package repository added to their package management system twice. My demo will only re-add a repository if the same URL hasn’t already been added, but the same repository may have different URLs on different mirrors. There seems to be no unique repository identifier in rpm-md repositories. One possibility is using the md5sum of one of the metadata files, but this would require making several checks, and ensuring the repository metadata is synced before the process can start.

• Security issues.
  This demo gets for free the security warning from YaST when adding an untrusted repository. It is likely a more clear warning will be required of both the security and technological issues that can be caused by installing random software.

Clearly the format of the meta-package file would need to be thought about carefully. What information does it need to contain, can it be bundled with packages to allow third parties to distribute RPMs which depend on packages in other people’s repositories.

Hopefully this demo might explain the concept better than my previous attempts, and might inspire some real improvements in user experience in future distributions.

: 04 Dec 2006 19:05 |  Tags: Management Opensuse Package Suse |  Comments (7) |  Close comments |  Report a problem