Home Home
Sign up | Login

Author Archive

Cloudy with a touch of Green

March 19th, 2014 by

Finally there is some news regarding our public cloud presence and openSUSE 13.1. We now have openSUSE 13.1 images published in Amazon EC2, Google Compute Engine, and Windows Azure.

Well, that’s the announcement, but would make for a rather short blog. Thus, let me talk a bit about how this all works and speculate a bit why we’ve not been all that good with getting stuff out into the public cloud.

Let me start with the speculation part, i.e. hindrances in getting openSUSE images published. In general to get anything into a public cloud one has to have an account. This implies that you hand over your credit card number to the cloud provider and they charge you for the resources you use. Resources in the public cloud are anything and everything that has something to do with data. Compute resources, i.e. the size of an instance w.r.t. memory and number of CPUs are priced differently. Sending data across the network to and from your instances incurs network charges and of course storing stuff in the cloud is not free either. Thus, while anyone can put an image into the cloud and publish it, this service costs the person money, granted not necessarily a lot, but it is a monthly recurring out of pocket expense.

Then there always appears to be the “official” apprehension, meaning if person X publishes an openSUSE image from her/his account what makes it “official”. Well first we have the problem that the “official” stamp is really just an imaginary hurdle. An image that gets published by me is no more or less “official” than any other images. I am after all not the release manager or have any of my fingers in the openSUSE release in any way. I do have access to the SUSE accounts and can publish from there and I guess that makes the images “official”. But please do not get any ideas about “official” images, they do not exist.

Last but not least there is a technical hurdle. Building images in OBS is not necessarily for the faint of heart. Additionally there is a bunch of other stuff that goes along with cloud images. Once you have one it still has to get into the cloud of choice, which requires tools etc.

That’s enough speculation as to why or why not it may have taken us a bit longer than others, and just for the record we did have openSUSE 12.1 and openSUSE 12.2 images in Amazon. With that lets talk about what is going on.

We have a project in OBS now, actually it has been there for a while, Cloud:Images that is intended to be used to build openSUSE cloud images. The GCE image that is public and the Amazon image that is public both came from this project. The Azure image that is currently public is one built with SUSE Studio but will at some point also stem from the Cloud:Images OBS project.

Each cloud framework has it’s own set of tools. The tools are separated into two categories, initialization tools and command line tools. The initialization tools are tools that reside inside the image and these are generally services that interact with the cloud framework. For example cloud-init is such an initialization tool and it is used in OpenStack images, Amazon images, and Windows Azure images. The command line tools let you interact with the cloud framework to start and stop instances for example. All these tools get built in the Cloud:Tools project in OBS. From there you can install the command line tools into your system and interact with the cloud framework they support. I am also trying to get all these tools into openSUSE:Factory to make things a bit easier for image building and cloud interaction come 13.2.

With this lets take a brief closer look at each framework, in alphabetical order no favoritism here.

Amazon EC2

An openSUSE 13.1 image is available in all regions, the AMI (Amazon Machine Image) IDs are as follows:

sa-east-1 => ami-2101a23c
ap-northeast-1 => ami-bde999bc
ap-southeast-2 => ami-b165fc8b
ap-southeast-1 => ami-e2e7b6b0
eu-west-1 => ami-7110ec06
us-west-1 => ami-44ae9101
us-west-2 => ami-f0402ec0
us-east-1 => ami-ff0e0696

These images use cloud-init as opposed to the “suse-ami-tools” that has been used previously and is no longer available in OBS. The cloud-init package is developed in launchpad and was started by the Canonical folks. Unfortunately to contribute you have to sign the Canonical Contributor Agreement (CCA). If you do not want to sign it or cannot sign it for company reasons you can still send stuff to the package and I’ll try and get the stuff integrated upstream. For the interaction with Amazon we have the aws-cli package. The “aws” command line client supersedes all the ec2-*-tools and is an integrated package that can interact with all Amazon services, not just EC2. It is well documented fully open source and hosted on github. The aws-cli package replaces the previously maintained ec2-api-tools package which I have removed from OBS.

Google Compute Engine

In GCE things work by name and the openSUSE 13.1 image is named opensuse131-20140227 and is available in all regions. Google images use a number of tools for initialization, google-daemon and google-startup-scripts. All the Google specific tools are in the Cloud:Tools project. Interaction with GCE is handled with two commands, gcutil and gsutil, both provided by the google-cloud-sdk package. As the name suggests google-cloud-sdk has the goal to unify the various Google tools, same basic idea as aws-cli, and Google is working on the unification. Unfortunately they have decided to do this on their own and there is no public project for google-cloud-sdk which makes contributing a bit difficult to say the least. The gsutil code is hosted on github, thus at least contributing to gsutil is straight forward. Both utilities, gsutil for storage and gcutil for interacting with GCE are well documented.

