Planet Sabayon Linux

In these days, there’s something that attracted my attention: Compiz.

We have been a Beryl-distro since the famous fork and we enjoyed being called that way just because, Beryl still rocks. Why? Even if Compiz has always held the stability crown, Beryl was distributors’ friendly. It is so easy to integrate it on the system, mostly because of its automagic. But anyway, after spending several hours to try to implement it in the best way, I have finally published desktop-acceleration-helpers 3.0, our own compiz and compiz-extra ebuilds (0.5.0-r1)! And about today? maybe ext4 …

I’m back! For sure! And still alive. Things are doing well and the vacation was good enough. Now it’s time to work back on Sabayon Linux. Me and Luca, started yesterday with the yet in-progress forum reorganization. I’ve implemented the required subforums mod for phpBB and now we are moving the section around. I also took the time to add some extra languages to it, as I have announced on the respective sections. About the releases, we are currently writing down the TODO list for the 3.4 release. I think that we’ll have a Loop 2 testing release in a matter of days (maybe one week). It just depends on the upcoming kernel release, 2.6.21. More in the next days guys. I still have to read all the e-mails that I received the past week, ugh!

Hello, I want to inform you all that I’ll be on vacation from tomorrow to the 23rd. Happy Sabayon!

player is a small yet very powerfull mplayer wrapper script, I love mplayer but I really hated the fact that everytime you start mplayer it starts a new mplayer process, so besides window resizing/relocating I have to close old mplayer window to replace it with the new one. What about subtitles and edl files ?? the script will search the current folder (till depth 2) for any file that matches the same movie name (with .srt or .sub extension)
You should read the script source code to understand how it works
player

A while ago I was tired of editing/commenting Window Managers in .xinitrc, So I decided to look for a way to start any Window Manager, switch between them using one command line, and also make sure that the command ’startx’ starts the last Window Manager used…

The idea goes like this, the real xinitrc file will be called something else (Personally I chose .Xinitrc), .xinitrc will be a symbolic link to .xinitrc-sessions/windowmanager, and .xinitrc-sessions/windowmanager is just a small file that goes like this:
#!/bin/sh
source $HOME/.Xinitrc


So when you call startx, .Xinitrc will be called, in .Xinitrc the Window Manager name will be concluded from the file which .xinitrc links to (in this case .xinitrc-sessions/windowmanager)

To make the task even easier, instead of creating .xinitrc-sessions/* and .xinitrc link, I created a small and simple bash script which will create all the required files/links needed to launch the Window Manager

example:
If I want to run fvwm, all I have to do is call:
$ xsession fvwm
I want to change to gnome, so
$ xsession gnome
and now, running:
$ startx

will launch gnome as it was the last Window Manager

Links:
.Xinitrc
xsession

I would like to inform you all that my e-mail is not a place to look for help. There is a forum, an IRC Channel, a Bugzilla. I can’t find the time to answer all the e-mails that I receive on a daily basis. Sorry.

Nah, it’s just a stupid song name. Don’t worry about that. While I’m massively/actively/asdasd (Luca can understand that) working on Entropy with very nice results (apart the needed code cleanup that will take place before the first public server release), we are uploading the first Public_Beta-aware(TM), 3.4 release, tagget Loop 1. In fact, the release cycle will, from now on, follow these steps:

1. Publish beta releases, called Loop + (incr. number: Loop 1, Loop 2, and so on) on BitTorrent, xdelta included, and on a dedicated server for our Core Beta Team only. Core Beta Team: it is a selected number of people that work beside me and Luca. They get releases earlier, can report issues faster and get more attention because they know how to do things (n00bs don’t, sorry.).
2. After the Loop sequence, the new release will be published on the Official Mirrors and on BitTorrent as usual.

We decided to do 3.4 just because Entropy still needs 2-3 months of active work and polishing. So, Sabayon Linux 3.4 Loop 1, will be published before the end of the week, and will contain our 2.6.21_rc5-git10 kernel release (we’ll prepare sabayon-source-2.6.21_rc6 ASAP), GNOME 2.18, VirtualBox 1.3.8, and all the fixes that would have been in 3.3.1 (never released).

Another thing that I should inform you is about my holidays! From the 16th to the 23rd of April the only thing that I will see is, sand, sea, and hopefully an amazing sunset. Yay!

Ok, that’s another knife hidden in our pocket. Smart Applications are coming! What are they? Well… I’ve just made a demo package that already works on all modern Gentoo based distributions and maybe even on Fedora and OpenSUSE. What are they (again!!!) ? Simple… One application, packaged into a compressed file with all the dependency tree included. Just like how applications work in Windows: unpack –> double click –> run!. That’s it! No hassles! If you have an AMD64 Sabayon install, just download Abiword from here, unpack and double click (from Konqueror or Nautilus) on the .exe files !

Amazing, isn’t it? That’s the hidden power of the upcoming Entropy server stack

Heeeeeeeeeeeere you goooooooooo test the our new sources from 2.6.21-rc5…it’s powerful indeed and many fixes should be in….check wireless drivers NOW WE REALLY HAVE ALMOST ANY CARD IN IT!!!!!
Let us know what you think

So, while my new freelance job in the IT world is starting to make some progresses, I would like to please you all by telling what happened this week in the Sabayon Linux world. I ( ) decided to shift the release plan of the 3.3.1 of one week, for two reasons:

- Me and Luca decided to put 2.6.21 kernel on it, with updated ATI drivers, DScape (mac80211) stack updates and so on. That’s a good thing after all.
- Entropy! I’m doing great progresses. Code is added at an incredible speed, I migrated all the Entropy database to SQLite and it’s damn fast, really! On my Athlon64 X2 workstation, a detailed query just takes about 0.040 seconds. Apart from that, I am re-syncing the packages on the Binary Host (the first of a set of public mirrors that will be managed by Entropy) currently the x86 ones, so, please be patient with your binmerge tool , it will take a while, it’s about 2,7Gb == 2019 packages.

Well, about Entropy, I’ve had another great idea, taken from the bad designed and distro-centric Klik. I’ve called them “smartapps” and they’re currently working nice even on Ubuntu and OpenSUSE. I don’t want to add much for the moment on that. Even because I have to solve one trouble with the “so-called” .desktop files, it seems that they do not support relative URIs properly, DAMN!. I manage to start to put the first brick of the Entropy client within the 15th of the current month. That will be a critical moment for the whole project: I hope to be able to manage all the reverse dependencies properly. You know, Portage sucks. Really, it’s the hard truth.

Also, I’ve added the support for two different branches, “stable” and “unstable”, all the packages in world (our, not Gentoo), will be marked as “stable” at each stable release. New package added to the database are always marked unstable and the end-user can enable the unstable branch just with some clicks.

In the end, if you would like to join us with this huge project or contribute to the World Domination, we would just need:

- A ssh-available 64bit PC with strong CPU power and >2Mbit/sec upload speed. Why? because I only have a sh***y 320kbit/sec DSL (in upload). Dudes, that’s the Italy…..
- Man power. We are looking for trustworthy packages maintainers.

Now, time to take a nap. See ya.