openSUSE 11.0 KDE4 inclusion

There seems to be a lot of misconceptions regarding the inclusion of KDE4 in openSUSE 11.0 that are leading to a great deal of anger on the mailing list.

KDE4.0 is the default in openSUSE 11.0. It is being forced upon users.

Not true. Both KDE3.5 and KDE4.0 (and GNOME) are offered when installing from the DVD or netinstall. There is no default. The KDE4.0 description is

KDE 4.0 is the most recent evolution of KDE. It comes with many new KDE technologies, but is less mature than the other desktops.

While KDE3 is described as

KDE 3.5 is the previous generation of the K Desktop Environment. It is mature and stable.

which I personally think is a fairly good description. This is only shown on new installs, if a user is upgrading an existing installation then he or she will remain with his or her existing desktop. Users are not forced or even suggested to change from KDE3 to KDE4.

Novell forced the inclusion of KDE4.0 was forced upon the openSUSE community for [insert conspiracy reason here]

There have been dozens of “Novell did not listen to the users” comments which are wrong for several reasons.

The topic was discussed at length in various media which are all open to everyone.

• Bugzilla
• IRC Project Meeting , and at the KDE team meetings too.
• Project mailing list, here, and several other threads.

The result of these discussions is what we have in openSUSE 11.0. They were not ignored, in fact they led to the inclusion of the KDE3 option clearly in the installer.

The second problem with these statements is they assume that everything that happens in openSUSE is a direct result of Novell policy. The openSUSE community is made up of many people including many who work for Novell. The decision to include KDE4.0 was made by the community and particularly the KDE team. There is no evidence that there was a Novell policy that KDE4.0 must be included in openSUSE 11.0. In fact, the descision was delayed until as late as possible when it could be made on technical merit.

KDE4 should not be included until it is ready.

How do you define ready? KDE4.0 is already ready for some users. Whether it is ready for you depends upon what featureset you use. I will not be switching myself until certain features are implemented.

There are good reasons to begin the move to KDE4.0 early.

• People can move over when KDE4 is ready for them.
• openSUSE specific tools and integrations can be ported to KDE4 gradually.

So far this process is something like this.

• openSUSE 10.3 : KDE3 the only prominent option in the installer. KDE4 was available for testing. The openSUSE tools are KDE3 based.
• openSUSE 11.0 : KDE3 and KDE4 are both prominent options in the installer, with a warning that 4.0 is not mature. Updater applet has been ported to KDE4. YaST has a Qt4 UI.
• Future : KDE3 may be dropped when KDE4 is good enough to replace KDE3 for the vast majority of users.

The current state of KDE4 migration is available on the wiki

There is no point filing bug reports against KDE4 because the developers know what is wrong with it.

• Few people will have exactly the same configuration as you, or use the same featureset, so will not run into the same bugs/missing features.
• Both upstream bug tracker, and the openSUSE bug tracker allow you to search for duplicate bug/enhancement reports before you file. You can find out for yourself whether anyone else has reported your issue.

This argument just seems to be “I’m too lazy to report issues, but quite willing to rant about them instead.”

Including KDE4.0 will lead to bad reviews.

This might happen. However, so far reviewer’s quibbles have been with entirely different issues. In fact there have been several positive reviews of the openSUSE shipped KDE 4.0.

There should be a KDE3.5 installable livecd.

This was not produced as there were insufficient resources to produce and test three installable livecds. Someone can always step up and help produce one.

Summary

• openSUSE is not forcing people to switch to KDE4. Users can switch to KDE4 when they wish. Both are included on openSUSE 11.0.
• If you find bugs in or are missing functionality in KDE4 please file bug reports so it can be fixed.
• If you have an opinion regarding when the timescale for moving to KDE4 you are free to get involved and influence the decisions. You do not have to resort to insulting developers on the mailing lists to be heard, in fact insulting developers so is a good way to ensure that people disregard your opinion.

: 24 Jun 2008 18:43 |  Tags: Kde4 Opensuse |  Comments (19) |  Close comments |  Report a problem

Upgrading openSUSE 10.3 –> 11.0 in a running system.

Upgrading openSUSE between releases while the system is running is not a currently supported method of upgrading. The supported method is to boot from an install medium and select the upgrade option. Nevertheless, it is possible to upgrade a running system. This is more difficult than normal with openSUSE 10.3 -> openSUSE 11.0 due to the change in RPM payload format from bz2 -> lzma which makes the RPM in 10.3 unable to install RPMs from 11.0.

