Important: Sabayon x86 (32bit) is being deprecated

Hello users,

TL;DR: x86 (32bit) support is going away soon, if you use Sabayon x86_64 (64bit), you can ignore this.

in an effort of decreasing our computing and human capacity requirements, I am going to start the process that deprecates Sabayon x86 (32bit) images, package repositories and their support.
x86_64 (or AMD64) has been introduced one decade ago. Yes, it was 2004, pretty much the same year I started messing with a binary Gentoo-based distro.

It’s time to move on, free up resources and focus on what matters. 32bit is not important anymore and modern computers come with tons of GB of RAM. At the same time, I don’t see x32 going anywhere. Instead, I see the need to standardize on one single x86 architecture. Some distributions have started doing the same, for instance, RHEL 7 will not see any 32bit version. Windows 8, well, yes, said goodbye to 32bit as well.

If you are still stuck with 32bit CPUs, there are 5 things you could do:

  1. Make sure that your CPU does not really support x86_64. You may be surprised to know that it might run x86_64 code just fine.
  2. Given our deprecation roadmap, migrate your stuff over a more recent system. eBay, Amazon, are your friends. A second-hand x86_64 system can cost you less than $100.
  3. Migrate to other distros and pray they won’t kill 32bit anytime soon (time is not in your favor).
  4. Migrate your Sabayon system to Gentoo/Portage, basically compiling your own stuff. Alternatively, setup your own Entropy repository in order to keep your system up-to-date.
  5. Burn your motherboard and CPU by doing insane overclocking and then, when they die, violently hit them with a hammer while screaming “You shall not compute!”.

Our deprecation roadmap is as follows:

  • June 2014: stop offering x86 images off our download pages, keep them on mirrors.
  • July/August 2014: stop building x86 images as part of our daily and monthly release rollout.
  • October 2014: stop offering x86 images from our mirrors.
  • November 2014: stop offering package updates, including security updates, for x86 images.
  • January 2015: stop offering packages from our mirrors.

After January 2015, you will not be able to install new packages as well. The only way to keep your system up-to-date is to use Portage (plus our overlays) or Entropy (by maintaining your own repository). Our x86_64 images are multilib, which means that you can run 32bit code on them just fine.

Make your own SteamBox with Sabayon, now.

So, this started as a personal project. One of the projects you start during a rainy day. Actually, it did not rain at all, but I wanted to take a day off from my readings (just completed this btw).

You cannot really stop hobbyists from doing what they’re best at, after all. You cannot even stop enthusiasts from being enthusiasts when, eventually, somebody puts some love into the Linux ecosystem.

So, my question is, while we wait for the official SteamBox (and perhaps Half-Life 3…), why don’t we make our own? And this is what I did.

I want to share with you a (personal but publicly available) Sabayon image called: “Sabayon SteamBox Edition (md5, torrent)“.

What is this?

Sabayon SteamBox Edition is a remastered 64bit only Sabayon live image that contains Steam. This image can be either run off USB storage or DVDs or installed, like any other Sabayon image. The difference is that, once booted, Steam is automatically started in Big Picture mode.

How does it work?

Well, as written above, Steam is automatically started in Big Picture mode at boot. However, you can exit Steam and logout through an application running in background called “Steam Manager” and then, log into GNOME and use the system as a normal Sabayon distro. This allows you to make changes to it, like for instance, setup a wireless connection, configure Steam the way you want or just update the system, and then dive back into the “SteamBox” mode.

This is pretty much the way I converted my Windows Steam (gaming) machine into a Sabayon SteamBox, and I’m sure that some of you may want to do the same.

What hardware, or better, what GPU?

Seriously, get a NVIDIA GPU. If you really want to play complex games that’s the easiest solution. However, I also managed to run Steam off open source radeon and even intel drivers, but I got the best experience when using the nvidia ones. Sabayon SteamBox also experimentally supports NVIDIA Optimus (it uses optirun, but I will migrate to primusrun soon) if you boot the system appending “optimus” to the kernel command line.

How to transform your current Sabayon into a SteamBox?

Simple, just “equo install sabayon-steambox“, enable the “steambox” service (with systemd: systemctl enable steambox), append “steambox” to the kernel command line and reboot.