In GCE we also were able to stand up openSUSE mirrors. These have been integrated into our mirrorbrain infrastructure and are already being used quite heavily. The infrastructure team is taking care of the monitoring and maintenance and that deserves a big THANK YOU from my side. The nice thing about hosting the mirrors in GCE is that when you run an openSUSE instance in GCE you will not have to pay for network charges to pull your updated packages and things are really fast as the update server is located in the same data center as your instance.

Windows Azure

As mentioned previously the current image we have in Azure is based on a build from SUSE Studio. It does not yet contain cloud-init and only has WALinuxAgent integrated. This implies that processing of user data is not possible in the image. User data processing requires cloud-init and I just put the finishing touches on cloud-init this week. Anyway, the image in Azure works just fine, and I have no time line when we might replace it with an image that contains cloud-init in addition to WALinuxAgent.

Interacting with Azure is a bit more cumbersome than with the other cloud frameworks. Well, let me qualify this with, if you want packages. The Azure command line tools are implemented using nodejs and are integrated into the npm nodejs package system. Thus, you can use npm to install everything you need. The nodejs implementation provides a bit of a problem in that we hardly have a nodejs infrastructure in the project. I have started packaging the dependencies, but there is a large number and thus this will take a while. Who would ever implement….. but that’s a different topic.

That’s where we are today. There is plenty of work left to do. For example we should unify the “generic” OpenStack image in Cloud:Images with the HP specific one, the HP cloud is based on OpenStack, and also get an openSUSE image published in the HP cloud. There’s tons of packaging left to do for nodejs modules to support the azure-cli tool. It would be great if we could have openSUSE mirrors in EC2 and Azure to avoid network charges for those using openSUSE images in those clouds. This requires discussions with Amazon and Microsoft, basically we need to be able to run those services for free, which implies that both would become sponsors of our project just like Google has become a sponsor of our project by letting us run the openSUSE mirrors in GCE.

So if you are interested in cloud and public cloud stuff get involved, there is plenty of work and lots of opportunities. If you just want to use the images in the public cloud go ahead, that’s why they are there. If you want to build on the images we have in OBS and customize them in your own project feel free and use them as you see fit.

Goodbye EC2 Tools Long Live AWS Tools

February 26th, 2014 by

For quite some time we had a package named ec2-api-tools in the Cloud:EC2 project and I suspect many that work with EC2 had found the package and were using the ec2-* commands to manage stuff in EC2. Along with the ec2-api-tools Amazon maintained a separate ec2-* tool set for various services. Keeping up with the armada of Amazon developers is not easy and thus the other ec2-* tool sets never got packaged.

Now a new integrated set of tools is available called with the “aws” command and provided by the aws-cli package. The package is available from the Cloud:Tools project and a submit request to Factory is pending. The new package does not obsolete the ec2-api-tools package as there is no issue with having both packages installed. However, I did take the liberty to remove the ec2-api-tool package from the Cloud:EC2 project as it would no longer receive updates considering that we have a nice new tool that unifies all Amazon services. The documentation for the new command can be found .

The aws code is hosted on github and thus contribution of fixes is easy and that is another big plus over the ec2-* tool sets.

Yes, and of course we need to get openSUSE 13.1 into EC2, and I am working on that, stay tuned….

Some post-processing of oSC13

July 22nd, 2013 by

Well, oSC13 has come and gone and what a great event to look back on. Starting with the pre-registration party on Thursday night all the way to the end on Monday the program was jam packed with interesting talks and workshops. All sessions were well attended and some were hopelessly over flowing.

The millions of thank you’s directed toward Kostas and Stella, the driving forces for the organization, are probably not enough. In addition to having a great event we also had the opportunity to learn a lot about what it takes to pull off oSC. Until oSC13 a lot of knowledge about the oSC organization was locked up within SUSE as the primary driving force of the conference organization in previous years. The “locking up” of information was just something that happened due to the nature of the organization of previous conferences. Information inside companies just gets lost, that’s the nature of the beast and this is certainly not intentional. Additionally, at least for me, having the community organized event this year made me think more about what it takes to pull off the organization. I guess with SUSE standing behind the event not just as a sponsor, but also as the lead organizer, it somewhat made the individuals that worked on the organization anonymous. We certainly had great conferences previously and many of us like to think back and reminisce about previous events when we meet. Another point is probably that one thinks that many more resources are brought to bare when a company is behind the organization of an event, although that is not necessarily the case.

