All 15 entries tagged Opensuse
View all 27 entries tagged Opensuse on Warwick Blogs | View entries tagged Opensuse at Technorati | There are no images tagged Opensuse on this blog
February 05, 2008
One of the strengths of openSUSE is that configuration tools written using the YaST platform do not have to be re-written to fit within a different desktop environment. For example here is the same printer configuration dialogue being drawn using the Qt/GTK and ncurses user interface toolkits.
If this configuration tool had been written as a KDE application it would appear out of place on GNOME, and if it were written as a GNOME application it would appear out of place in KDE.
The user interface for the One Click Install handler was implemented using YaST, which meant that GNOME users could benefit from it without having to depend on a KDE application KDE , GNOME . In other distributions new features may be focused on one particular desktop, and users of another desktop, may be left to wait until someone ports the features.
It also helps to allow the desktop teams to focus on working on KDE or GNOME rather than only writing and fixing configuration tools.
While this is a great strength, it is perhaps simultaneously a great weakness. Most other distributions which are targetted at end users have a default desktop environment, for example:
- Ubuntu: GNOME
- Debian: GNOME
- Red Hat: GNOME
- Mandriva: KDE
- PCLOS: KDE
- Freespire: KDE
etc.. (no need to list them all)
This is all very sensible, quite apart from allowing them to focus their development resource, it also allows them to market the distribution as a complete product. Take the main product description page for ubuntu for example , they are able to give a flavour of what the product looks and feels like because they recognise that the desktop environment is part of the product, perhaps the most important part. It also means users can install from an ubuntu install cd without having to understand what a desktop environment is. It also allows them to arrange deals to install the product on OEM machines.
Historically SUSE Linux was much the same as these others, the default desktop environment was KDE, there were personal and professional boxed sets of the SUSE Linux operating system. There was also an enterprise version SLD . SUSE Linux built up a significant userbase, primarily of KDE users. Even now, as of last count there are 70% KDE users vs 20% GNOME . These historical users being the most experienced, are perhaps the most likely to get involved with openSUSE development.
Since the Novell purchase of SUSE political pressures, presumably partly from ex-ximian people, led to the switch of the enterprise desktop product to GNOME as the default desktop environment. The thinking, apparently, was that SUSE’s niche as a great KDE based OS was insufficient and there was a better chance competing against Red Hat directly by copying exactly what Red Hat were doing.
After this the openSUSE default desktop was also changed, but not to GNOME, instead to have no default at all. Instead, users are now presented with a confusing step during installation , during which they have to choose which desktop environment they wish to use (Or an equally confusing download page if using 1cd install) . This is an impossible choice to make for someone who does not know what a desktop environment is, and the politically correct descriptive text does nothing to help. (Efforts have been made to improve the descriptions of the desktop environments shown during installation, and to show previews of each desktop, but these do not really solve any problems, only slightly alleviates them.)
This has the following implications:
- The potential userbase is limited to those few who know what a “desktop environment” is.
Others won’t even get over the installation hurdle.
- Reviewers assume the de-facto default desktop environment is GNOME.
As it is the default for the enterprise version, and also listed first. Consequently the poor quality GNOME desktop leads to bad reviews.
- openSUSE can’t be marketed as a product, just a collection of packages and choices.
- openSUSE can’t be installed on OEM systems without someone picking a desktop or forcing choice on users at first boot.
- openSUSE is relegated from being a product to simply a playground for testing packages.
Quotes from the GNOME team such as “If you want a stable system, there’s SLED”, in addition to frequently broken GNOME packages in openSUSE releases would seem to support this view. SLED is the only remaining desktop product.
- openSUSE quality decreases, can only be used by those who can fix the problems themselves.
- Novell have more to develop and support as openSUSE and SLE diverge.
Many desktop features were added first to SLED10, and then moved to openSUSE. Development ends up having to be done twice, once on the enterprise products, and then on openSUSE. The more the codebases diverge the more work there is to support security & bugfix updates on both openSUSE and SLE products.
- Only people who are interested in developing a distribution aimed at a geek niche will contribute to openSUSE.
None of which is good for the future of SUSE.
In my not-so humble opinion this situation is untenable, yet I can’t forsee any change. The de-facto SUSE Linux / openSUSE desktop has always been KDE by the user and developer base. Choosing GNOME would mean a loss of users/contributors as staunch KDE advocates move on. It possibly also means attracting few users as other distributors such as Red Hat/Fedora and Debian or Ubuntu already do much better jobs of shipping a GNOME desktop. Going back to KDE is unlikely to happen due to internal Novell politics & pressure from ex-ximian people. So most likely the situation will stay as it is now, with use slowly declining due to the problems above.
While some people have been complaining in recent weeks about kubuntu being a second class citizen to ubuntu, I see this as one of its greatest strengths. The alternative is like with openSUSE, the whole distribution ends up becoming the “second citizen”.
February 02, 2008
I’ve noticed a trend of people hot-linking ‘One-Click-Install’ YMP files directly from http://software.opensuse.org on their blogs and news stories. While it’s great that people are including these it is worth considering whether it would be wise to take a copy of the YMP file and host it yourselves, or on openSUSE wiki, or somewhere else which can host static content.
If your web-host doesn’t understand the YMP mimetype a link directly to a YMP file will not work, you can work around this using “data:” URLs by creating a link as follows:
<a href="data:text/x-suse-ymu,http://example.com/mysoftware.ymp">My Install Link</a>
The install links on http://software.opensuse.org/search are:
- Subject to deletion/renaming at any time.
If you blog including a link taken directly from there then other people may simply copy it onto their blog/news site, and if the original disappears, or you need to make a change you end up with lots of broken or outdated links everywhere, even if you update your blog.
If someone points out a problem (need another package included, or a conflicting package removed, etc, then there’s no way to fix it. Additionally the YMPs generated by the buildservice are fairly inflexible at present as they are auto-generated from patterns. You might wish to alter it in a way not supported by the build-service.
Hotlinking is most likely to lead to headaches when the YMPs are complex, and frequently changing. Like the “install KDE4” links for example.
Hopefully that should help inform so as to enable you to make a decision as to whether to hotlink or copy the YMP.
Some people have commented on the lack of public progress on the Software Portal Project so I suppose I should blog about it.
The goal of the project is to make it easy for users to locate and install software.
Some distributions are shipping with simplified application installers now (Such as Ubuntu’s “Add/Remove Applications”), these abstract away from the detail of packages and display only applications to the user. So, for example a package such as kdenetwork may contain multiple applications (kopete, knewsticker, ... ) and other applications such as amarok may be composed of multiple packages (amarok, amarok-xine, ...). The simplified installers therefore only show the applications themselves: amarok, kopete, knewsticker.
The software portal combines automatic detection of applications from package repository metadata, with user generated content. So it can import metadata from the main distribution repositories, buildservice repositories, packman, etc, and then detect applications which will then be browsable by the users. Users can submit new applications, and edit existing ones where the autodetection was not perfect. Users can attach screenshots, tags, comments etc to existing applications. Users will be able to install applications using a one click install link.
So how much is complete? We announced the project 9 months or so ago, progress has been slow as all those involved have been busy. Nevertheless there has been tangible progress.
Here are some screenshots
Now that Pascal has added support for users and roles all the core components are in place. Now it’s a case of Features features features. At some point we need to decide what features are necessary for an initial release.
I hope this has enlightened some as to what the software portal project is about, let us know if you have any suggestions or comments. There is a mailing list . Help is even more welcome than comments ;)
October 31, 2007
I was prompted by a bug report to look at the progress reporting employed by YaST whenever the package management is used. At present separate popup windows are used to indicate progress/activity for reading each repository cache, and any downloads etc.
This makes the UI look rather busy & distracting. It also can cause problems for people using some window managers which fail at stopping the progress dialogues from stealing focus. This behaviour is one of the most frequent complaints now.
Additionally there is no global progress indication, which means people have no real idea how long the operation will take to complete. And for people on dialup it could be fairly slow.
I had a poke to see how difficult it would be to embed the progress reporting into the main window, and show global progress. It turned out to be relatively easy.
I’ll upload the source when I’ve refined the design a bit and make it work alongside the existing progress callbacks to avoid breaking everything else currently using them.
October 17, 2007
My openSUSE 10.3 box arrived today :)
The box has two dual-layer DVDs with all the software available in the online repository, and the startup manual in printed form.
October 16, 2007
I spent some time rewriting the backend for my package search over the weekend to
a) Improve indexing efficiency
b) Improve search result accuracy
Many of the repositories the search indexes change frequently, especially factory & packman. Updates to the index were starting to take unacceptably long, when indexing now about 208,000 packages, their descriptions & filelists.
With a few improvements such as skipping package details & files from packages which are unchanged after a repository update, redesigning the table/index structure. The indexer is now far faster and less i/o intensive when performing incremental updates. This should mean I can keep the search index more up to date, and be less annoying to other users of the server.
I also spent some time analysing the search queries, and used what I learnt to enable full search of the files within a package. Previously only a rough comparison to the filenames was made. Now you can even search for a full filename, like /opt/kde3/bin/kopete . Normal queries such as konversation or kde irc client will still work.
I made a few other small improvements too, e.g. filenames with binary matches will be ranked higher, so searches for something like kopete are a bit more useful, finding /opt/kde3/bin/kopete
The next thing on webpin TODO, after fixing all the problems that arise from these changes, is to make some frequently requested improvements to the web frontend, such as adding Install Now links to each search result. And perhaps alter the theme to fit with the new openSUSE-community theme .
If you prefer the command line to a web browser, check out yaloki’s command line client
October 09, 2007
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:
- 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
August 15, 2007
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.
July 02, 2007
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:
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
- Screenshots & thumbnailing
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.
May 18, 2007
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
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.