Thanks Valve.

steambox

Rolling out systemd

28283482

We started to roll out systemd today.
But don’t panic! Your system will still boot with openrc and everything is expected to be working without troubles.
We are aiming to support both init systems, at least for some time (long time I believe) and having systemd replacing udev (note: systemd is a superset of udev) is a good way to make systemd users happy in Sabayon land. From my testing, the slowest part of the boot is now the genkernel initramfs, in particular the modules autoload code which, as you may expect, I’m going to try to improve.

Please note that we are not willing to accept systemd bugs yet, because we’re still fixing up service units and adding the missing ones, the live media scripts haven’t been migrated and the installer is not systemd aware. So, please be patient ;-)

Having said this, if you are brave enough to test systemd out, you’re lucky and in Sabayon, it’s just 2 commands away, thanks to eselect-sysvinit and eselect-settingsd. And since I expect those brave people to know how to use eselect, I won’t waste more time on them now.

What’s cookin’ on the BBQ

While Spring has yet to come here, the rainy days are giving me some time to think about the future of Sabayon and summarize what’s been done during the last months.

donations

As far as I can see, donations are going surprisingly well. The foundation has now enough money (see the pledgie.com campaign at sabayon.org) to guarantee 24/7 operations, new hardware purchase and travel expenses for several months. Of course, the more the better (paranoia mode on) but I cannot really complain, given that’s our sole source of funds. Here is a list of stuff we’ve been able to buy during the last year (including prices, we’re in the EU, prices in the US are much lower, sigh):

  • one Odroid X2 (for Sabayon on ARM experiments) – 131€
  • one PandaBoard ES (for Sabayon on ARM experiments) – 160€
  • two 2TB Seagate Barracuda HDDs (one for Joost’s experiments, one for the Entropy tinderbox) – 185€
  • two 480GB Vertex3 OCZ SSDs for the Entropy tinderbox (running together with the Samsung 830 SSDs in a LVM setup) – 900€
  • one Asus PIKE 2008 SAS controller for the Entropy tinderbox – 300€
  • other 16GB of DDR3 for the Entropy tinderbox (now running with 64G) – 128€
  • mirror.de.sabayon.org @ hetzner.de maintenance (33€/mo for 1 year) – 396€
  • my personal FOSDEM 2013 travel expenses – 155€

Plus, travel expenses to data centers whenever there is a problem that cannot be fixed remotely. That’s more or less from 40€ to 60€ each depending on the physical distance.
As you may understand, this is just a part of the “costs”, because the time donated by individual developers is not accounted there, and I believe that it’s much more important than a piece of silicon.

monthly releases, entropy

Besides the money part, I spent the past months on Sabayon 11 (of course), on advancing with the automation agenda for 2013. Ideally, I would like to have stable releases automatically produced and tested monthly, and eventually pushed to mirrors. This required me to migrate to a different bittorrent tracker, one that scrapes a directory containing .torrents and publishes them automatically: you can see the outcome at http://torrents.sabayon.org. Furthermore, a first, yet not advertised, set of monthly ISO images is available on our mirrors into the iso/monthly/ sub-directory. You can read more about them here. This may (eheh) indicate that the next Sabayon release will be versioned something like 13.05, who knows…
On the Entropy camp, nothing much has changed, besides the usual set of bug fixe, little improvements and the migration to an .ini-like repositories configuration files syntax for both Entropy Server and Client modules, see here. You may start realizing that all the good things I do are communicated through the devel mailing list.

leh systemd

I spent a week working on a Sabayon systemd system to see how it works and performs compared to openrc. Long story short, I am about to arrange some ideas on making the systemd migration come true at some point in the (near) future. Joost and I are experimenting with a private Entropy repository (thus chroot) that’s been migrated to systemd, from openrc. While I don’t want to start yet another flamewar about openrc vs systemd, I do believe in science, facts and benchmarks. Even though I don’t really like the vertical architecture of systemd, I am starting to appreciate its features and most importantly, its performance. The first thing I would like to sort out is to be able to switch between systemd and openrc at runtime, this may involve the creation of an eselect module (trivial) and patching some ebuilds. I think that’s the best thing to do, if we really want to design and deploy a migration path for current openrc users (I would like to remind people that Gentoo is about choice, after all). If you’re a Gentoo developer that hasn’t been bugged by me yet, feel free to drop a line to lxnay@g.o (expand the domain, duh!) if you’re interested.

