Con la versione 5.12 di perl sembra che le cose procedano in maniera più spedita non solo per il linguaggio in se, ma anche per la realizzazione degli ebuild per Gentoo Linux.
La release candidate 5 di perl 5.12 è già disponibile nel relativo overlay, grazie a qualche volontario che non finiremo mai di ringraziare. ;-)
Se avete una macchina non di produzione che vi avanza, è ora di provare l'upgrade!
Molti moduli Perl sono, almeno da me, dati per scontati, nel senso che si utilizzano così di frequente che ormai sono come parte del linguaggio stesso. In realtà si tratta di interessanti progetti per semplificare le attività di ogni giorno, per i quali è opportuno scrivere qualche riga non solamente "celebrativa", ma utile a chi non li conoscesse.
Uno di questi moduli è Path::Class, di Ken Williams, utilizzato per la gestione dei file utilizzati da un'applicazione. Esso offre alcuni vantaggi rispetto alle funzioni core di Perl:
Sabato 28 Novembre 2009 si terrà a Udine l' Open Source Day, giornata dedicata a chi si avvicina al mondo dell'open source. Lo spirito è simile a quello del Linux Day, solo che... non si parla solo di Linux. ;-)
Sarà anche l'occasione, nel percorso avanzato, per parlare un po' di Perl. L'intervento non avrà comunque taglio particolarmente tecnico, ma sarà "introduttivo con la giusta dose di filosofia" (spero, visto che lo sto ancora preparando...). In definitiva, spero sarà una cosa piacevole per il pubblico. :-)
Accorrete dunque in massa all'Open Source Day! Oltre al mio intervento, ce ne sono altri alquanto interessanti. Il programma completo è disponibile qui.
È da un po' di tempo che mi riprometto di scrivere qualche riga in italiano a proposito di ack. Benché sia disponibile in molte distribuzioni Linux, questo software non è ancora così largamente conosciuto dagli utenti.
Si tratta di un sostituto, alquanto migliorato, del noto comando grep disponibile in pratica su ogni Unix esistente. I vantaggi consistono in una serie di feature aggiuntive, e in una configurazione di default che fa quasi sempre "ciò che si desidera" (con grep, infatti, è spesso scontato dovergli passare una serie di flag per farlo comportare come ci si aspetta).
Ispirandomi alla lista indicata sul sito ufficiale, ecco un po' di ragioni per utilizzare ack:
Per installarlo, scaricatelo dal sito ufficiale o, se usate Linux, cercatelo tra i pacchetti della vostra distribuzione. Ad esempio su Gentoo esiste l'ebuild ack, mentre su Ubuntu/Debian è presente il pacchetto ack-grep.
Gentoo has been in a curious situation regarding Perl lately: for instance, the 5.10.1 version appeared in the Portage tree only a couple fo weeks ago (which would have been fine if there had been a 5.10.0 in the tree, but it was still stuck to 5.8.x). For the adventurous 5.10.0 was, however, available in the Perl overlay.
Why did it take so long for inclusion in Portage?
First of all, there's the usual problem of flie conflicts due to "dual-lifed" modules (those which live both in their own distribution/ebuild and in the Perl distribution): if they only have library files that's fine (the ones coming with the perl distribution go in /usr/lib/perl/, the ones installed via ebuilds go in /usr/lib/perl/vendor_perl which has @INC precedence). However, some modules (such as Encode) install files in /usr/bin as well and, since they're core, there's a file clash. Add to this that different perl version have different core modules and you're in a mess. This issue is still not fully solved and is one of the reasons the perl-5.10.1 ebuld in portage is both unmasked and without keywords (which is a way to say to users: be very aware).
A second problem is that a version shift of Perl tends to break a lot of packages (fex. inkscape had problems), which should be checked. This leads directly to the third problem: the Gentoo Perl herd is quite understaffed, and is seeking help. Luckily, we have tove++ who copes with the important things. Finally, perl 5.10.0 has many problems of its own which made things worse - it was actually not a good idea to include in (unpatched) in any distribution.
Said this, 5.10.0 does work quite well on Gentoo once you finish going through the upgrade process, which in some cases involves complete removal of perl 5.8.x and then installation of 5.10.1. One of the good things is that perl-cleaner, now at version 2.0, is much improved and works well in rebuilding modules and depending packages.
Regarding the modules, there's some progress. g-cpan is no longer a recommended way to automatically build Perl module ebuilds, and most of the work is now done by hand: more than 900 ebuilds (including modern things such as Moose and DBIx::Class) are directly available in the main Portage tree and regularly updated. Another 430 (including Catalyst and many modules related to it) can be found in the Perl Overlay: we try to keep these regularly updated as well.
There are also some attempts to new tools for automatic ebuild generation of Perl modules and dependencies, such as CPANPLUS::Dist::Gentoo. These efforts could help Gentoo become the best operating system for Perl which, because of the ebuild structure, might seem like an obvious achievement.
The Perl Overlay also has a parrot-scm branch, where, if you feel you want to code Perl 6, you can find rakudo.
So, as you can see there's a lot going on in the Gentoo world regarding Perl. There's however, a need for people who use Gentoo and have some spare time to help with all of this. If you love this distribution and there's something you want to do, show up in #gentoo-perl on Freenode.
xfce4 is a lightweight (compared to Gnome and KDE) which I happen to love, as it still provides nice theming, a well-done panel system and some interesting goodies. The window manager (xfwm4) is not handy as others. xmonad is, however, a great one, in particular: tiling, highly customizable and... written and extendable in Haskell!!! So, it makes up for a good replacement.
I decided to change xfce's window manager and use xmonad. The thing required a few steps in order to begin working properly. Here's a tutorial which presumes you use the following software versions:
xfce 4.6.1
xmonad 0.8.1
gmrun 0.9.2
dmenu 4.0
This is a screenshot of how it's going to look like.
I also assume you have a working xfce4 installation and you're able to login to the xfce desktop with an account (by the way, I suggest slim as login manager).
First of all, you need to emerge xmonad (after unmasking it in /etc/package.keywords):
emerge -av xmonad xmonad-contrib
xfce configuration
The first thing is to properly configure xfce. My suggestion is to open the Desktop settings dialog box and, in the Icons tab, uncheck all default icons: it's a tiling window manager, and having icons around will only leave a box containing them which is going to look weird. You're not migrating to a tiling window manager to use desktop icons, aren't you? ;-)
Switching from xfwm4 to xmonad is a bit tricky, as xfce4 doesn't support (like Gnome and KDE do) configuring the window manager at all, and xmonad doesn't support the session protocol (so we must ensure that xmonad is started every time we log in). So, just login with your account, open a terminal and then terminate xfvwm4 while launching xmonad:
kill `pidof xfvm4` && xmonad &
The window manage should be replacing (you'll notice your windows tiling). At this point exit xfce4 saving the session: this will ensure xmonad is started again when you log back in. Problem is xfce will also try to start xfvwm4: to avoid this you have to locate you session file in ~/.cache/sessions and remove the entry for xfvwm4.
At this point you should be able to login again and xmonad will be your new default window manager.
xmonad configuration
xmonad needs a some tweaking to play well with xfce, and also to be more usable on its own.
Looking into you ~/.xmonad directory you'll find a xmonad.hs file which is used to compile xmonad (the xmonad-x86_64-linux binary in the same directory, with the name changing depending on your arch) when starting it for the first time. The configuration file is in Haskell, so it might look a bit weird if you haven't seen the language before. The instruction given below might vary if you xmonad.hs is a bit different, or if you already customized it somehow.
First of all, we need to ensure xmonad properly manages the xfce4 panels (I have one, at the bottom), by placing them where you expect them to be, by making them visible in all workspaces and by avoid application windows to overlap them. Add this line after the other import ones:
import XMonad.Hooks.ManageDocks
Locate the:
myLayout = tiled ||| Mirror tiled ||| Full
and change it to:
myLayout = avoidStruts(tiled ||| Mirror tiled ||| Full)
Then locate:
myManageHook = composeAll
[ className =? "MPlayer" --> doFloat
, className =? "Gimp" --> doFloat
, resource =? "desktop_window" --> doIgnore
, resource =? "kdesktop" --> doIgnore ]
and replace it with the following code. It's actually a small change but I chose to create an extra variable for the sake of clarity.
stockManageHook = composeAll
[ className =? "MPlayer" --> doFloat
, className =? "Gimp" --> doFloat
, resource =? "desktop_window" --> doIgnore
, resource =? "kdesktop" --> doIgnore ]
myManageHook = manageDocks <+> stockManageHook
Now that we ensured the panels get a proper placement, we'd better change the default xmonad mod key: the default left Alt conflicts with the shortcuts of many applications, including xfce terminal, firefox, and others. Luckily, we have an otherwise almost useless "Windows start" key on the left of the keyboard; to use that as mod key find this line:
myModMask = mod1Mask
and change it to:
myModMask = mod4Mask
I suggest you delete the binary inside the .xmonad directory before logging back in, in order to ensure it's compiled again.
additional software
In its default configuration, xmonad provides key binding for a couple of useful softwares.
gmrun (mod+shift+p) opens a small text box where you can enter the name of a command to launch. You can also use xfce's own "Run program..." feature of course.
dmenu(mod+p) opens a nice menu bar (at the top by default) which lists what you have in /usr/bin (by default) and can be used to launch programs by just typing a few letters and navigating the list. Very handy.
Well, that's it: you should have everything working now. Exercise your hands and fingers for xmonad. ;-)
My Linux distribution of choice - and, consequently, my operating system of choice - is Gentoo. However, from time to time I'm getting requests from customers to install some Linux servers or desktop computers in their places. Gentoo takes a lot of effort for an in-place installation and a)I don't have the time for that b)the customer won't pay for all that time anyway.
Ultil recent times, I used to install Slackware - which I like a lot because it's simple and clean. However, there are always been things which I didn't like in Slackware: lack of a dependency resolution system in the package manager, impossibility to upgrade the system without actually destroying it, and some weird Pat's choices. Moreover, Pat recently dropped Gnome support from mainline Slackware, and Gnome is precisely the desktop environment I use and install.
So I decided to grab all the relatively well-known distributions and to test them out. I tried CentOS, Fedora, Ubuntu, and many others - but they were all really too bloated in my opinion. I then decided to give Arch a try, as I heard good words about it around the internet and... bingo, I found what I was looking for!
Arch is, basically, as clean as Slackware (if not cleaner), but provides a great package manager with a dependency resolution system. It's also easy to update your system, and there's a nice policy for the updating of configuration files (even though probably not as advanced as Gentoo's). Also, the community is big (and growing), and very helpful.
I liked Arch so much that I decided to install it on my laptop. So now I'm half a Gentoo and half an Arch Linux user. I just hope to find time to contribute to both projects somehow. ;-)
Here's a screenshot of my development desktop: since it's 1600×200, click on it in order to see the larger picture, or you'll understand nothing.
Getting the 1600×1200 on my development machine was (is?) quite a pain: at first I needed to change my video card as the (very) old ATI one wasn't able to handle this resolution properly. After the change, my PC begun powering-off at random, and it seems the problem is the Nvidia video card. So, now I have another ATI (newer but lacking great performance) and I still need to dig into this. Fun, uh?