Method

1. Upgrade RPM to the version in 11.0
2. Install the full package management stack from 11.0
3. Upgrade all packages.

Stages

The specific steps required to upgrade using the above method may vary from system to system, these are just those that I needed.

• Disable all the repositories I was using on 10.3.

  mv /etc/zypp/repos.d /etc/zypp/repos.d.old    

• Delete the repository cache.

  rm /var/cache/zypp/zypp.db        

• Add the main openSUSE 11.0 repository.

  zypper ar http://download.opensuse.org/distribution/11.0/repo/oss openSUSE110    

• Install the new RPM from openSUSE 11.0.

On 64bit:

rpm -Uhv 'http://download.opensuse.org/distribution/11.0/repo/oss/suse/x86_64/rpm-4.4.2-199.1.x86_64.rpm'

Or if you are on 32 bit:

rpm -Uhv 'http://download.opensuse.org/distribution/11.0/repo/oss/suse/i586/rpm-4.4.2-199.1.i586.rpm'

• Install the 11.0 package management stack.

  zypper in zypper    

• Add the 11.0 version of the nonoss and packman repositories, as I have several packages installed from these.

  zypper ar http://download.opensuse.org/distribution/11.0/repo/non-oss openSUSE110_NonFree
  zypper ar http://packman.iu-bremen.de/suse/11.0/ packman    

• Upgrade all packages. At this point I had to confirm several package vendor changes and removal of a few obsolete packages.

  zypper ref
  zypper dup    

• Reboot

Problems

I had only two significant problems after upgrading. Both turned out to be down to my having edited configuration files, so they were not automatically overwritten with the updated configuration files.

• Networkmanager would immediately disconnect after connecting. This turned out to be down to a stale dhclient configuration file. I solved this with:

  mv ./dhclient.conf.rpmnew ./dhclient.conf    

• openSUSE updater could not find any backends. This turned out to be down to a stale zypp configuration file. I solved this with:

  mv /etc/zypp/zypp.conf.rpmnew /etc/zypp/zypp.conf    

Since lack of a new configuration files can cause breakage in unexpected places it would be nice to offer users the chance of replacing or merging their configuration file changes, rather than requiring users to know about these files and merge them manually.

: 24 Jun 2008 13:49 |  Tags: Opensuse |  Comments (42) |  Close comments |  Report a problem

Cycle Paths

To people who do not do much road cycling, cycle paths may seem like a good idea. Keep cyclists and cars separated and offer some protection to cyclists. It sounds like a good idea in theory. However, in practice, cycle paths are one of the most dangerous hazards to cyclists. Occasionally, one does see a well designed cycle path, but these examples are very rare. The majority of cycle paths are terrible examples of road design.

Of course one is not obligated to use a cycle path, and many, knowing the hazards common to cycle paths, avoid them completely. The problem with this is that some ignorant car drivers and even law enforcement officers take issue with cyclists not making use of the available cycle path facilities. People need to be more aware of the dangers of cycle paths, and that by asking cyclists to use them you are endangering their lives.

I will outline a few of the most dangerous problems with cycle paths here to illustrate some of the problems.

There are three main classifications of cycle paths.

1: Separate but alongside the road.
2: Part of the road
3: A completely different route to the road.

The third kind of cycle path has no particularly dangerous problems, other than frequently being unmaintained and taking longer routes than the road. These paths are also quite rare. The most common are the first two. Let us first consider the kind of cycle path which is alongside a road but separated from the road by a curb. These paths are often shared with pedestrians, even if they are not supposed to be.

The first major problem with this type of cycle path is that the cyclist no longer has priority over side roads and driveways. This means that in an urban environment the cyclist would have to stop, cross, start every few metres. In addition to this the visibility the cyclist has of hazards emerging from side roads is greatly diminished.

When riding on the road the cyclist both has priority and is moving with the traffic. Accidents are most likely to occur when turning or crossing through traffic, something these cycle paths make cyclists do continuously.

Another problem with these cycle paths is that cars will turn left into the side roads, something the cyclist has little visibility of and cannot prevent. While riding on the road the cyclist can be aware of cars wishing to turn left and move out from the curb slightly to discourage drivers from cutting across their path.