Thanks, it’s time to push Sabayon farther

I want to take take a few moments from my deserved Christmas break to say thanks to all the donors who have contributed to our last fundraiser. After 1.5 years, we’ve been able to hit our €5000 goal. This is a big, I mean really big, achievement for such a small (I am not sure now) but awesome distro like ours.

We’ve always wanted to bring Gentoo to everyone, make this awesome distro available on laptops, servers and of course, desktops without the need to compile, without the need of a compiler! It turns out that we’re getting there.

So, the biggest part of the “getting there” strategy was to implement a proper binary package manager and starting to automate the distro development, maintenance and release process.
Even though Entropy is in continuous development mode, we’ve got to the point that it’s reliable enough. Now, we must push Sabayon even farther.

Let me keep the development ideas I had for a separate blog post and tell you here what’s been done, what we’re going to do and what we still need in 2013.

First things first, last year we bought a new and shiny build server, which is kindly hosted by the University of Trento, Italy, featuring a Rack 2U dual Octa Opteron 6128, 48GB RAM and, earlier last year,
2x240GB Samsung 830 SSDs. In order to save (a lot of) money, I built the server myself and I spent something like 2500€ (including the SSDs). Take into consideration that prices for hardware in the EU are much higher than in the US.

Now we’re left with something like 3000€ or more and we’re planning to do another round of infra upgrades, save some money for hardware replacement in case of failures, buy t-shirts and DVDs to give out at local events, etc.

