Here's a few tips and tricks that some people might want to use to fine tune their openSUSE 12.3 machines

'Traditional' Multi-monitor behaviour for GNOME 3 workspaces

GNOME 3 has a bit of a weird way of handling multiple monitors with its multiple workspaces feature. When switching workspaces, it's only the workspace on the 'primary' monitor which changes, the applications running on the second monitor (or 3rd or 4th..) remains where they are, as if they're on the own single, static, workspace.

Some people like this behaviour - I use it so I can have one screen with key tools I need all the time (Network monitors, etc) where my other screen is the one where I'm constantly shifting and changing depending on what I'm doing

But if you'd like to change to a 'traditional' arrangement where changing workspaces changes the applications on all of your screens, all you need to do is run the following command as yourself (I'd recommend pressing ALT+F2 and just copy/pasting this in there)

gsettings set org.gnome.shell.overrides workspaces-only-on-primary false

and if you decide you want to change it back to the standard behaviour

gsettings reset org.gnome.shell.overrides workspaces-only-on-primary

Making your fonts even prettier in GNOME 3

First things first - I strongly recommend that if you have them installed, remove the Microsoft TTF fonts with the following command as root

zypper rm fetchmsttfonts

As I explain on my Google+ post, 'back in the day' Microsoft's fonts were pretty much considered the only acceptable fonts and the Free/Open alternatives installed on openSUSE by default were considered ugly.

That might have been true back then, but in this day and age the Free/Open fonts installed are much smoother and I find myself looking at the MS fonts and recoiling in horror much as I used to at Linux fonts.

To really get your fonts looking perfect, I'd recommend playing around with the 'Hinting' and 'Antialiasing' options in the Fonts section of 'gnome-tweak-tool' (launch by pressing the Winkey/Super and searching for Tweak)

I find that having 'Hinting' set to 'Slight' and 'Antialiasing' set to 'Rgba' looks best on my machines.

Installing the Groupwise Client on openSUSE 12.3

Quite a few of us openSUSE users work for companies that run Novell's Groupwise. Their Linux client hasn't seen any development in recent years, but with the absence of an open source alternative, many of us needed to find a way to get 'old faithful' working.

Thanks to Michael Brookhuis from SUSE, we have a solution. Run the following command as root to make sure you have all the necessary packages installed

zypper in openmotif-libs-32bit libstdc++33-32bit libpangox-1_0-0-32bit

And then run the following to make a symlink so Groupwise can find the openmotif libs you just installed

 ln -s /usr/lib/libXm.so.4 /usr/lib/libXm.so.3

Or you could just be like me and use the Groupwise Web Interface, which has finally grown on me :)

Hope this helps some people out there

The combination of limare and open-gpu-tools can now run Quake 3 Arena timedemo without depending on the binary driver for the shader compiler!

Connor Abbott has been being his amazing (16y old!) self again in the weeks after his talk at FOSDEM, and he pushed his compiler work in his open-gpu-tools tree to be able to handle basic vertex shaders. Remember that our vertex shader is a rather insane one, where the compiler has to work real hard on getting scheduling absolutely right. This is why an assembler for our vertex shader was not too useful and the most part of a compiler had to be written for it to generate useful results. A mammoth task, and Connor his vertex shader code is now larger than the code I have in my limare library.

So it was high time that we brought limare and OGT together to see what they were capable of with some basic shaders. Luckily, the Q3A GLES1 emulation has basic shaders, what a nice coincidence :)

So Connor turned my simple vertex shader essl into the high level language used by the OGT vertex shader compiler, and through steps described at this wiki page, turned them into MBS files (Mali Binary Shader - the file type output by the standalone compiler, and also by newer binary driver integrated compilers). Limare can then load and parse those MBS files, and run the shaders. No need to involve the ARM binary anymore when we have OGT generated MBS files :)

The result was quite impressive. We had a few issues where the limare driver (which has mostly taken its cues from the output of the binary driver) and OGT disagreed over symbol layout, but apart from that, bringing up the shaders connor produced was pretty painless. Amazingly effortless, for such a big step.

Connor then spent another day playing with the fragment shader assembler, fixed some bugs, and produced 3 fragment shaders for us. One for the clear shader used by limare directly, and 2 for Q3A. After some more symbol layout issues, these also just worked! We even seem to be error-margin faster with the MBS files (due to texture coordinate varyings being laid out differently).

So this is a really big milestone for the lima driver project. Even with our insane pre-optimized architecture, we now are able to run Quake 3 Arena without any external dependencies, and we are beating the ARM binary while doing so.

For generating your own shader MBS files, check out Connors OGT, and then you can head straight to Connors wiki page. My Q3A tree now has the MBS code included directly. And i pushed a dirty version of my FOSDEM limare code.

As for this new limare code, this fosdem_2013_pile branch will vanish soon, as i need to properly pry things apart still. This is run-for-the-price code, and often includes many unrelated fixes in the same commit. It's better to do archeology on it now, than 3y from now, so this needs to be split. But in the meantime, you all can go and give Q3A on a fully free driver stack on Mali hw a go :)