Another problem with these cycle paths is that they are often supposed to be bidirectional, but insufficient room is left. Furthermore, pedestrians often use them (sometimes this is encouraged by signs). Mixing pedestrians and cyclists is a bad idea, pedestrians often move into the path of cyclists at the last minute by mistake. Also, in a 30mph limit a cyclist travelling at 20mph is closer to the speed of a car than a 3mph pedestrian, keeping objects of the same speed grouped is safer.

Another common problem is that the cycle paths are simply far too short. I have seen many which are stupidly short, some less than 5 metres, for which I have no explanation of what the designer was thinking. Even the longest cycle paths are rarely longer than a mile or so. When cycling at 20mph there’s really no point leaving the road and dealing with additional hazards only to have to rejoin it very shortly. Rejoining the road is often dangerous, the cyclist must merge with a stream of moving fast traffic. Often the point at which the cycle path rejoins the road comes with no warning and is at a point of road with particularly poor visibility, such as after a bend.

The other common type of cycle path is where a section of the road is marked off as being a cycle path. This is significantly better than the separated cycle paths as it only suffers from some of the above problems. The cyclist has priority over side roads and is moving with the traffic. However, there are other problems with these cycle paths.

The first is that they are often full of static hazards. They are typically located at the sides of roads and not very wide. Sunken drain covers often occupy nearly the entire width, forcing the cyclist to swerve in and out of the cycle path, in and out of the flow of traffic. Car drivers also seem to think that these cycle paths are synonymous with car parks, also forcing cyclists to continuously swerve in and out of the cycle paths.

Of course these hazards would exist whether or not the edge of the road was designated a cycle path. The problem is that the cycle path encourages cyclists to stay at the edge of the road as long as possible and swerve late. Whereas the safest course is to move out as soon as an obstacle becomes visible, making your intention clear to car drivers. Unfortunately in an urban environment this means there’s little opportunity to actually enter the cycle path at all.

Another problem I have observed with these cycle paths is that they encourage car drivers to encroach from side roads. They seem to think that a cycle path is an extension of the side road. Of course this encroaching is often necessary for the driver to get better visibility or get out at all in busy conditions. However, I have observed when a cycle path is present the driver is much more likely to use it when it is not necessary. Even though the cycle path is part of the road the emerging drivers believe they have priority over the cyclists.

Another problem with these cycle paths is that the encourage filtering past static or slow traffic on the left. Car passengers habitually open car doors into this space without checking the mirrors. Cars will also move left into the cycle path space to avoid hazards or to turn left. Drivers are also far less conscientious about checking their left hand mirrors than their right hand mirrors, as other than cyclists there’s unlikely to be anything there. These reasons make it much safer to pass static traffic on the right hand side, down the middle of the road. While this might seem scary it also offers the cyclist a better view of the road, there is usually also more space available in the centre of the road.

There are lots more problems with cycle paths, such as them being unmaintained and covered in glass, These are just the main hazards that mean that using a cycle path greatly increases the risk of a collision.

There are of course some well designed cycle paths that do not suffer from these flaws, but these are so rare that unless you know a cycle path well you’re better off avoiding it in case it’s dangerous.

A better solution than cycle paths everywhere would be to make the roads wider instead of adding poorly designed cycle paths that assume you the designer knows better than the cyclists and drivers who actually know the road and conditions. Wider roads allow drivers to pass cyclists with ease and cyclists to ride safely. As for cyclists who crawl along at 5mph they could just be allowed to use the pavements.

The best tactics for avoiding collisions in an urban environment are to cycle fast and cycle wide. Cycle fast and you’re closer to the speed of the traffic, which gives drivers more time to react and less urgency to pass. Cycle wide and you’re more visible, moving out to avoid potential hazards when passing side roads or rounding tight bends which reduce visibility. It’s important to not stay wide when unnecessary though, and to allow cars to pass whenever safe.

A common car driver complaint is that with the cyclists on the road, often cycling wide it’s difficult to pass them. There seems to be some hostility between car drivers and cyclists, car drivers thinking they have more right to use the roads than cyclists. It’s worth bearing in mind that if all the cyclists were not cycling but in cars they would be harder to pass, and be increasing the congestion and pollution on the roads. So the cyclists are in fact doing you a favour. Most cyclists are probably car drivers as well so also contributing to the upkeep of the roads.

If a cyclist is riding too wide for you to pass he or she will probably let you past at a convenient time. Unobstructed by glass and a big metal cage the cyclist has a much better view of the road surface and overall road conditions than you do.

