I must admit being away from GNU/Linux desktops’ evolution dealing everyday with CentOS and Ubunutu 10.4 via CLI. Distributions that, anyway, are far away from the frantic evolutions in terms of desktop environment UX provided by the most up-2-date trends.
But I’m preparing a virtual machine for a bioinformaticians’ post PhD course and we choose a modern distro for this. Given my skills and experience the choice went over Fedora.
So I’m playing a little around to see how the Gnome Shell behaves and decided, since I have some spare time, to customize it a little. I could not ever imagined in my wildest dreams that modifing GDM login screen would be such a PITA.
Luckily enough a 2010’s post from Alvin T. Enguillo is still the easiest method (and with this I’ve said it all if you read the article) to achieve this goal.
So, do you like the result?
It’s being some month now that at work we have encountered a nasty problem with Perl’s module Compress::Zib usage in a tool developed by a colleague. At the moment to start the graphical rendering of a web page the system gave error to our users.
Searching in Apache2’s log I’ve encoutered many error of this kind:
dualvar is only available with the XS version of Scalar::Util at /var/www/html/$MY-APP-PATH/perl/Compress/Zlib.pm line 8
This is because the Scalar-List-Utils module precompiled in RHEL/Fedora/CentOS and similar does NOT have the support of XS weaken function.
You will see a lot of bugs issued on this topic in this part of Linux distro’s.
My solution was to install perl-Task-Weaken package:
In fact as we can read in the package’s description:
rpm -qi perl-Task-Weaken
URL : http://search.cpan.org/dist/Task-Weaken/
Summary : Ensure that a platform has weaken support
Description : One recurring problem in modules that use Scalar::Util's weaken function is that it is not present in the pure-perl variant.
This restores the functionality testing to a dependency you do once in your Makefile.PL, rather than something you have to write extra tests for each time you write a module.
Lately at work I had to struggle a bit with the recovery of a personal workstation. Once very powerful nowadays with the dead of some of it’s disk, the subsequent loss of any RAID functionality (investing in IDE drives doesn’t make sense), and it’s “low” 1.5GB of RAM it’s just enough for some basic uses.
Unfortunately there has been an issue with the drive that resulted in (a near) complete data loss.
It was time to reinstall it, but default procedures failed. Ubuntu, Fedora, CentOS … ALL of them gave me an issue. Then I remembered how Promise RAID chipset on main motherboard had bad comments at the time, many regarding the poor implementation of RAID drivers.
So I’ve entered the BIOS of it’s motherboard (an Asus P4B533-E model) and disabled all internal support to raid.
Then I’ve booted my Fedora 15 DVD and at the prompt I gave the
command, disable so any fake RAID in the motherboard or RAID controller BIOS so that it acts as a normal controller.
BAM! It worked!
I am in the middle of the work for a GNU/Linux keynote & hands-on demo for some colleagues.
Since I’m a loyal Fedora/CentOS user I’m installing the latest Fedora 15 on my MacBook’s VirtualBox.
Everything went ok during the installation until first reboot on which the system told me:
FATAL: INT18: BOOT FAILURE"
remaining into the error mode and forcing me to manually reboot.
If this happens to you too be sure to check if the installation media (the cd-rom or the dvd-rom) is still present in the player (!!!) and remove it.
It happears to be a know issue with VirtualBox, since a bug #2680 was opened 3 years ago and still unresolved (probably because it’s unclear if it’s VirtualBox or Fedora dvd boot system fault).
Ejecting the optical media solved my issue, cheers!