I will not post a video, as there really is nothing new to see. It is the exact same timedemo, running some promille faster. Build things, and then run it yourself on your sunxi hardware (i am still working on porting it to the new kernel of a more powerful platform). That's the best proof there is!

For building limare, check out the fosdem2013_pile branch and then just run make/make install.

For building Q3A all you need to do is run:

make ARCH=arm USE_LIMARE=1

And, when you have the full quake installed in ~ioquake3/baseq3, you can create a file called ~ioquake3/baseq3/demofour.cfg with the following content:

cg_drawfps 1
timedemo 1
set demodone  "quit"
set demoloop1 "demo four; set nextdemo vstr demodone"
vstr demoloop1

You can then run the ioquake3 binary with "+exec demofour.cfg" added to the command line, and you will have the demo running on top of fully free software!

Now we really have covered all the basics, time to find out how Mesa will play with our plans :)

Note: this blog post follows the ones of Frank Krueger about the alpha release of mono 3.x for Xamarin.iOS bringing .NET 4.5 features to the mobile world: Drag-n-drop and Scripting Users. Read that first, it's worth it.

The old way!

If you're using the Chipmunk bindings, the correct way to handle collisions between shapes is to register 4 (FOUR!) handlers for the different steps: begin, preSolve, postSolve and separate. Your collision handling logic is then spread in 4 different functions. All of that for the same collision.

bool Begin (Arbiter arb)
{
 Console.WriteLine ("began");
 return true;
}

bool PreSolve (Arbiter arb)
{
 Console.WriteLine ("presolved");
 return true;
}

void PostSolve (Arbiter arb)
{
 Console.WriteLine ("postsolved");
}

void Separate (Arbiter arb)
{
 Console.WriteLine ("separated");
}

It would be great, for the sake of simplicity, if we could group the logic altogether.

await to the rescue

C# 5 (in .NET 4.5) allows just that. Procedural code in the form of:

await began;
Console.WriteLine ("BEGAN");
await presolved;
Console.WriteLine ("PRESOLVE");
await postsolved;
Console.WriteLine ("POSTSOLVE");
await separated;
Console.WriteLine ("SEPARATED");

All this, ran into an infinite loop:

async void WaitForCollisions ()
{
 using (var waiter = new AsyncCollisionWaiter (space, WALL, CHARACTER)) {
  for(;;) {
   var began = waiter.GetBeginAsync ();
   var presolved = waiter.GetPreSolveAsync ();
   var postsolved = waiter.GetPostSolveAsync ();
   var separated = waiter.GetSeparateAsync ();

   await began;
   Console.WriteLine ("BEGAN");
   await presolved;
   Console.WriteLine ("PRESOLVE");
   await postsolved;
   Console.WriteLine ("POSTSOLVE");
   await separated;
   Console.WriteLine ("SEPARATED");
  }
 }
}

The magic lies in the AsyncCollisionWaiter. Here's a quick implementation for it

Caveats

Get openSUSE 12.3 Now that openSUSE 12.3 is out, the openSUSE ARM Team want to step up a gear. As the cycle was shorter than normal, there are a few wrinkles that need to be ironed out and also a whole heap of new things that can be added. After some discussion at FOSDEM, it was decided to hold a Hackathon to address these items. The Hackathon will take place on 08 to 12 April, both at the SUSE offices in Nuremberg as well as online for those that can’t attend in person.

Have you heard about it? openSUSE 12.3 is out!

I did an upgrade earlier today on my main laptop (with a simple zypper dup after having updated the repos configuration, which went surprisingly fast), and this release looks great! But the best part: it comes with OpenStack love!

Enjoy Folsom!

For the first time, an openSUSE release provides a fully working set of OpenStack packages. We had some OpenStack packages in the previous release, but they were not in such a great shape and some components were even missing (although we fixed that later on with packages in the build service).

With 12.3, you can finally enjoy OpenStack with the Folsom release in a very straight-forward way, and therefore you can easily deploy your own cloud. The packages that we provide are built from the stable/folsom branch, and there's an online update coming soon so you can enjoy the stable/folsom code as of end of last week.

To help people who might not want to learn everything needed to properly deploy OpenStack, we also have a small openstack-quickstart package, that comes with a script that can be used to deploy everything locally. It is obviously not recommended to run this on your main computer (I usually run this in a virtual machine), but it gets you quickly to the point where you can play with OpenStack.

Dashboard of an OpenStack cloud running on openSUSE 12.3

Play today with Grizzly!