Having the community drive the organization for oSC13 is just a completely different feeling, and I think I am not alone with this sentiment. The people that were involved in the organization of previous conferences were always happy to help and share information, and some were intimately involved in pulling things together, thank you.

The knowledge accumulated will certainly spread through the community and a number of meetings and many discussions at oSC13 started this process already. During the live project meeting, a.k.a. Town Hall meeting, it was my pleasure to announce that oSC14 will take place in Dubrovnik in April 2014. Svebor, the lead for the oSC14 organization endured a number of brain dumps and got bombarded with ideas and suggestions.

This conference paves the way for oSC to grow as a community organized event and I know that Stella and Kostas had to swallow more lumps, as the prime movers, than others in the future will have to. Thank you.

With somewhere around 250 attendees we all can be very proud of the first community organized oSC. For impressions check out some pictures of oSC13 and the video recordings of the sessions. Now is also a good time to seriously start thinking about your travel plans for April 2014. See you in Dubrovnik

The Resourcefulness Of Our Great Community — An Example

June 18th, 2013 by

At the risk of stepping on other people’s toes let me apologize before I start. I am certain we have many members in the community that have gone out of their way to overcome hurdles placed in their way by our “organization” or others. I was inspired by this story because it shows how dedicated our community members are and it really fits well with some of the issues we are still struggling with in the transition from Boosters to SUSE team and the transition between initiatives, Ambassadors to Coordinators and shipping of DVDs to boxes of promo material for designated events.

Peter Czanik was caught in the middle of all of this at a recent FSF conference where he and others had an openSUSE booth. With no DVDs being shipped, due to the transition in the promo material shipping procedure (this has been announced) and no money available through TSP for local production of marketing materials due to a snafu (a temporary solution is in the works) there was basically no help from the resources where help should be coming from, sorry about that Peter.

Despite these obstacles Peter and the team showed up and made due with what was available to have great success. In Peter’s words:

“”"”
- distributed the last few remaining openSUSE 12.2 DVDs. Many people complained, that it’s not the latest and greatest, but also many were happy, as they have an old machine and older Linux versions usually have lower resource requirements.
- reused the posters we printed last autumn to decorate the booth (at the end of the day they were in a sorry state, so can’t be reused any more…)
- used the few remaining openSUSE brochures, stickers we printed last year (printing was contributed last year by somebody working at a printing company and our company printer…)

- used my ARM machines and a few borrowed mini PCs to demo openSUSE and make the booth eye catching (people asked about the machines and went away with openSUSE DVDs and brochures )

So, in short: last autumn we had local contributions from community members, this year we used what was last few bits of it and some creativity.

The good thing is, that I was told from multiple directions, that openSUSE had the best booth among software projects at the conference (and they did not know, that it was from a ZERO budget…).

The bad thing is, that we don’t have any marketing materials left. No DVDs, posters or brochures.

“”"”"

There is no need to rose color the situation, leaving community members trying to represent openSUSE at a conference stranded like this should not happen and there is no excuse for creating this situation in the first place. Work is proceeding to address these issue. However, I want to focus on the positive, and that is undoubtedly how determined Peter and the team were to make the conference a success and how they overcame the obstacles presented to them.

Thank you Peter and team fro being such dedicated representatives of our community and project. Also thank you for pointing out the shortcomings in our current transition period. This will allow us to address these, hopefully in short order.

As I mentioned, am am certain many of you have similar stories to tell. Thanks for your efforts as well.

One that got away – 12.3 Networking

March 13th, 2013 by

Well openSUSE 12.3 is about to go live  and we are all pretty excited. It is, as far as I can tell a rock solid release and we have outdone ourselves. Considering the short release cycle makes this even more impressive.

One can only thank everyone in the community for pulling together, getting a lot of stuff done and delivering a great release.

Yet, there’s one sprinkle that rains on our parade. While we completed the switch to systemd we somewhere along the lines forgot to check the status of NetworkManager on an installed system. Thus, when you upgrade from a previous release and NetworkManager is disabled, it will be enabled and running after the upgrade is complete, sorry. If you happen to be running a network bridge your bridge will not be working and you’ll end up in some weird network state where ifconfig will tell you that both your bridge and your Ethernet card have an IP address. Your routing table will also be messed up. Addressing the issue is easy.