So far, the whole Sabayon infrastructure is spread across 3 Italian universities and TOP-IX (see at the bottom of http://www.sabayon.org for more details) and consists of four Rack 1U servers and one Rack 2U.
Whenever there’s a problem, I jump on a car and fix issues myself (like PSU, RAM, HDD/SSD failures) or kindly delegate the task to friends living closer than me.

As you can imagine, it’s easy to suck 200-300€ whenever there’s a problem and while we have failover plans (to EC2), these come with a cost as well.
As you may have already realized, free software does not really come for free, especially for those who are actually maintaining it. Automation and scaling out across multiple people (individuals involved in the development of this distro) are the key, and in particular the former, because it reduces the “human error” impact on the whole workflow.

As I mentioned above, I will prepare a separate blog post about what I mean with “automation”. For now, enjoy your Christmas holidays, the NYE celebrations and why not, some gaming with Steam on Sabayon.

UEFI and UEFI SecureBoot + Linux, is the nightmare over?

During the last weeks, I spent several nights playing with UEFI and its extension called UEFI SecureBoot. I must admit that I have mixed feelings about UEFI in general; on one hand, you have a nice and modern “BIOS replacement” that can boot .efi files with no need for a bootloader like GRUB, on the other hand, some hardware, not even the most exotic one, is not yet glitch-free. But that’s what happens with new stuff in general. I cannot go much into detail without drifting away from the main topic, but surely enough, a simple google search about UEFI and Linux will point you to the problems I just mentioned above.

But hey, what does it all mean for our beloved Gentoo-based distro named Sabayon? Since DAILY ISO images dated 20121224, Sabayon can boot off UEFI systems, through DVD and USB (thanks to isohybrid –uefi) and, surprise surprise, with SecureBoot turned on!. I am almost sure that we’re the first Linux distro supporting SecureBoot out of the box (update: using shim!) and I am very proud of it. This is of course thanks to Matthew Garrett’s shim UEFI loader that is chainloading our signed UEFI GRUB2 image.

The process is simple and works like this: you boot an UEFI-compatible Sabayon ISO image off DVD or USB, if SecureBoot is turned on, shim will launch MokManager, that you can use to enroll our distro key, called sabayon.der and available on our image under the “SecureBoot” directory. Once you enrolled the key, on some systems, you’re forced to reboot (I had to on my shiny new Asus Zenbook UX32VD), but then, the magic happens.

There is a tricky part however. Due to the way GRUB2 .efi images are generated (at install time, with settings depending on your partition layout and platform details), I have been forced to implement a nasty way to ensure that SecureBoot can still accept such platform-dependent images: our installer, Anaconda, now generates a hardware-specific SecureBoot keypair (private and public key), then our modified grub2-install version, automatically signs every .efi image it generates with that key, which is placed into the EFI Boot Partition under EFI/boot/sabayon ready to be enrolled by shim at the next boot.
This is sub-optimal, but after several days of messing around, it turned out that it’s the most reliable, cleanest and easiest way to support SecureBoot after install without disclosing our private key we use to sign our install media. Another advantage is that our distro keypair, once enrolled, will allow any Sabayon image to boot, while we still allow full control over the installed system to our users (by generating a platform-specific private key at install time).

SecureBoot is not that evil after all, my laptop came with Windows 8 (which I just ripped off completely) and SecureBoot disabled by default and lets anyone sign their own .efi binaries from the “BIOS”. I don’t see how my freedom could be affected by this, though.

Secretly({Plan, Code, Think}) && PublishLater()

During the last years I started several open source projects. Some turned out to be useful, maybe successful, many were just rubbish. Nothing new until here.

Every time I start a new project, I usually don’t really know where I am headed and what my long-term goals are. My excitement and motivation tipically come from solving simple everyday and personal problems or just addressing {short,mid}-term goals. This is actually enough for me to just hack hack hack all night long. There is no big picture, no pressure from the outside world, no commitment requirements. It’s just me and my compiler/interpreter having fun together. I call this the “initial grace period”.

During this period, I usually never share my idea with other people, ever. I kind of keep my project in a locked pod, away from hostile eyes. Should I share my idea at this time, the project might get seriously injured and my excitement severely affected. People would only see the outcome of my thought, but not the thought process itself nor detailed plans behind it, because I just don’t have them! Besides this might be both considered against any basic Software Engineering rules or against some exotic “free software” principles, it works for me.

I don’t want my idea to be polluted as long as I don’t have something that resembles it in the form of a consistent codebase. And until that time, I don’t want others to see my work and judge its usefulness basing on incomplete or just inconsistent pieces of information.

At the very same time, writing documents about my idea and its goals beforehand is also a no-go, because I have “no clue” myself as mentioned earlier.

This is why revision control systems and the implicit development model they force on individuals are so important, especially for me.
Giving you the ability to code on your stuff, changes, improvements, without caring about the external world until you are really really done with it, is what I ended up needing so so much.
Every time I forgot to follow this “secrecy” strategy, I had to spend more time discussing about my (still confused?) idea on {why,what,how} I am doing than coding itself. Round trips are always expensive, no matter what you’re talking about!

Many internal tools we at Sabayon successfully use have gone through this development process. Other staffers sometimes tell things like “he’s been quiet in the last few days, he must be working on some new features”, and it turns out that most of the times this is true.

This is what I wanted to share with you today though. Don’t wait for your idea to become clearer in your mind, it won’t happen by itself. Just take a piece of paper (or your text editor), start writing your own secret goals (don’t make the mistake of calling them “functional requirements” like I did sometimes), divide them into modest/expected and optimistic/crazy and start coding as soon as possible on your own version/branch of the repo. Then go back to your list of goals, see if they need to be tweaked and go back coding again. Iterate until you’re satisfied of the result, and then, eventually, let your code fly away to some public site.

But, until then, don’t tell anybody what you’re doing! Don’t expect any constructive feedback during the “initial grace period”, it is very likely that it will be just be destructive.

Git, I love ya!

Equo code refactoring: mission accomplished

Apparently it’s been a while since my last blog post. This however does mean that I’ve been too busy on the coding side, which is what you may prefer I guess.

The new Equo code is hitting the main Sabayon Entropy repository as I write. But what’s it about?

Refactoring

First thing first. The old codebase was ugly, as in, really ugly. Most of it was originally written in 2007 and maintained throughout the years. It wasn’t modular, object oriented, bash-completion friendly, man pages friendly, and most importantly, it did not use any standard argument parsing library (because there was no argparse module and optparse was about to be deprecated).

Modularity

Equo subcommands are just stand-alone modules. This means that adding new functionality to Equo is only a matter of writing a new module, containing a subclass of “SoloCommand” and registering it against the “command dispatcher” singleton object. Also, the internal Equo library has now its own name: Solo.

Backward compatibility

In terms of command line exposed to the user, there are no substantial changes. During the refactoring process I tried not to break the current “equo” syntax. However, syntax that has been deprecated more than 3 years ago is gone (for instance, stuff like: “equo world”). In addition, several commands are now sporting new arguments (have a look at “equo match” for example).

Man pages

All the equo subcommands are provided with a man page which is available through “man equo-<subcommand name>”. The information required to generated the man page is tightly coupled with the module code itself and automatically generated via some (Python + a2x)-fu. As you can understand, maintaining both the code and its documentation becomes easier this way.

Bash completion

Bash completion code lives together with the rest of the business logic. Each subcommand exposes its bash completion options through a class instance method called “list bashcomp(last_argument_str)”, overridden from SoloCommand. In layman’s terms, you’ve got working bashcomp awesomeness for every equo command available.

Where to go from here

Tests, we need more tests (especially regression tests). And I have this crazy idea to place tests directly in the subcommand module code.
Testing! Please install entropy 149 and play with it, try to break it and report bugs!

Equo rewrite, Sabayon 10 and Google

The following month are expected to be really exciting (and scary, eheh), for many reasons. Explanation below.

My life is going to rapidly change in roughly one month, and when these things happen in your life, you feel scared and excited at the same time. I always tried to cope with these events by just being myself, an error-prone human being (My tech. English teacher doesn’t like me to use “human being”, but where’s the poetry then!) that always tries to enjoy life and computer science with a big smile on his face.

So, let’s start in reverse order. I have the opportunity to do the university internship at Google starting from October, more precisely at Google Ireland, which is located in Dublin. I think many of the Googlers had the same feelings I currently have before me, scared and excited at the same time, with questions like “do I deserve this?”, “am I good enough?”. As I wrote above, the only answer I have found so far is that, well, it will be challenging but, do I like boredom after all? Leveraging on professionality and humbleness is probably what makes you a good team-mate all the time. Individuals cannot scale up infinitely, that is why scaling out (as in team work) is a much better approach.

It’s been two years since I started working at Weswit, the company behind the award-winning Lightstreamer Push technology, and next month is going to be my last one there. Even though, you never know what will happen next year, once back from the internship at Google. Sure thing is, I will need a job again, and I will eventually graduate (yay!).
So yeah, during the whole University period, I kept working and besides it’s been tough, it really helped me out bidirectionally. In the end, I kept accumulating real-world expertise during this time.
Anything in my life has been risk-free, and I took the risk of leaving a great job position to pursue something I would have regretted for the rest of my life, I’m sure. On the other hand, I’m sure that at the end of the day, it will be a win-win situation. Weswit is a great company, with great people (that I want to thank for the trust they gave me) and I’m almost sure that the next one might not be my last month there (in absolute terms I mean). You never know what is going to happen in your life, and I believe there’s always a balance between bad and good things. Patience, passion and dedication is the best approach to life, by the way.

Before leaving for Dublin, we (as in the Sabayon team) are planning to release Sabayon 10. improved ZFS support,  improved Entropy & Rigo experience (all the features users asked me about have been implemented!), out of the box KMS improvements, BFQ iosched as default scheduler (I am a big fan of Paolo Valente’s work) a load of new updates (from the Linux kernel to X.Org, from GNOME to KDE through MATE) and if we have time, more Gentoo-hardened features.

Let me mention here one really nice Entropy feature I implemented last month: Entropy adopted SQLite3 as its repository model engine since day one (and it’s been a big win!), even though, the actual implementation has been always abstracted away so that upper layers never had to deal with it directly (and up to here, there is nothing exciting). Given that a file-based database, like SQLite is, is almost impossible to scale out [1], and given that I’ve been digging into MySQL for some time now, I decided it was time to write an entropy.db connector/adapter for MySQL, specifically designed for the InnoDB storage engine. And 1000 LOC just did it [2]!

As you may have seen if you’re using Sabayon and updating it daily, Entropy version has been bumped from 1.0_rcXXX to just XXX. As of today though, the latest Entropy version is 134. It might sound odd or even funny, but I was sick of seeing that 1.0_rc prefix that was just starting to look ridiculous. Entropy is just about continuous development and improvement, when I fully realized this, it was clear that there won’t be any “final”, “one-point-oh” and “one-size-fits-all done && done” version, ever. Version numbers have been always overrated, so f**k formally defined version numbers, welcome monotonically increasing sequences (users won’t care anyway, they just want the latest and greatest).

I know, I mention “Equo rewrite” in the blog post title. And here we go. The Equo codebase was one of the first and long living part of Entropy I wrote, some of the code is there since 2007, even though it went through several refinement processes, the core structure is still the same (crap). Let me roll back the clock a little bit first, when the Eit codebase [3] replaced old equo-community, reagent and activator tools, it was clear that I was going to do exactly the same thing with the Equo one, thus I wrote the whole code in an extremely modular way, to the point that extra features (or “commands” in this case) could be plugged in by 3rd parties without touching the Eit kernel at all. After almost one year, Eit has proven to be really powerful and solid to the extent that now, its architecture is landing into the much more visible next-gen Equo app.
I tell you, the process of migrating the Equo codebase over will be long. It is actually one of many background tasks I usually work on during rainy weekends. But still, expect me to experiment with new (crazy, arguable, you name it) ideas while I make progress on this task. The new Equo is codenamed “Solo”, but it’s just a way to avoid file names clashing while I port the code over. You can find the first commits on the entropy.git repo, under the “solo” branch [4].

Make sure to not miss the whole picture: we’re a team and Sabayon lives on incremental improvements (continous development, agile!). This has the big advantage that we can implement and deploy features without temporal constraints. And in the end, it’s just our (beloved) hobby!

[1] imagine a web service cluster, etc — I know, SQL in general is known for not scaling out well without sharding or other techniques, but this is outside the scope of this paragraph, and I think NoSQL is sometimes overrated as well.
[2] http://git.sabayon.org/entropy.git/tree/lib/entropy/db/mysql.py
[3] Eit is the server-side (and community-repo side) command line tool, “Eit” stands for “Entropy Infrastructure Toolkit” and it exposes repo management in a git-like fashion.
[4] http://git.sabayon.org/entropy.git/log/?h=solo

Sabayon on Amazon EC2

During the last week, while I was enjoying my vacations, I’ve also had a lot of fun preparing a new EC2-friendly kernel (and sources) based off our kernel git repo (which is based on Linus’ kernel tree + some patches like the BFQ scheduler, fbcondecor and aufs3).

The outcome of my puzzle game (trying to figure out why an instance doesn’t boot on EC2 is like solving puzzles at times) is that sys-kernel/ec2-sources and sys-kernel/linux-ec2 (precompiled binaries) are now available on the sabayon-distro overlay and the Sabayon Entropy repository “sabayonlinux.org”.

As you may expect, I rapidly started to get bored again. For this very simple reason, and since I always wanted to have a fallback website/webservices infra ready on EC2 (in case of a disaster) I started cooking an EBS baked AMI, copycating the current Virtual Machines snapshots from our backup server.

As you may expect, I rapidly started to get bored once again. So, I prepared a molecule .spec file that automatically creates a ready-to-go ext4-based Sabayon Server filesystem image tarball ready to be dumped into a spare EBS volume. Once you have an EBS volume you just need to snapshot it and create the AMI from there (fyi).

As you may expect, I was getting bored of course. So I started preparing a “BuildBot” AMI that could be launched programmatically (say, from a cronjob) and once started (@reboot cronjob target is <3), attaches an existing EBS volume containing a Sabayon chroot, runs equo update && equo upgrade and other stuff, then detaches the volume, makes a snapshot, creates a versioned AMI.
Yes, boring stuff deserve a lot of bash scripting, can’t be otherwise. In this way, I can continuosly build updated Sabayon AMIs for EC2 without much human intervention (of course the BuildBot AMI mails back to me the upgrade result (both stderr and stdout)).
If anybody is interested in my “BuildBot” scripts, just drop a line here.

I don’t know yet where to go from here, but you may be interested in reading this wiki entry: “Sabayon on EC2“. Moreover, you may be also interested in knowing that the aforementioned filesystem image tarballs are already available on Sabayon mirrors, inside the iso/daily directory.

You can have a look at the currently available Sabayon AMIs here:

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