Of course, Folsom is relatively old at this point and the new version, Grizzly, is to be released in three weeks. But don't be sad! We've been working on Grizzly packages for some time now: you can grab them from the Cloud:OpenStack:Master project in the build service (hey, look, it's even building packages for SLE and openSUSE 12.2! the build service is a rather convenient tool!). I guess we'll properly move them to Cloud:OpenStack:Grizzly once Grizzly is officially released.

Develop with DevStack!

I mentioned a few months ago that I had finished porting DevStack to openSUSE 12.2, and I wrote some small documentation on how to use it. It's really a neat tool, both for playing with OpenStack and for developing for it.

However, I realized earlier this week that I had never double-checked everything was still okay for 12.3. It turns out there's a small issue that completely breaks it, oops ;-) But once the fix is checked in, DevStack will be usable on the latest openSUSE. I'll do some more tests before marking this version of openSUSE as supported in DevStack, but that shouldn't block anyone from using DevStack on 12.3.

Join us!

We're pretty open about how we develop OpenStack in openSUSE. Andreas wrote a post about all this a few days ago. We've opened up (or rather, revived) a mailing list dedicated to the cloud recently, which developers, packagers and users can all use to discuss OpenStack. And unsurprisingly, we also have an #opensuse-cloud channel on Freenode. But most importantly, we've worked on making public the infrastructure we use to build OpenStack for openSUSE.

I think the important bit on this is that everybody is able, and welcome, to join this effort. It's not just about being able to say "see, we have OpenStack"; it's about building a rock-solid experience for OpenStack, and enjoying doing that!

Now, let's celebrate the release: party time! :-)

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

I read today that Ubuntu-Gnome is now an official flavour of Ubuntu! Great work, you’ve achieved the same level of recognition as KDE has.  Establishing Kubuntu, and other flavours of Ubuntu, was a very canny move on Canonical’s part to control and contain dissent within the Ubuntu big tent.   The Kum-ba-ya, lets-all-make-a-circle-in-our-vests hype that Ubuntu generated in 2005 was so strong that it sucked in KDE users as well as users of GNOME, then the anointed Ubuntu desktop.  Pretty soon they formed an unofficial forum, in Germany (where else) and started talking about a KDE Fork.  The answer from Canonical was to throw them Kubuntu, with “infrastructure and support benefits“, hiring the Debian KDE maintainer, and to pour blandishments into the credulous ears of the KDE leadership of that time, who were mighty unsettled by the acquisition of their then-darling distribution by Novell and its earlier Ximian purchase.  This sackful of glass beads and liquor was sufficient to prevent ornery KDE users roaming all over the place doing what they liked, and especially not over the border to other distributions, and in doing so increase Ubuntu’s momentum.

Now fast forward to 2013 and we’re seeing the same happen to GNOME.  No longer the standard desktop, but still with significant suction among Ubuntu users, GNOME is neatly herded on to the reservation and congratulated on its wise decision.  Now look to your Kubuntu colleagues to see how that is going to work out for you down the road. PS: If Mark promises to install GNOME Ubuntu, don’t believe him for a second.  He has an office by now full of desktop computers representing official flavours that he never turns on.  Sound familiar?

Howdy,

the openSUSE on ARM team was quite busy the last few weeks with getting openSUSE 12.3 for AArch64 (ARM64, also called ARMv8) ready. At the time of this post, we have finished around 4100 packages (out of ~ 6000) of openSUSE 12.3 built for AArch64, the ARM 64bit platform. With those successfully built packages, we’re also able to build a regular openSUSE image for you to try and run in the ARMv8 System emulator (ARMv8 Foundation Model).

This is a huge achievement and milestone for us, thanks to lots of helpful hands within openSUSE. Just to put this into perspective: This is not a minimal system with a couple of toolchain packages. It is also not an embedded variant of a Linux environment. No, this is the full featured, standard openSUSE distribution as you’re used to, ported to AArch64, up and running. We have built it based on (slightly newer versions of) standard openSUSE 12.3 packages, and the changes are mostly already merged back into openSUSE Factory. For all we know it’s also more successful package builds than any other Linux distribution has on AArch64! If you’d like to see the status yourself, please check out the OBS repository we created for this.

As an open distribution, it is important to make contributions easy and we worked hard to enable others to participate in our effort. We extended OBS to automatically spawn a Foundation Model virtual machine when you want to build for aarch64. This works remotely on the OBS server as well as locally using osc build. More information on this is available on the respective wiki page.

So, dive right into it:  Get the image and start with openSUSE on AArch64 by following our wiki page: https://en.opensuse.org/Portal:ARM/AArch64.

Check out the Barcelona Ruby conference 2013 speakers on the Weekend 14 & 15 September 2013

http://www.baruco.org/speakers

Yukihiro Matsumoto
Aaron Patterson
Avdi Grimm
Bryan Helmkamp
Charles Nutter
Corey Haines
David Chelimsky
Katrina Owen
Matt Wynne
Paolo Perrotta
Reg Braithwaite
Richard Schneeman
Sandi Metz

Want to be in the list? Call for papers is open until 10th March

http://www.baruco.org/call_for_papers

 Want to sponsor?

http://www.baruco.org/sponsors

This is one of my recent collection of creations for the project. Check it out! Now that many things are about to happen for the community such as the release of openSUSE 12.3, openSUSE Conference in Greece and later on, openSUSE Summit. I hope that some of these images make a change for who participates of the community. I always try to put my best efforts in creating something that reflects the feelings and fun of this community.

Thank you