Login as root, which you will have to do at the login manager if you happen to run NIS, disable NetworkManager, stop the NetworkManager service, and restart your network. You are now back to your original configuration, no sweat ;) . Below is a list of commands you want to run as the root user to make this happen:

# systemctl –force disable NetworkManager.service

# systemctl stop NetworkManager.service

# rcnetwork restart

We can do better

July 20th, 2012 by

Maybe it is just me, but lately it appears that there is a lot brewing on our lists. Generally I try to stay out of the fray, but of course we, as members of our community, are all in the middle of it in one way or another. With a very recent endless thread on the opensuse list fresh in memory, not that I read all or even most of the messages it generated, and the follow on thread of the original poster bidding his farewell to the list, supposedly because the poster didn’t like the responses, I feel compelled to share some of my own thoughts on the topic.

My feeling is that a good number of people that complain about the noise on our lists are also those that contribute to that noise at a good rate. Thus, I can only say that sometimes it is nice to exercise some restraint and not hit that “Send” button; who hasn’t had the “I shouldn’t have sent this” thought? The bottom line is, that it is almost impossible to write anything that does not step on somebody’s toes somewhere along the way and if everyone that feels the least bit uneasy about some comment would respond all the time we would really be in an endless loop. I am certain, this post will make someone uneasy, upset, angry or worse. If that’s the way you feel right now, I am sorry, I am not trying to make you angry or upset on purpose. Please accept my apology.

That said, who hasn’t been frustrated out of their mind by some perceived dumb software problem or other issue? Even worse when it is our own hurdle we cannot cross. In the end we just wanted to yell and scream and the result is too often a message with: pick your “Emotional state appropriate inflamatory subject…” and rant your question to the list. Everyone gets emotional, and frustration happens to be a very strong reaction. However, the question that should come to mind before hitting that “Send” button to a list of volunteers is this, “Will an emotional reaction with moaning, groaning, whining, and complaining, that hides the real problem, give me the feedback needed to resolve my issue?” The answer is simple; No it will not. A post charged with negative energy will, and there is plenty of proof on our lists, solicit emotional, mostly negative, responses. These do not contribute to resolving the problem at hand. However, once this storm is set in motion there is, for better or worse no stopping it and it just has to run its course, i.e. eventually people will be tired of feeding the storm that should have never happened and things will go back to “normal”, whatever that may be.

I believe that the people, volunteers, on the opensuse mailing lists are generally willing to help solve problems others encounter. Yes, there will be the occasional cynical remark here and there, but I do not believe these remarks are ushered in a mean spirited way, and in the end we do not really have to nit-pick everything to death. It is one thing to yell at someone because the product or service you purchased from them does not meet your expectations, it is another thing to go bananas on a list where answers are provided by people with generally good intentions that volunteer their time. As posters of questions we all have a responsibility to keep this in mind before we go down the emotionally charged road to the abyss of not getting our questions answered.

However, putting the onus completely on the question poster is a bit too easy, isn’t it. While we as helpers would all love to get the “perfect” problem description, that is completely factual and contains no mistakes in description and actions to reproduce the problem, we have to realize that this is just not going to happen. By the time an issue hits the list the person posting probably is charged up in one way or another and ready to get rid of some of that stored energy, some more than others. Thus, as helpers we have to develop a bit more tolerance and let things roll off our backs a bit more. As potential helper we can just ignore the ranting posters. If you have it within you to provide the answer to the hidden problem and can rise above the fray, fantastic! help and do a good deed. However, if you know the answer to the hidden problem but feel the urge to feed the emotional storm it may be best to just ignore the message and not respond. In the end a raging answer hides the kind deed of help just as the raging question hides the problem.

No we do not have to have boring and no fun lists, but in the end flame wars or endless bickering threads are not fun and having people leave the lists or even not using openSUSE because of silly things is just not helpful to anyone. If we as posters, seekers of answers and providers thereof can just tone it down a bit things will probably work better for everyone.

1-2-3 Cloud

June 20th, 2011 by

Towards the end of last year there was an article in openSUSE news “announcing” the cloud efforts in the openSUSE project and on OBS. Well, cloud is still all the rage (see Jos’ contribution to openSUSE News issue 180) and people just cannot stop talking about cloud computing.

