We are thrilled to announce the release of Banshee 2.0! It's the culmination of six months' work by 36 developers and dozens of translators, documenters, bug reporters, and testers. It is a stable release, the successor to Banshee 1.8.

New Features:

• Artist/Album Browser Track Actions
• Play After Queue Options
• Sleeker UI, Less Wasted Space
• Video Subtitle Support
• Lots of new devices supported
• Amazon Cloud Player download support
• Hundreds (277, to be exact) of bugs fixed, and dozens more minor enhancements!

View the release notes for much more information, or head straight to the download page.

The Banshee community has come a long way in the last six months.

• We now support Windows in addition to Linux and OS X. Our Windows installer has been downloaded by 12,729 unique IPs.
• We are donating $1,200 USD per month to the GNOME Foundation — that's over $15,000 annually, or 5% of GNOME's 2009 budget.
• And Ubuntu decided to make us their default music player, joining the ranks of openSUSE and Foresight Linux.

Congratulations and many thanks to everybody who made all this possible! If you want to learn more about Banshee, how you can contribute, get in touch, get help, etc, head over to our website.

The voting on how to do the versioning is over and the “old school” has won by 55 per cent (of 98 participants). Thanks to all that participated in the two votes and the discussion around the topic.

As Coolo said in on the project list,  we’d like to make a small change to the numbering:

We will not have a .0 release but only .1, .2, .3 release. Since we have releases in three months, the November
release is always the .1 release, the July release the .2 and the March release the .3.

So, the plan is that the next release will be called openSUSE 12.1 and launched on the 10th of November, 2011! Two years later – on the 14th of November, 2013 – we will then have the openSUSE 13.1 release.

So, the next four releases are called:

• November 2011: openSUSE 12.1
• July 2012: openSUSE 12.2
• March 2013: openSUSE 12.3
• November 2013: openSUSE 13.1

Detailed results for logged-in openSUSE members are available at the connect poll page and I have reproduced them here as well:

• A: “old school”: Like currently but only counting the right number until 3:
  55% (54 votes)
• B: “Fedora style”: Just integers:
  29 % (28 votes)
• C: “Ubuntu style”: YY.MM:
  16 % (16 votes)

This is also consistent with the results of the first public voting.

Note that openSUSE does not have a major and minor numbering, even if it seems so. There is right now no difference in any way between what we would do for openSUSE 11.4 or 12.0 or 12.1 – and no sense to speak about openSUSE 11 or openSUSE 11 family. We also had in the past no process on how to name the next release (when to increase which parts of the number).

I think this new versioning is still consistent with the old one but also an improvement since it’s now clear that we change the first digit every two year. The first poll showed that half of our users prefer a date based versioning and the other a consecutive numbering. So, depending on your point of view, you can see this as a mixture of both or as consecutive numbering

So, time now to make openSUSE 12.1 a great release!

Dear All


Well what can I say? 4 sales in on calendar week, and 2 sales to kick start April and this ain't no fool!!

Friday was an amazing day for Bolton Linux, 2 sales back to back took our sales to 4 for the week for the first time, all be it 2 on Wednesday and Two on Friday, it shows there is a market, and that it is growing.

To celebrate the launch of Gnome 3.0 (three point zero) Free Software UK are throwing a party in Manchester Next Sunday 10th April from 2pm till 5pm Bolton Linux will be giving a presentation on Gnome, Novel and openSUSE.

We would welcome everybody to join us.

This does mean that however, we will not be attending Sheffield market this month. Instead we will arrange for PC Centre North West to carry some stock on our behalf.

But I am sure you will all agree a party is better than hard slog at a market :)

Today we want to present the current development of snapper, a tool for managing btrfs snapshots.

For years we had the request to provide rollbacks for YaST and zypper but things never got far due to various technical problems. With the rise of btrfs snapshots we finally saw the possibility for a usable solution. The basic idea is to create a snapshot before and after running YaST or zypper, compare the two snapshots and finally provide a tool to revert the differences between the two snapshots. That was the birth of snapper. Soon the idea was extended to create hourly snapshots as a backup system against general user mistakes.

The tool is now in a state where you can play with it. On the other hand there is still room and time for modifications and new features.

Overview

We provide a command line tool and a YaST UI module. Here is a brief tour:

First we manually create a snapshot:

# snapper create --description "initial"

Running YaST automatically creates two snapshots:

# yast2 users

Now we can list our snapshots:

