So far other two weeks are past since my last blog post about Rigo. I have been able to implement several features since then, mainly thanks to RedBull I’d say. Jokes apart, I’m used to work on Rigo in the evening and early (6am) morning and, despite hackers are all used to nightly coding marathons (including me, actually), the best is coming out of me when birds start singing.

git-log would tell you what changes have been made in this timeframe, without me wasting time here instead of coding, but I think communicating it explicitly would help me getting some feedback from all of you in order to enrich my next UI design iteration. I’m not an interaction designer myself, don’t really want to be, but I learned a lot of things working with them in the past. Although we sometimes see interaction designers as kids with a pencil abusing of erasers (i’m not serious!) they are vital in the success of your App (I learned it the hard way as well).

Dbus Service

RigoDaemon is the new Dbus-powered service that handles the privileged operations on behalf of (concurrent) Rigo clients, such as Repositories Update, Application Management (install/remove/update) and System Upgrade. These are in fact the three main tasks RigoDaemon is going to carry out. The hard part has been implementing a way to do Resource Passing from Rigo clients (holding shared Entropy Resources locks) and RigoDaemon (wanting to acquire exclusive access to the same Entropy Resources), i called the whole process: rendezvous (as it is, in fact). The rendezvous has to be fault-tolerant in the sense that, being for both releasing and acquiring back shared locks by Rigo clients, these can go away anytime and RigoDaemon is required to make sure to not hold resources if no Rigo instances are connected.
RigoDaemon is going to replace Magneto Dbus Service, once Rigo replaced Sulfur.

Concurrency

Multiple Rigo Clients can be used concurrently, as images show below. The IPC architecture allows RigoDaemon to “arbitrate” resources access, kindly asking all the clients connected to release them for example (due to the beginning of a specific Activity, see below). At the same time, it is possible to launch an activity (like repository update or system upgrade), then close Rigo, reopen it and have it resumed to the current activity state. This makes Rigo fully fault tolerant against bugs and critical system updates where GTK3 or other Rigo dependencies could (but shouldn’t) be subject to potential instabilities. Running GTK3 unprivileged is also another indirect goal achieved.

Activities

Both RigoDaemon and Rigo implement their daemon and UI state through a Finite State Machine, moving from an activity to another atomically. This makes possible to aggressively use multithreading without worrying too much about UI state and the likes. I don’t want to start describing the boring details here, but since I introduced this way of seeing the whole User <-> Rigo interaction story, everything started to make sense: spawning a repo update event now means “hey, i want to carry out this activity, gimme the UI control” and “hey dude [dude is another Rigo Client process] the other guy here wants to do Activity-X, could you please lock down and start listening to his events?”.
The concept is the same you can find developing for Android, and is about how the human being can deal with tools, you cannot use a hammer and a chainsaw at the same time in real life!

PolicyKit

Any privileged activity inside RigoDaemon is controlled by PolicyKit actions. There are three main actions (the same listed below): Repository Update, System Upgrade and Application Management. This way administrators could even setup policies allowing users to update, upgrade or install apps with no privileges at all (read: *could*). PolicyKit gives us this fantastic flexibility though.

Repositories Update

The Activity I’ve been working on is Repositories Update. Even if this is usually carried out by Magneto (automatically updating repositories on our behalf), there are cases in which this is still important for Users: they might not have Magneto loaded, repositories could have been just added to the list and Rigo would need to download them, etc.
This Activity is also a good testbed for RigoDaemon <-> Rigo Client IPC architecture. Fact is, it took me 5 iterations before getting everything working the way I wanted (I’m a picky guy you know…).

Repositories Update Activity, like all the other activities that are going to be implemented soon, require RigoDaemon running. Now, there’s a trick to start it in devel mode, and start Rigo (you need pygobject-cairo, all the GLib introspection stuff, including introspection support in policykit):

$ git clone git://git.sabayon.org/projects/entropy.git
$ cd entropy/rigo/RigoDaemon && sudo sh  devel-start-daemon.sh &
$ cd ../ && python2 rigo_app.py –debug

What’s missing

The UI is not 100% complete first of all.
System Upgrade, Application Management activies are not implemented yet.
The Rigo Preferences View is not there (this will contain handy buttons to launch secondary activies as well as forcing repositories to update).
If all goes well, I expect to have everything working in a month from now, even because I need to go back studying then.

This blog post took me 1 whole evening (split across several), if you think it’s been worth it, don’t think twice and donate to Sabayon now, www.sabayon.org/donate .

If you ever wondered why Fedora and Ubuntu have such nice animated boot screens, let me enlighten you on this subject. They are using Plymouth to achieve this.

If you want to play with this I have some instructions for you to follow but be warned that you should know what you are doing and let me start with summing up some known issues:

All following problems should be solved when Plymouth is finally integrated with OpenRC.

1. Because Plymouth is taking over the control of tty1 it might mess it up. Although they should no longer occur with 0.8.3-r3.
Line endings might be messed up.
Password typed in tty1 might be not hidden. Switch to another tty to login.
2. Plymouth turns on OpenRC’s interactive mode. The workaround is to disable it permanently in /etc/rc.conf.
3. Splash might freeze on some stages and not respond immediately.

dev.gentoo.org/~aidecoe/doc/en/plymouth.xml

If this didn’t scare you away yet here are the steps to make it work on a Sabayon system:

equo install dracut plymouth

change Openrc configuration:
edit /etc/rc.conf

rc_interactive=”NO”

list plymouth themes and select one:
plymouth-set-default-theme –list