Using openSUSE as a host for your cloud infrastructure is also making great progress. We have 3 cloud projects in OBS and hopefully these cover your favorite cloud infrastructure code, Virtualization:Cloud:Eucalyptus, Virtualization:Cloud:OpenNebula, and Virtualization:Cloud:OpenStack. The projects provide repositories for Eucalyptus, OpenNebula, and OpenStack, respectively.

We attempt to make it relatively easy to get a cloud up and running. In this process OpenNebula and OpenStack have progressed the most. Eucalyptus is working, but due to an issue with Eucalyptus and openSSL 1.0 and later (the version in openSUSE) automation has to wait until these issues are resolved.

For OpenNebula we now have a KIWI example that shows how one can get a cloud setup from scratch in less than 2 hours, including the image build. The example contains a firstboot workflow for the head node, and self configuration of cloud nodes.

For OpenStack SUSE Gallery images are in the works and will be published in the near future.

All repositories provide packages you can install on running openSUSE systems. If you are interested in using openSUSE as the underlying OS for your cloud or if you want to contribute to the cloud projects, subscribe to the cloud mailing list opensuse-cloud@opensuse.org

Wacom Bamboo Pen and openSUSE 11.3

September 23rd, 2010 by

It all started when my daughter discovered the Bamboo Pen. Naturally the tablet quickly turned into a must have accessory to her computer. After a bit of Googling I came to the conclusion that making the beast work with Linux should be possible. The prize for the effort would be a very happy young lady.

In order to avoid any potential hassle with shipping etc. we went to the local Best Buy to buy the tablet. As the store had the hardware at the same price as online retailers that decision was easy.

Once I actually had my fingers on the tablet it was time to make it work. Doing a bit more detailed research now, I found various openSUSE forum posts and various other links. Some of these were not quite consistent, others appeared to address only half the solution. Therefore, I decided to cast away most of what I had found and just concentrate on the information found on the Linux Wacom Project. The HOWTO is informative and provides all information needed to get everything working. The HOWTO does not provide the information in the linear fashion I like, when I try to get something new to work. With a bit of hoping back and forth and some pocking around I got the tablet to work.

Now to the linear summary on how to get the tablet working.

  • Install openSUSE 11.3
  • Install the necessary packages to build the code provided by the Wacom project (root access required)
    • kernel-source
    • kernel-syms
    • xorg-x11-server-sdk
    • plus make and standard build infrastructure
  • Get the sources from the Wacom download page (0.8.8 at the time of this writing). This is the kernel driver code. The included X utilities and driver code in this version will not work on openSUSE 11.3 and will not build either, that’s OK.
  • Get the X utils and driver code from the Wacom main page. The link at the time of this writing is near the top of the page and links to version 0.10.8
  • Build the kernel driver
    • Unpack the kernel driver code tar -xjvf linuxwacom-0.8.8-8.tar.bz2
    • cd linuxwacom-0.8.8-8
    • Configure the build ./configure --enable-wacom
    • Build the driver make
  • Copy the newly built driver over the driver supplied by the openSUSE kernel (root access required) cp src/2.6.30/wacom.ko /lib/modules/`uname -r`/kernel/drivers/input/tablet/
    • If you want to make a backup copy of the project provided driver make sure you store the copy outside of the modules tree, i.e. outside of /lib/modules/`uname -r`
  • Remove any updates for the driver rm /lib/modules/`uname -r`/weak-updates/updates/wacom.ko
  • Build the X11 utils and driver
    • Unpack the sources tar -xjvf xf86-input-wacom-0.10.8.tar.bz2
    • cd xf86-input-wacom-0.10.8
    • Configure the build ./configure
    • Build make
    • Install (root access required)make install
  • Create a udev rule (root access required)
    • With your favorite editor open /etc/udev/rules.d/60-wacom.rules
    • Add the following code
      # udev rules for wacom tablets.
      KERNEL!="event[0-9]*", GOTO="wacom_end"
      # Multiple interface support for stylus and touch devices.
      DRIVERS=="wacom", ATTRS{bInterfaceNumber}=="00", ENV{WACOM_TYPE}="stylus"
      DRIVERS=="wacom", ATTRS{bInterfaceNumber}=="01", ENV{WACOM_TYPE}="touch"
      # Convenience links for the common case of a single tablet. We could do just this:
      #ATTRS{idVendor}=="056a", SYMLINK+="input/wacom-$env{WACOM_TYPE}"
      # but for legacy reasons, we keep the input/wacom link as the generic stylus device.
      ATTRS{idVendor}=="056a", ENV{WACOM_TYPE}!="touch", SYMLINK+="input/wacom"
      ATTRS{idVendor}=="056a", ENV{WACOM_TYPE}=="touch", SYMLINK+="input/wacom-touch"
      # Check and repossess the device if a module other than the wacom one
      # is already bound to it.
      ATTRS{idVendor}=="056a", ACTION=="add", RUN+="check_driver wacom $devpath $env{ID_BUS}"
      LABEL="wacom_end"
  • Regenerate the module dependencies depmod -e