# snapper list
Type   | # | Pre # | Date                     | Cleanup  | Description
-------+---+-------+--------------------------+----------+-------------
single | 0 |       |                          |          | current
single | 1 |       | Wed Mar 30 14:52:17 2011 |          | initial
pre    | 2 |       | Wed Mar 30 14:57:10 2011 | number   | yast users
post   | 3 | 2     | Wed Mar 30 14:57:35 2011 | number   |
single | 4 |       | Wed Mar 30 15:00:01 2011 | timeline | timeline

Snapshot #0 always refers to the current system. Snapshot #2 and #3 were created by YaST. Snapshot #4 was created by an hourly cronjob.

Getting the list of modified files between to snapshots is easy:

# snapper diff 2 3
c... /etc/group
c... /etc/group.YaST2save
c... /etc/passwd
c... /etc/passwd.YaST2save
c... /etc/shadow
c... /etc/shadow.YaST2save
c... /etc/sysconfig/displaymanager
c... /var/tmp/kdecache-linux/icon-cache.kcache
c... /var/tmp/kdecache-linux/plasma_theme_openSUSEdefault.kcache

You can also compare a single file between two snapshots:

# snapper diff --file /etc/passwd 2 3
--- /snapshots/2/snapshot/etc/passwd    2011-03-30 14:41:45.943000001 +0200
+++ /snapshots/3/snapshot/etc/passwd    2011-03-30 14:57:33.916000003 +0200
@@ -22,3 +22,4 @@
 uucp:x:10:14:Unix-to-Unix CoPy system:/etc/uucp:/bin/bash
 wwwrun:x:30:8:WWW daemon apache:/var/lib/wwwrun:/bin/false
 linux:x:1000:100:linux:/home/linux:/bin/bash
+tux:x:1001:100:tux:/home/tux:/bin/bash

The main feature of course is to revert the changes between two snapshots:

# snapper rollback 2 3

Finally yast2-snapper provides a YaST UI for snapper.

Testing

Playing with snapper should only be done on test machines. Both btrfs and snapper are not finished and included known bugs. Here is a step-by-step manual for installing and configuring snapper for openSUSE 11.4.

Feedback

We would like to get feedback, esp. about general problems and further ideas. There are also tasks everybody can work on, e.g. the snapper wiki page or a man-page for snapper.

For the time being there is no dedicated mailing-list so just use opensuse-factory@opensuse.org.

Following the announcement of the Canterbury distribution, there has been a lot of work about this in the background too. In order to provide developers with the easiest framework to package with, we are pleased to announce the availability of the Canterbury Rolling Application Platform.

No more tedious packaging, upstream won't have to deal with the idiosyncrasies of distributions any more. Just write your source code, use our framework, and it will automagically be turned into a craplet, which is the new name for artifacts in our distributed platform. It will just fly!

Unlike all efforts of packaging and distribution, our approach is truly revolutionary and provides instant and effortless scalability for the cloud through virtualization of provisioning for horizontal and vertical growth of your business.

At the center of this revolutionary platform lies our secret sauce, Publish Organic in the Open, which will enable you to quickly push out your stuff into the wide world of users of the new Canterbury Rolling Application Platform.

aprfoo@feci.es$ make_poo --dist=loo LibreOpenOffice
Preparing upstream organic ... [DONE]
Building craplet loo.crap ... [DONE]
Flushing buffers ... [DONE]
Pushing to canterbury.org ... [DONE]
Finishing up. Congratulations, your CRAP is flying at the loo !

We are expecting big vendor support behind this effort, with HP, Oracle, IBM and probably also Microsoft, as it would only be a natural fit for their .NET platform.

It is obviously written in Python (significant whitespace fits in naturally with our philosophy) and will be available in git repositories soon.

Hello again,


I just did a quick update to GNOME 3 live image, to fix some issues people discovered in previous images :

• radeon / r600g openGL drivers have been switched to use gallium : they should be more stable with GNOME-Shell
• GNOME Control Center system information correctly detects graphics card on your system
• Empathy accounts panel is back in GNOME Control Center

As always, you can download it from http://gnome3.org/tryit.html. If you want to install this image on a system, just add "liveinstall" on the boot command line.

Enjoy !

Well Amazon has just blown ebay out of the water today I sold 2 boxes of 11.4, takes my tally to 24 now.. (10 copies of 11.4 and 14 of 11.3).