we select the solar theme:
plymouth-set-default-theme solar

generate initramfs:
dracut -H

NOTE: Whenever you change plymouth theme regenerate initramfs:
dracut -H -f

when you generate a new initramfs notice this line:
I: -rw-r–r– 1 root root 4050903 Mar 6 21:04 /boot/initramfs-3.2.0-sabayon.img
this is the location of the generated initramfs we need to add to the next step.

edit /etc/grub.d/40_custom

add:
menuentry “Dracut” {
linux /boot/kernel-genkernel-x86_64-3.2.0-sabayon root=/dev/sda1 video=uvesafb:mtrr:3,ywrap,800×600-24@60 quiet splash
initrd /boot/initramfs-3.2.0-sabayon.img
}

regenerate grub.cfg:
grub-mkconfig -o /boot/grub/grub.cfg

reboot and select the Dracut entry from grub

Time flies when having fun, seems like I haven’t blogged about anything in forever.  I hope everyone knows Sabayon 8 is released and I haven’t seen much for issues being reported.  I’m seeing the typical installer stuff, anaconda is a fussy beast.  I’ve battled in the past also, so your not alone.  For the few issues reported, I’d say success.  Oh yea, after all the hype of new xorg and legacy hardware not working, last minute decision was to keep old xorg for now.

Speaking of reporting issues, I’m still seeing people post on forum and bugzilla invalid stuff.  Stating things like, “I did a fresh install than did the updates and now the desktop won’t load”.  There isn’t anyone in this universe that is going to be able to help you.  Developers will simple click invalid and move on.  You need to provide as much info as possible, hardware, logs, errors, how to reproduce, things like that.  Many people will say they don’t know how to get logs, check out this forum topic to help, How to Gather Log Files Easily.  Most of the time you are gonna need to get friendly with your terminal, especially if your X isn’t loading.  Starting applications from terminal can also provide valuable information.  So please provide something, the tools are there, use them to help yourself or for someone to help you.

So have you heard of Rigo Application Browser that Fabio is working on?  Check it out and if your ambitious and an advanced user, you can clone the entropy git and give it a whirl.  I believe Fabio said it’s a month out yet for the general public, so watch for updates.

Oh yea, been seeing questions as to where the Sabayon Experimental 8 spins are.  There just hasn’t been much discussion on that, so what I would recommend for now is to grab one from the Daily folder on the mirrors and than you will have a current build of your favorite experimental spin.  People worry about the Daily builds, but I run them all the time and find them stable.

Sabayon Forensics spin has gotten a couple new packages added to it by request.  I added net-misc/dropbox which I just added to the spec file today and net-wireless/aircrack-ng which is already on the current build.  The next build of ISO is this coming Sunday so dropbox will be on that ISO.

A quick question for all, when would be a good time to drop x86 branch?  1 to 2 years or more?  x86_64 is every where now a days, can’t remember last time I used a x86 operating system.

Rigo Application Browser is the official name of the Sulfur (aka Entropy Store) successor. The similarities end here, actually. This Gtk3-based application is sporting a very simple and clean design (Rigo means “row”, more or less): the whole interaction happens through a single widget: the search bar. Who doesn’t know how to use a search bar? Who doesn’t know how to use Google these days? Well, that’s the rationale. Installing Applications (but also searching through the available ones) should be just like “googling” a page. Nothing less, nothing more: you search it, you pick it, you wait for it to install. Done.

It’s been a month since I started working on it, following a bottom-up approach, making sure that the architecture can scale up well (and it does!!!). I guess another good month will be required before being ready for public testing (even though you can get Rigo via entropy.git repository already).

If you’re wondering about the speed, well, this is blazing fast. If you’re wondering what package managers are going to become on the Linux platform, that’s the 2012 answer to that question. Enjoy the shots (the UI is not complete yet! These are from the 4th UI design iteration).

While I’ve been a bit busy with work (I currently work on Lightstreamer for Weswit if you don’t know), with Rigo Browser, the next-gen (cough cough) Visual Entropy App Manager (in poor words, the Sulfur replacement — another blog post will follow) and with other zillions of things I daily do…

…while all this, I’ve been eventually able to hook in the first EfikaMX ARM image (X-less for now) on our ISO/Image build server. You should expect to hit our mirrors next Monday, under the iso/daily directory. You will need to update your u-boot version to the latest and greatest (See Genesi docs around) to get it boot, this because I actually use ext3 as boot partition (instead of the fugly vfat). The image will be called Sabayon_Linux_DAILY_armv7a_EfikaMX_Base_4GB.img.xz and as the the filename says, it’s suited for 4GB SDHC cards (better if Class 10).
The install procedure is always the same, xzcat over the device and the insert the MMC into the Efika. You will be then able to install the X stack using Entropy (via equo -> equo update && equo install foo).

Of course, I’m already preparing a GNOME3/Cinnamon/E17/who-knows-what-else version of the EfikaMX image. So, just be patient and you’ll get it. Hopefully with GL accell as well.

At the same time, I’m also building up an armel chroot (all our current ARM chroots are armhf – hardfloat ABI), that’s the only way to get GLES working with PowerVR GLES libraries, and eventually be able to get XBMC working on BeagleBoards and PandaBoards (blame those ugly proprietary drivers and libs). If anybody around is interested in helping us with man power on these two new Sabayon chroots, don’t hesitate to contact me or the rest of the team.

This is just a quick and dirty update for those following me in the ARM adventure, the best part has yet to come tho.