With a little mutual respect everyone can stay safer. Please stop building cycle paths without consulting cyclists, and please don’t get angry when cyclists prefer to stay alive and do not use them.

: 28 Apr 2008 12:11 |  Tags: Cycling |  Comments (35) |  Close comments |  Report a problem

openSUSE IRC – call for participation

The #suse channel on the freenode IRC (Internet Relay Chat) network is one of the places users can go to get support with openSUSE. The channel has suffered a little over recent months from the loss of some regular participants. Since the opening of the openSUSE project many of the channel regulars have become involved in other areas of the openSUSE project, leaving less time for user support on IRC.

While the regular participants may have decreased, the throughput of users seeking help shows no sign of abating. There is a danger that with fewer people helping in the channel, users will either not get help or be put off by the attitude of a few in the channel.

There are regular complaints from a few about the state of the #suse IRC channel, often as an excuse for not participating. This does somewhat irritate me as it is one of the easiest things to fix yourself. Simply join the channel and participate, even a single person does make a big difference to the whole channel. Complaining helps nobody, and only serves to discourage those who are helping

So please join us in #suse. Help, be helped, and have a lot of fun! If you are using openSUSE You can probably just click here to join the channel .

Reasons for being in #suse

• Improve end user support

#suse is one of the places users may look for help. It is linked on http://help.opensuse.org, from the desktop, and the openSUSE IRC clients default to joining the channel. IRC, being interactive, gives the opportunity to arrive at a problem diagnosis much more quickly than possible with a mailing list. It also has the disadvantage that no-one may be available or able to answer your question. It supplements the other support fora such as mailing lists & web forums.

• Improve channel atmosphere

#suse, along with the mailing lists and forums, is one of the parts of the community that new users will come into contact with. Their experience here may dictate whether they continue using the distribution or not, or whether they participate in the project or not. If users do not get their problems solved they may be forced to look elsewhere. If users have a bad experience in the channel, they may be discouraged and look for another community. It is therefore critical that we provide the best possible experience for users in the channel. This is not a policy problem (we have rules and guidelines), but a people problem. The people in the channel define its atmosphere and quality.

• Learn new things about openSUSE

Even if you think you are a suse expert, you will likely be surprised at the things you will learn by simply watching other people helping in the channel. This will then help you to help others in the future.

• Get your questions answered

Nobody is an expert in all areas, in addition to helping others you can have your own questions answered as well.

• Get to know other openSUSE users.

IRC provides interactive chat. With IRC it is possible to socialise and live the suse motto “Have a lot of fun” much more than is possible with other media such as mailing lists.

• Learn what the user painpoints are.

If you are involved in the openSUSE project, being in #suse gives a special insight into the most common problems users experience. It helps make the problems that need to be addressed in the future clear.

Possible reasons for not joining #suse

• I don’t like the channel atmosphere / I’ve heard it’s unfriendly

An IRC channel is simply a venue. The atmosphere of the channel is defined by those who are in it and active at any given time. Since there is rarely more than a handful of people active at any time, if you are speaking in the channel then you are pretty much defining the atmosphere. Improving the channel friendliness is simply a matter of joining and occasionally talking. If you encounter someone in the channel being antisocial or in violation of one of the channel rules, then contact one of the ops [/msg susehelp ops], who can then take appropriate action.

• The channel is too busy. I don’t have time to spend in #suse

Just being in the channel does not obligate you to talk, help, or even read it. Most of those in the channel will be doing other things, occasionally glancing at the channel. If they happen to see something they can help with they will. If there are enough people doing this then it translates into quite good support coverage, and not much of a timesink.

• I don’t know enough to help others

This is rarely true. Not all questions are of equal difficulty. At least half of user questions are frequently asked questions which can usually be resolved by supplying a bot factoid or URL. As they are frequently asked you will see others answering these questions after spending a little time in the channel, you can then immediately start helping answer these questions in the future by repeating the solution. Of the more difficult questions, there is a scale of difficulty. If you have used openSUSE for any length of time you will probably be surprised how many questions you will be able to answer.

: 26 Mar 2008 12:13 |  Tags: IRC Opensuse |  Comments (3) |  Close comments |  Report a problem

Interactive Firewalls?

openSUSE comes with a firewall (SuSEfirewall2) which is enabled by default on desktop installation and drops all incoming traffic. There are often discussions as to whether this is a good thing or not, with strong opinions on either side. I won’t get into those.