Amazon has now sold two copies although i can't figure why the price changes each time!

You know the drill, another week, another release.



Release team decided to do another call for tarballs to fix some bugs across the entire GNOME3 platform, so 2.91.93 was released yesterday.

And today, you can download GNOME Live Image 0.3.0, which contains all the fixes from 2.91.93 tarballs.

Url to download it hasn't changed : http://gnome3.org/tryit.html

Enjoy !

SUSE Studio is  an awesome tool, with a couple of clicks you can create an openSUSE/SUSE based system and deploy to your hard drive, an usb flash,  a live dvd, a VMware/VirtualBox/Xen server and even Amazon EC2 cloud.

Suppose you want to create a tailored SUSE Studio appliance to run a Ruby on Rails app, this is a list of things you have to take care of:

• install all the gems required by the app (this can be a long list).
• install and configure the database used by the app.
• install and configure a webserver.
• ensure all the required services are started at boot time. You can save some time by cloning this appliance shared on SUSE Gallery, but this is still going to be boring.

Dister to the rescue!

Dister is a command line tool similar to the one used by Heroku (one of the coolest ways to run your Rails app into the cloud). Within a few steps you will be able to create a SUSE Studio appliance running your rails application, download it and deploy wherever you want.

Dister is named after SUSE Studio robot. It has been created by  Dominik Mayer and me during the latest hackweek.

How it works

We are going to create a SUSE Studio appliance running a rails application called “SUSE history”. The app uses bundler to handle its dependencies. This is its Gemfile file:

source 'http://rubygems.org'
gem 'rails', '3.0.5'
gem 'pg'
gem "flutie", "~> 1.1"

As you can see the app uses rails3, the flutie gem and PostgreSQL as database.

Appliance creation

Move into the suse_history directory and execute the following command:

dister create suse_history

As you can see dister has already done a couple of things for you:

• created an appliance using latest version of openSUSE supported by SUSE Studio (you can use a different base system of course)
• added the devel:language:ruby:extensions repository to the appliance: this repo contains tons of ruby packages (like _modpassenger)
• installed a couple of things:
  • _devel_CC++ pattern: this will allow you to build native gems.
  • _develruby pattern: provides ruby, rubygems and a couple of development packages needed to build native gems.
  • rubygem-bundler: bundler is required by dister in order to handle the dependencies of your rails application.
  • rubygem-passenger-apache2: dister uses passenger and apache2 to deploy your rails application.
  • postgresql-server: dister noticed suse_history uses PostgreSQL as database, hence it automatically installs it.
  • rubygem-pg: dister noticed suse_history uses PostgreSQL as database, hence it automatically installs the ruby’s library forPostgreSQL.
• uploaded a custom build script which ensures:
  • mod_passenger module is loaded by Apache
  • both Apache and PostgreSQL are always started at boot time.
  • all dependencies are installed: this is done only during the first boot using bundler.
  • the database user required by your rails app is created. This is done only during the first boot using some SQL code.
  • the database used by the appliance is properly initialized (aka rails db:create db:migrate). This is done only during the first boot.
    

Upload your code

It’s time to upload suse_history code. This is done using the following command:

dister push

As you can see dister packaged the application source code and all its dependencies into a single archive. Then uploaded the archive to SUSE Studio as an overlay file. Dister uploaded also the configuration files required by Apache and by PostgreSQL setup.

Build your appliance

It’s build time!

dister build

The appliance has automatically being built using the raw disk. You can use different formats of course.

Testdrive

Testdrive is one of the coolest features of SUSE Studio. Unfortunately dister doesn’t support it yet. Just visit your appliance page and start testdrive from your browser. Just enable testdrive networking and connect to your appliance:

Download

Your appliance is working flawlessly. Download it and deploy it wherever you want.

dister download

Current status

As you can see dister handles pretty fine a simple Rails application, but there’s still room for improvements.

Here’s a small list of the things on my TODO list:

• The dependency management should install gems using rpm packages. This would make the installation of native gems easier, right now the user has to manually add all the development libraries required by the gem. Moreover it would reduce the size of the overlay files uploaded to SUSE Studio.
• SUSE Studio Testdrive should be supported.
• It should be possible to deploy the SUSE Studio directly to EC2.
• Fix bugs!
  

Bugs and enhancements are going to be tracked here.

Contribute

Dister code can be found here on github, fork it and start contributing.

If you are a student you can work on dister during the next Google Summer of code, apply now!