sysadm for a weekend

Probably many of you do not realize how much time it takes to maintain a healthy distro infrastructure. With “distro infrastructure” I mean all the servers and virtual machines that are serving Sabayon users and random website visitors.

We currently have 5 servers spread around several Italian Universities and TOP-IX, all of them are running Sabayon and all of them need to be kept up-to-date, rebuilt from time to time to accomodate new services or new management architectures (like automated content provisioning for throw-away virtual machines, etc). On top of two of them, there are a bunch of OpenVZ virtual machines, for sandboxing several critical components.

During the last weekend, and the weekend before it, I’ve been busy rebuilding the whole WWW virtual machines (OpenVZ) in order to transform these simple static virtual machines into  “clusterable” ones (for instance, implementing boot-time content provisioning, decoupling static data from webapps,  etc). Moreover, I eventually found some time to also decouple the Database Server (MySQL, at this time) from the WWW virtual machine. At some point, we’ll be able to migrate some of the infrastructure to the cloud with almost no effort and, most importantly, we will be able to scale out quite easily during post-release periods. Unfortunately, at this time, cloud computing is still quite expensive and we would need a lot more donations to be able to pay for it, so we need to squeeze all the RAM and CPU available from the current infra.

On a unrelated note, I am really proud of my little monster, Entropy, which is really doing a great job on our servers. Time to get back to Rigo coding now…

Sabayon 9: released

After more than 3 months of hard work. I am pleased to announce the immediate availability of Sabayon 9.

Have a look at the press release here and enjoy Sabayon.

Going to the Tizen Developer Conference

I am really happy to announce that I’ve been invited to the Tizen Developer Conference, in San Francisco, CA next month (May 7-9). I’m going with a friend of mine, Michele Tameni, who seems to have won the Intel consolation prize (damn you!).
I really need to thank Giovanni Martinelli and Mauro Fantechi for sponsoring my trip there and across the whole San Francisco Bay Area (I’ve been told that it’s full of Gentooers, gonna catch you!).

This is a great opportunity for me to meet a good deal of hardcore FLOSS devs and have a beer together (just one?). There are also several exciting talks I couldn’t really miss.

Feel free to contact me if you want to meet up for a drink. A post to the gentoo-core ML will follow next week.

Entropy & Rigo at Transifex

I created two projects at Transifex aiming to get better Entropy (and
Rigo, which has split .po files) localization support.

Sabayon Entropy Transifex Project Page:
https://www.transifex.net/projects/p/sabayon-entropy/

Sabayon Rigo Transifex Project Page:
https://www.transifex.net/projects/p/sabayon-rigo/

If you are speaking non-English languages, then help us out!

I’m going to create the Anaconda (Sabayon Installer) translation project later today.

Sabayon runs Android Market / Google Play Apps natively

I’m sure this is going to blow your mind completely.

During the last two months I’ve been busy re-thinking the way Package Management works in Linux distros in terms of User interaction and I ended up designing the new Sabayon Entropy GUI using a “less is more” approach. In layman terms, the idea is to carry out all the activities through two, and only two, main “interaction points”: a search bar and a notification bar (for sending feedback to User).

But why not going further and supporting Android Market Google Play Applications directly in Rigo?
This is exactly what I did, and it’s been even easier than implementing the whole Entropy Package Manager thanks to the fact that Android apps are self-contained and no dependency management is required.

So, yeah, Sabayon now supports Android Market Applications natively, both installation and runtime execution (through the Dalvik Java VM).

Rigo Application Browser, getting closer

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, http://www.sabayon.org/donate .

Rigo Application Browser, less is always more

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).

EfikaMX Base (X-less) Image, softfp chroot and more

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.

Hitchhiking on BeagleBoard xM and PandaBoard

During the FOSDEM weekend, I’ve been also able to write down some wiki notes about getting Sabayon (and Gentoo) working on the BeagleBoard xM and PandaBoard. You may be interested in reading the Hitchhikers guides for these two boards (but don’t get excited too much, our chroots are currently hardfp, this means no 3D until Imagination/TI/whatever don’t release the hardfp version of their OpenGL libraries — or unless I make a softfp chroot). Considering that even Ubuntu is switching to hardfp, I really feel optimistic about it.

Currently, you can find the BeagleBoard xM image on our ISO mirrors (under the “daily” directory), while the PandaBoard one will appear next Sunday. Both ship with the graphic stack, using omapfb (sigh), LXDE and Midori as Web Browser. NetworkManager is there as well. As you can imagine, there is still a lot of work to do (mainly making code compile, did I say Chromium?). Now I’m going to focus on the Efika MX a bit, it really looks to be orders of magnitude faster than the PandaBoard (woot!).

Enjoy arm and say thanks to Tigal for having sent me the boards.

Back from FOSDEM12

So, it’s beeen a quite exciting weekend at ULB in Bruxelles.

I would really like to say thanks to all the people I’ve been talking with during these days. Hope you all had a good time there. It’s always nice to meet other devs IRL and share opinions on stuff.

Besides this, many exciting things are around the corner during the next 10-15 days. I’m almost done writing about the BeagleBoard xM and PandaBoard on the Sabayon wiki (feel free to copycat the stuff to Gentoo wiki, no problems here). This means that I am eventually going to start messing with the Efika MX nettop, can’t wait can’t wait. People from Genesi USA are awesome, so is their hardware, no kidding.

And, last but not least, Sabayon 8: I just need to find time to write the full release notes (tomorrow nite hopefully).

hello, twitter

Enter your email address to follow this blog and receive notifications of new posts by email.

Join 584 other followers

del.icio.us

Follow

Get every new post delivered to your Inbox.

Join 584 other followers