The problem for users is that some things such as

• Samba share browsing
• File sharing
• Remote access
• Avahi

will fail to work, often silently. Some people just assume that the function is broken. A fewer think to disable the firewall and try again. Still fewer are able to open just the ports they require open in the firewall. One of the most frequently asked questions on IRC is why samba browsing does not work.

Obviously simply having the firewall disabled by default for internal networks would solve the problem. However, this is an unpopular option amongst some, and if the firewall is enabled it should still be possible to help the user know what to do.

I knocked up a little proof of concept application which

• Watches events in the firewall log
• Matches those events against predefined suggestions
• Proposes relevant suggestions to the user.
• If user approves, will open ports automatically using YaST

So, for example, if the user is trying to set up a webserver and the firewall is blocking access to it, it will suggest opening port 80.

Or if the user tries to browse samba shares and the firewall blocks the responses it will suggest opening high ports to allow these responses to get back.

More screenshots here

What do people think about this idea? Does anyone know of any other similar projects for interactive firewalls on linux? Mandriva has “mandi” but this seems more geared towards being an interactive fail2ban than offering suggestions.

My little demo source code is available if anyone is interested.

: 24 Mar 2008 14:34 |  Tags: Firewall Opensuse |  Comments (24) |  Close comments |  Report a problem

One–Click–Install improvements

I fixed a few bugs/wishes in the openSUSE “one click install” handler last week.

Amongst potentially interesting changes are

• Addition of command line support as I previously mentioned

• Tidied up the UI a little removed the somewhat cryptic “advanced mode” checkbox in favour of an editable proposal, as used elsewhere in YaST.

• Don’t show this again support for nag warning

Clicking customise gives the equivalent of the old advanced mode

Click here to install on 10.3

: 24 Mar 2008 14:27 |  Tags: One-Click-Install Opensuse |  Comments (7) |  Close comments |  Report a problem

Easier YMP Creation

Some people have requested a GUI for creating YMP (One Click Install) files (It seems some people have an aversion to XML) .This is something I had looked at in the past, but decided that it the resulting UI would be at least as complex as the generated XML.

I had another go at this today, and the resulting form really doesn’t seem to be much easier to use than writing the XML manually.

All you save is typing out the tags, which an XML editor would help you with anyway.

Perhaps a better approach for simple YMPs would be to convert user selections within the package management into a one click install file.

YaST software management (at least the Qt version) does provide a mechanism to export user selections to a file:

Which generates a file like

[Update]             MozillaSunbird                 |   21.0 M   | 0.7-6.3          | 0.7-6.3         
[Install]            MozillaSunbird-debuginfo       |    5.7 M   | 0.7-6.3          | ---             
[Install]            MozillaSunbird-translations    |   11.6 M   | 0.7-6.3          | ---             

It might be possible to convert this file into a YMP automatically, which would make generating simple YMPs easy. I might have a go at this sometime. However, it will not help creating complex YMPs with support for multiple distributions/versions, and translations.

Does anyone have any other suggestions for approaches to ease creation of YMP files for one click install links?

: 26 Feb 2008 21:14 |  Tags: Opensuse |  Comments (1) |  Close comments |  Report a problem

Third party updates

James since your blog doesn’t appear to support comments I’ll stoop to “discussion by blog”.

You state that third party repositories are not considered by the updater tools (YaST Online Update,Updater applet, zypper). This is not really true. In fact, by default the tools will only notify you of updates that are patches (higher priority than newer versions of packages). These patches could be in any repository, in practice they are only used in the official update repository. There is some more information about how patches are specified on the wiki .

Now, while only these “patches” are considered important enough to notify the user of, and apply automatically, other repositories are considered while performing the updates. This means that in the case of a new kernel patch being released which is incompatable with the currently installed nvidia driver, the kernel patch will not be installed until there are updated nvidia drivers available in the nvidia repository that will work with the new kernel. Once there is a new nvidia driver available the update will install and will pull in the updated nvidia driver from the other repository as a dependency automatically. The same should happen with madwifi, though they were quite slow in making new drivers available for the recent kernel updates, if it does not then it’s probably a packaging issue. There is more information about kernel module dependencies in this paper.

Furthermore, if you wish to be notified of new versions of packages in any repository, as well as patches, you can be. Simply tick the “Show upgrades” tickbox in the updater.