There you go, now you can connect the tablet, fire up GIMP and be creative.

Into the Cloud

March 29th, 2010 by

Setting up your own Cloud infrastructure on SUSE has just become a lot easier. You can now use Kiwi and a mostly pre-configured set-up to build your own Cloud node images. Once these images are built setting up your Cloud can be accomplished in a few minutes.

Checkout the Cloud Recipe in the Kiwi Cookbook.

Happy Hacking

Setting up a slide show screen saver in GNOME

March 10th, 2010 by

There are multiple options to set up a slide show screen saver that shows the pictures of your choosing when the screen saver kicks in. The following shows the various options and works with the gnome-screensaver.

Easy does it

The most direct way to get a slide show screen saver going is to place your pictures in the $HOME/Pictures directory, then start the GNOME screen saver settings dialog by using gnome-screensaver-preferences from the command line or by selecting the Screensaver icon in the Control Center (gnome-control-center). In the screen saver settings dialog select “Pictures folder” and click “Close”.

One step of customization (not the preferred option)

If you do not want to use the Pictures directory as the location for the pictures to be shown you can customize the location by making a few simple edits. As the root user edit the file /usr/share/applications/screensavers/personal-slideshow.desktop. At the end of the line that starts with “Exec” add “–location=PATH_TO_PICTURE_DIRECTORY”, without the quotes and with PATH_TO_PICTURE_DIRECTORY being a real path. For example if my pictures were in /opt/slideshow the modified line would look as follows:

Exec=/usr/lib/gnome-screensaver/gnome-screensaver/slideshow –location=/opt/slideshow

Save the file and select the “Pictures folder” in the screen saver preferences dialog to select the slide show as your screen saver.

While this is a straight forward modification this is not really a good solution. The reason being that this modifies a file that is part of a package and when the package gets updated you will loose your changes.

A second step of customization

The better solution to accomplish the task of customizing the picture location is to create a new .desktop file in /usr/share/applications/screensavers. You should use the personal-slideshow.desktop file as your starting point.

As root copy the personal-slideshow.desktop file to a file with a name of your choice, then edit the file. Change the value of “Name”, “Comment”, and add the “–location” option at the end of the “Exec” value as previously. Save the file and start the GNOME screen saver preferences dialog. In the list to the left search for the value you assigned to the “Name” variable when you edited the new .desktop file. Select it and your all set.

Getting fancy

If the animation of the pictures in the previous slide show setup is not sufficiently fancy for you, the GLSlideshow screen saver maybe the ticket for you. Unfortunately you cannot just simply configure the location of the images you would like to use in the GNOME screen saver preferences dialog or via command line arguments to the glslideshow screen saver. In order to configure the location of the images to be used it is necessary to run the xscreensaver settings dialog (don’t worry, in the end gnome-screensaver will be running again).

Just starting xscreensaver will fail as only one screen saver daemon per display is allowed. Therefore, it is necessary to first kill the gnome-screensaver; use the following commands:

-> ps -A | grep gnome-screens

At the beginning of the line this produces you will find a number, this is the process ID (PID). Use this number in the next command

-> kill -9 PID

Now fire up xscreensaver and select “Settings”. In the settings dialog select “GLSlideshow” and then switch to the “Advanced” tab. In the “Image Manipulation” frame select “Choose Random Image” and then enter the path of the directory containing your image files in the text box below the check button text. If you click the “Settings” button on the “Display Modes” tab you can set various parameters for the slide show.

With the slide show configured you can switch back to the GNOME screen saver if you so desire. In the settings dialog select File->Kill Daemon, then File->Quit. Now in a terminal window restart the GNOME screen saver by using the “gnome-screensaver” command. The process is a daemon and it will background itself. That’s it, now if you select the GLSlideshow in the GNOME screen saver preferences dialog you will see your images being selected.

With this you can have a slide show as your screen saver in no time.

Happy Hacking.