I’ve been really busy these days, mainly working as consultant you know, but things are moving in the right direction now. Apart from the usual Entropy work, I finally had the time to rewrite Gentoo slow-as-hell Eselect OpenGL module in this way:
- I removed Portage dependency
- I embedded all the needed general purpose functions
- I avoided the usage of ldconfig (since the new tool will be used only on the Live environment, there’s no need to overload the boot procedure by regenerating ld.so.cache for just few new libraries – /usr/lib/opengl/{ati,nvidia,xorg-x11}) and used the old dear LD_LIBRARY_PATH in /etc/env.d/o3opengl and /etc/profile.env (another dirty but powerful trick to avoid running env-update – that’s really unoptimized).
With the new tool, called opengl-activator and carried by sabayonlive-tools 1.6.0, Live boot will just take 1-2 minutes less. Yeah, MINUTES! So, all this new stuff, along with the performance improvements suggested by Daniel Robbins will be included in the upcoming 3.4F release.
Apart from that, we’re working on the miniEditions and on the new Business Editions. Please be patient.
The actual Sabayon Linux:
Day #1: you install Sabayon Linux Core
Day #1, 1 hour later: you decide that you need XOrg and KDE.
Day #3 (or 4, or 5, depending on your hardware): XOrg and KDE are finally installed. You are getting bored.
Day #4: You’re sick of it. And decide to get rid of all this graphical garbage. Gosh, Portage does not actually have reverse dependencies handling. Ok, not a big problem, some docs and patience and you get what you need. Time spent: well, not just 5 minutes.
The future Sabayon Linux:
Day #1: you install Sabayon Linux Core
Day #1, 1 hour later: you decide that you need XOrg and KDE.
Day #1, 20 minutes later: XOrg and KDE are finally installed. You are getting bored.
Day #2: You’re sick of it. And decide to get rid of all this graphical garbage. Yay, Equo does support reverse dependencies handling! So, you decide to remove kde-meta first. Ok, then you realize that XOrg may be fine if used with Fluxbox and decide to just rip away every package that depends on kdelibs. Oh, Equo can do it too, awesome!
Read more…
It’s funny to see that all Gentoo users and developers think that we are using ~arch keyword to build packages. Ahh, you never opened our make.conf, don’t you?
Oh, another funny thing is that they think our Installer is slow. Never tried Anaconda, heh?
These things make me happy! Another great day… 
Yeah, the first one, will be our future binary packages manager, like apt is for debian and yum is for RedHat/FC. It just takes the best from these worlds and the best from Gentoo bringing you to a revolutionary experience. Well, it’s starting to do some real stuff. Like, syncing the repository, do searches inside the repository and local database, download packages, installing them, syncing with Gentoo /var/db/pkg directory and so on. There are still a lot of missing things but you know, when you build a building, the hardest part are the foundations. We have it, and they start to work really well. So, I think that we’re perfectly on track.
Have a look at this screenshot, I was trying to install Fluxbox on a Core Install, pulling in all the missing packages.
So, what’s Spritz then? Easy one. Take YumEx and get it working on Sabayon with Entropy.
Well, to sum up, we’ll have a binary package manager perfectly compatible with Gentoo (it’s up to you) that uses gentoo naming conventions and will let you install our optimized openoffice package (not -bin) in just few seconds. Can you realize it?