You can also do this with zypper

zypper up -t package

(That’s a literal “package” , not a package name)

This is not enabled by default as just because a user has a repository available in his or her package manager it does not mean that he or she necessarily wishes to install newer versions of packages just because they are there. For example packman repository has had problematic alsa upgrades in the not too distant past, which most people do not want. There is also the issue of “vendor bouncing” where a newer version of a package becomes available in one repository, and then in another, and so on. There are other ways to resolve that though, such as vendor sticky (Assuming the user wishes to stay with upgrades & updates from the same vendor, unless he or she specifically installs one from another vendor).

: 19 Feb 2008 20:13 |  Tags: Opensuse |  Comments (3) |  Close comments |  Report a problem

Command–Not–Found on openSUSE

Ubuntu ships with a programme called command-not-found which will suggest a package to install when the user types a command at the terminal which can’t be found. It seems this makes use of a hook called command_not_found_handler() which is not available in SUSE.

Pavol Rusnak is working on porting this programme to openSUSE, so it might be available for 11.0. But is it possible to get this behaviour on a vanilla openSUSE 10.3 without installing any other packages?

It does seem possible to do something hacky to get such behaviour:

export PROMPT_COMMAND='
if [ $? -eq 127 ]; then 
    history -a; 
    COMMAND=$(tail -n 1 $HISTFILE); 
    SQL="SELECT name from resolvables WHERE id IN (SELECT resolvable_id FROM named_capabilities WHERE name_id IN (SELECT id FROM names WHERE name LIKE \"$COMMAND\")) LIMIT 1;" 
    PACKAGE=$(echo $SQL | sqlite3 /var/cache/zypp/zypp.db); 
    PACKAGE=${PACKAGE:="-"};
    if [ $PACKAGE != "-" ]; then 
    echo $COMMAND is not installed\; Try \"sudo zypper install $PACKAGE\" to install it.; 
    fi; 
fi'

Then you get similar behaviour:

benji@lcars:~> kopete
bash: kopete: command not found
kopete is not installed; Try "sudo zypper install kdenetwork3-InstantMessenger" to install it.

benji@lcars:~> amarok
bash: /usr/bin/amarok: No such file or directory
amarok is not installed; Try "sudo zypper install amarok" to install it.

benji@lcars:~> nothingprovidesthis
bash: nothingprovidesthis: command not found

benji@lcars:~>

However, the whole adding command to history and then re-reading seems like a really bad idea. Possibly a security hole if someone adds something malicious to .bash_history so it’s probably not a good idea to use this ^_. If anyone knows how to get the previous command in a better way please let me know. “fc” will return it, but not until after PROMPT_COMMAND has been executed it seems.

It also assumes that anything with exit status 127 is a command not found, which is probably not always true.

Also it doesn’t seem to work in other shells that are not bash.

Any better way to do this without command_not_found_handler() ?

: 11 Feb 2008 14:41 |  Tags: Command-Not-Found Opensuse |  Comments (2) |  Close comments |  Report a problem

One Click Install links from the command line.

I get asked occasionally whether it is possible to install some software from a “one click install” link from the command line. Well now it is.

I’m not entirely sure what peoples’ usecase for this is, but up until now the only answer has been to download the .ymp file, read it and follow the instructions manually.

Fortunately the one click install handler is implemented using YaST, and YaST not only makes it easy to make your interfaces display with Qt/GTK/Ncurses⁰, but also to add command line interfaces.

Several YaST modules already have command line interfaces. For example try running

  yast2 lan help

This made it quite easy to add command line support to the one click install handler.

Here’s a screenshot of it in action:

There is no support for doing anything interactive, like selecting optional software yet, but it should be functional.

If you want to try it out on openSUSE 10.3 simply

1. Copy http://bw.uwcs.co.uk/OCI/CLI/OneClickInstallCLI.ycp to /usr/share/YaST2/clients
2. Copy http://bw.uwcs.co.uk/OCI/CLI/OCICLI to somewhere in your $PATH.
3. Then run

     OCICLI <url>    

I need to remove some duplication of code with the existing graphical handler before committing to SVN, but it should be possible to include in future openSUSE versions if people want it.

[0] There’s a bug with the version in 10.3 that prevents it from functioning in ncurses mode, this should be fixed before 11.0

: 09 Feb 2008 21:27 |  Tags: Opensuse |  Comments (4) |  Close comments |  Report a problem