Monday, April 15, 2013

Third-Party Repositories for Mageia

The subject of third-party repositories is a touchy one for some people. For the maintainers of a distro, they feel that third-party repos cause compatibility problems and the packages are not subject to adequate Q&A. The third-party maintainers believe that they are maintaining either specially modified packages useful to their members or packages that the main distro cannot, for legal reasons, maintain and distribute. Both are correct.

If you need a package offered by a third-party repo, then by all means use it carefully. If not, don't even add the repos to your local repositories.

For Mandriva, the PLF at plf.zarb.org and MIB at PianetaLinux.org provided those services. For Mageia, it looks like BlogDrake.net is taking the lead.

You may add the appropriate repos as root using the commands below:

urpmi.addmedia --wget --distrib ftp://ftp.blogdrake.net/mageia/mageia2/x86_64
urpmi.addmedia --wget --distrib ftp://ftp.blogdrake.net/mageia/mageia2/i586 

urpmi.addmedia --wget --distrib ftp://ftp.blogdrake.net/mageia/mageia3/x86_64
urpmi.addmedia --wget --distrib ftp://ftp.blogdrake.net/mageia/mageia3/i586



If you want to learn more about adding third-party repositories, look at the Mageia Software Manual.

Tuesday, January 22, 2013

Mageia3 Vs. Fedora18




I recently compared the installation of Mageia3 with Fedora 18 (both done in a VirtualBox virtual machine). When installed and fully configured to taste, you have essentially the same level of usability and ease of administration with a similar choice of desktop environments and current versions of applications running on a recent kernel using SysV-style init and RPM packaging. The meaningful differences are more easily illustrated with some history, so this will not be the typical, dull, useless version-to-version comparison with a plethora of gratuitous screenshots and the inevitable inane jargon overload.

Fedora has been the community release of Red Hat since RHEL became the primary distro for Red Hat proper. It enjoys a more frequent release schedule than RHEL and is more focused on the desktop. Think of it as the development version of the workstation companion to the Enterprise version of Red Hat Linux taht is now in its 18th release. 

Mageia would seem to be a relative newcomer, only now in the beta of its third release, but its roots go back to Red Hat 5.x with the release of Mandrake 5.2. Mandrake was essentially a re-spin of Red Hat with better default configurations and an emphasis on the KDE desktop (RedHat has long been GNOME-centric). A great idea plagued with poor corporate leadership and even poorer corporate decision-making, Mandrake-come-Mandriva focused its development in three areas: its package manager, its administration tools and its volunteer community. Red Hat at the time still relied heavily on a text-based installer, RPM and linuxconf, all of which required more than a modicum of command-line mojo. RedHat were just beginning to develop admin tools written in Python. 

The Perl programming language was adopted by Mandrake, both because the initial cadre of developers were proficient in it and also as a way to differentiate themselves from Red Hat. As well, they would not be simply "improving" admin tools over which they did not have final control of the source code. It was a bold gamble that both benefited them and undermined their success as few other distros have adopted their tools. 

Red Hat through the years only begrudgingly accommodated their non-corporate user base and actively undermined them at times. For example, Red Hat's early incarnation of KDE was so heavily edited to make it less configurable and more GNOME-like (and better suited for a corporate workstation) that it elicited an uproar from KDE fans while documenting the Red Hat developer's overwhelmingly "not invented here" mentality (as evidenced by their scurrilous code comments). Fedora/Red Hat has always been a GNOME-centric distro because the limited configuration options of GNOME provide the best fit with their corporate workstation focus and because many GNOME developers work for Red Hat. Red Hat, in the name of "free software" also made their distro very multimedia unfriendly by not only not providing easy access to integrating less-than-free multimedia software, but by not compiling in support for them if you wished to add them on your own. Again, it was a more corporate-centric, IP attorney-friendly approach.

Many of the Red Hat/Fedora usability advances in package management and desktop ease-of-use were fomented by the loyal non-corporate user base. But this made the installation and configuration of a usable home desktop system and easily updatable system a nightmare of tedium, spawning alternatives like Mandrake and KRUD, Kevin's RedHat Uber Distribution, which provided a more friendly configuration and a way to deal with updates that addressed "Dependency Hell"; it was made obsolete by the eventual adoption of YUM as the RPM wrapper and the growth of the Fedora user community.

The Mandrake/Mandriva installer was steadily improving but idiotic corporate decisions were killing the distro: non-sensical acquisitions and pursuit of computer-aided training pillaged the start-up capital, but the user community was strong. Meanwhile, the RPM wrapper application URPMI and the user/administrator tools were coming along and Mandriva offered the broadest out-of-the-box hardware compatibility of any distro. Complicated configuration of things like X11, sound and printing were almost fiddle-free and automatic. However, Mandriva's choice of desktop and system graphics was uninspiring and almost child-like, certainly not as cutting-edge and sexy as the up and coming Ubuntu. 

Red Hat spun off the community version of Red Hat as Fedora Core, then as Fedora. A growing user-focused community sprang up to address it's usability shortcomings and has flourished. Mandriva corporate neglected its user community and as it approached bankruptcy for the second time, abandoned the desktop version of Mandriva to community users and departing employees under the auspices of Mageia. 

The official Mageia base install continues to demonstrate the ease-of-use "just works", broad hardware support, sane default configurations and a community-focused multimedia desktop. The official Fedora base install continues to demonstrate the corporate-focused minimalist approach Red Hat has traditionally taken to support their Enterprise version and, as always, a strong community effort continues to take up the slack and make it usable as a consumer desktop. 

Desktop-focused Mageia has finally stepped up its default look and feel to a polished, sophisticated and modern level while corporate-focused Fedora looks flat and clunky in comparison (still, Mageia could use some more sex appeal). The bottom line is a very different out-of-the-box experience. Mageia's installation, default configuration and usability all best Fedora. Still, you can wind up with a very usable  and essentially similar consumer desktop experience using either distro; Mageia just gets you there with less work and fuss. Overall, Mageia appears to have found it's raison d'ĂȘtre.


Saturday, December 29, 2012

My DropBox Experience

I have recently begun using Dropbox, being first introduced to it on my HTC Evo phone where it automatically syncs every picture I talk to my desktop PC.

There are some very cool things you can do with Dropbox and many sites around the Internet will clue you in (See the REFERENCES below). I'll concentrate on some things that are more Linux focused.

I'm a big fan of the Zim Desktop Wiki in that it helps me keep notes about specific configuration issues, tips, tricks and other useful info. But as designed, it is limited to a single desktop machine. I have several that I use, a few in remote locations. The solution? Zim keeps it's info in ~/Notes. Simply move the Notes directory into the ~/Dropbox directory and then symlink it back to ~. Now create the same symlink on every machine you use. Dropbox has now synced you Zim data to all your computers.

There are also a number of suggestions that you can do the same trick with ~/.mozilla. The only drawback I see is that you don't want to waste Dropbox space for the Cache files. Just keep the cache local by using about:config to change the value of browser.cache.disk.parent_directory to /tmp . Then you don't waste bandwidth or Dropbox storage on them.

You can only run one instance of Dropbox per user, but you may have multiple users on your system, each running their own personal instance with their own 2GB storage. Send each user an invitation so you get more free storage and let them set up their own dropbox accounts. Start the Dropbox daemon from rc.local like this:

su -user1 -c /home/user1/.dropbox-dist/dropboxd
su -user2 -c /home/user2/.dropbox-dist/dropboxd
etc.

While Windows users have problems trying to run Dropbox like this as a "service" such as need for Mac and windows users to stop the service to access the individual Dropbox management GUI, Linux has no such problems. When the user logs in, they will have a Dropbox icon in their tray and their files will be freshly synced.

While the tip to install portable Windows applications is nice, Linux users can keep shell scripts, custom config files, self-compiled software packages and so on for use anywhere.



REFERENCES
Get the Linux Dropbox Application
https://www.dropbox.com/install?os=lnx

32-bit
$ cd ~ && wget -O - "https://www.dropbox.com/download?plat=lnx.x86" | tar xzf -

64-bit

$ cd ~ && wget -O - "https://www.dropbox.com/download?plat=lnx.x86_64" | tar xzf -

Then run:

$ ~/.dropbox-dist/dropboxd

Get the command-line script:

$ wget https://www.dropbox.com/download/dropbox.py

Put it in ~/bin and chmod +x it. Use --help to see its options.


10 [More] Killer Dropbox Tips and Tricks
http://web.appstorm.net/roundups/data-management-roundups/10-more-killer-dropbox-tips-and-tricks/
Best Tip: Store security webcam pphotos for offsite recovery

20+ Advanced Dropbox Hacks
http://blog.storecrowd.com/dropbox-hacks/
Best Tip: Start bittorrent downloads from work

Cool Dropbox tips & tricks
http://www.droiddog.com/android-blog/2010/08/cool-dropbox-tips-tricks/
Best Tip: Install portable Windows applications

Technology Tuesdays: DropBox Tips & Tricks
http://www.glidemagazine.com/hiddentrack/technology-tuesdays-dropbox-tips-tricks/
Best Tip: Sync your saved games.

Wednesday, December 12, 2012

Installing XPaint on Mageia2

XPaint is a desktop image editing application with a long history. It is currently maintained by Jean-Pierre Demailly, who will shortly be releasing version 2.9.9.3.

There is no RPM package available for Magia2, so I thought I would compile it from the source code, but I ran into some problems. The first was that naming conventions between the source code and what Mageia provides differ.










The XPaint INSTALL file says the following libraries (plus their development libraries) are necessary to compile XPaint.

libX11
libXext
libXt
libXmu
libSM
libICE
libXp
libXpm
libz
libpng
libtiff
libjpeg
libopenjpeg


Naming conventions are always annoyingly problematic. Mageia provides:

libx11_6            libx11_6-devel
libxext6            libxext6-devel
libxt6              libxt-devel
libxmu6             libxmu6-devel
libsm6              libsm-devel
libice6             libice-devel
libxp6              libxp-devel
libxpm4             libxpm-devel
libzlib1            libzlib-devel
libpng12_0          libpng12-devel
libpng15_15         libpng-devel
libtiff5            libtiff-devel
libjpeg8            libjpeg-devel
libopenjpeg1        libopenjpeg-devel
libXaw3dXft         libXaw3dXft-devel

Plus, you'll need
libxft-devel

Since Mageia2 does not provide it, you will also need the libXaw3dXft-1.6.2b library provided by XPaint's Sourceforge page which you must compile first.

To install all the Mageia-provided dependencies,

$ sudo urpmi libx11_6 libx11_6-devel libxext6 libxext6-devel libxt6 libxt-devel libxmu6 libxmu6-devel libsm6 libsm-devel libice6 libice-devel libxp6 libxp-devel libxpm4 libxpm-devel libzlib1 libzlib-devel libpng12_0 libpng12-devel libpng15_15 libpng-devel libtiff5 libtiff-devel libjpeg8 libjpeg-devel libopenjpeg1 libopenjpeg-devel libxft-devel

This will install an additional 43 or so packages on a standard Mageia2 system.

Lets begin with libXaw3dXft. Unpack the sources, configure and compile.

NOTE: the default installation locations for both are in /usr/local; I prefer them in /usr.

In ~/libXaw3dXft/,

$ ./configure --prefix=/usr --enable-arrow-scrollbars
$ make
$ sudo make install

Now, we may compile the application in ~/xpaint-2.9.9.3/.

For me, there was a missing link to libXaw3dXft and Jean-Pierre kindly provided a fix (this may be fixed by the time you attempt this).

$ ln -s /usr/include/X11/Xaw3dxft ~/xpaint-2.9.9.3/xaw_incdir

Now we can compile XPaint in ~/xpaint-2.9.9.3/,

$ ./configure --prefix=/usr
$ make
$ sudo make install

Many thanks to Jean-Pierre Demailly for maintaining XPaint and for his generous assistance. If I can get motivated to learn a few new procedures, I might maintain an XPaint RPM for Mageia.




Jean-Pierre Demailly recently corresponded with this advice:

I forgot to mention (and that's probably hardly visible in the docs),
that it is advisable to compile libXaw3dxft with the options
  --prefix=/usr --enable-arrow-scrollbars
The instructions above have been modified to reflect this.- ed.
The second option provides arrow scrollbars that have a look and feel similar
to modern toolkits, and XPaint behaves better with them enabled.

(I'll make that option the default in the next release, but the libXaw3d
variant doesn't and I did not change that yet ...)

Sunday, November 06, 2011

Upgrade Mandriva 2010 to 2011

Part of the fun of Linux, for me at least, is the ability to fix things when they go wrong. And things generally go wrong when you don't follow the advice of conventional wisdom. Plus, my personal mantra is "fix it until it breaks".

One of those great pieces of common wisdom when discussing Mandriva is that you only upgrade within major versions, like from Mandriva 2010.1 to 2010.2, but when moving between major versions, like from Mandriva 2010 to 2011, you do a clean install.

If you have followed other convention wisdom, you have a separate physical partition for /home. With that configuration in place, you can do a clean install of the root filesystem and keep all you personal files and settings. But that can also pose problems since there is not always a clean upgrade path for the personal configuration files that live in the dotfile and hidden directories of your home directory. More on that at another time.

I wanted to upgrade (not update) from Mandriva 2010.2 to 2011.0 just to see what would happen. A look at the Notes for 2011.0 would indicate that such an option is possible with relative ease. Well, not really. Here's what you need to do.

After you have made certain that all you data is backed up and secure, the first step of the update is to update all the packages on your system.

# urpmi --auto-update --auto -v

Next, all the references to the 2010.2 repositories must be deleted.

# urpmi.removemedia -av

Then, 2011.0 repositories must be added. I also use the PLF repositories, so those need to be added those as well. You can do this automatically with EasyURPMI at PLF.

For the full Mandriva repos (all on one line):

# urpmi.addmedia --distrib --mirrorlist 'http://api.mandriva.com/mirrors/basic.2011.0.$ARCH.list'

For the PLF repos (all on one line):
# urpmi.addmedia --distrib --mirrorlist 'http://plf.zarb.org/mirrors/2011.0.$ARCH.list'

Note that the commands contain the variable $ARCH. I did that so you could copy the command and it would automatically detect your i586 or x86_64 system as appropriate.

Even after this has been done, some of the individual repos (the non-free ones) that are deliberately not enabled. To enable these, in your menu go to Tools > System Tools > Configure Your Computer. This launches the Mandriva Control Center. Then select Software Management > Configure media sources. Tick the boxes next to the repos Main Backports, Contrib Backports, Non-free, Non-free Updates, Non-free Backports, PLF Non-free and PLF Non-free Backports. Click on OK when you are all done and exit the Control Center.

If you want to avoid the lengthy trip through the menu system, execute drakrpm-edit-media in a terminal window.

If anyone is aware of a script that can have the same result, I would like to hear of it.

I have always found it better to do this kind of upgrade without the GUI running. So far, if you've been following along on your own system preparing for the upgrade, you've been able to cut and paste commands between your browser and a terminal window, but once the GUI disappears, that becomes impossible. Since the command to perform the actual update is a long one, let's create a shell script to execute it.

Using whatever text editor you prefer, create a file named 2011_upgrade.sh, make it executable with chmod +x and have it contain the following (all on one line):

#!/bin/sh urpmi --auto --auto-update --replacefiles 2>&1 | tee 2011_upgrade.log # upgrade 2010.2 to 2011.0

Now, using Crtl-Alt-F2, open a virtual terminal and log in as root. Stop the dm service to shut down the window manager with:

# service dm stop

Now log back in as root, change to your home directory and run the 2011_upgrade.sh script.

The urpmi package manager now wants to install a lot of packages and urpmi is smart enough to know to install certain system-critical packages first. But urpmi cannot install python-numpy because if version conflicts. This causes the upgrade process to fail to install any python packages which will seriously munge your system and which prevents the installation of packages which depend n the newer version of python..

Don't panic and most importantly, don't reboot. Your system is running now and there is no guarantees that it will on a reboot.

The solution is simple. That is we should uninstall python-numpy manually and then re-install the most current version; this will allow urpmi to update python and unblock the installation of many more packages.

The problem we encounter is that the urpme command doesn't know how to uninstall python-numpy without also uninstalling every other package that depends on it. Normally that's a good behavior, but not for in this instance.

We'll need to use the rpm command to uninstall only the one package and then use it's smarter cousin urpmi to successfully update all of python.

# rpm -ev --nodeps python-numpy

and then,

# urpmi python-numpy

There may be similar notifications for other files. I was notified about libkexiv2 and x11-driver-input-evtouch. The same trick using rpm -ev --nodeps works with them as well.

With these problems fixed, run the 2011_update.sh script once more. Keep fixing and re-running until there are no more packages to update. Once that state is reached, it will be safe to reboot into Mandriva 2011.0. When 2011.1 is released, the same technique can be used, but there should be fewer problems.

One problem that did occur post-upgrade concerns networking. Mandriva 2011 implements a new network manager and your old network configuration files won't work with it. While you can use the network section of the Mandriva Control Center to fix this (I had to delete the connection and re-create it to make it work), it's easier to add NM_CONTROLLED=yes to the end of each ifcfg-* file in /etc/sysconfig/network-scripts. That's all that is necessary for the new Network Manager to control them.

Otherwise, everything works fine and I'm now running Mandriva 2011.0. That the upgrade worked as smoothly as it did is a testament to the work and expertise of the Mandriva team. If I come across other issues, I'll address them here.

Monday, October 31, 2011

More fun with Linux

There are two things that can help you to have some fun with Linux.

The first is VirtualBox. Since you are not using it for commercial purposes, you may download and install the full-featured version for your host operating system. If you are a MS Windows user curious about Linux, this is ideal for you. If you are a Linux user curious about different distros, this works as well.

After you install VirtualBox on your host operating system, you need to learn how to use it. the VirtualBox site has excellent documentation. My suggestion for configuration are give the virtual machine the maximum amnount of RAM and video memory that is practical and set the network choice to "bridged" rather than "NAT".

Next stop is to download the NetbootCD. This CD contaions enough of an OS to enable wired Ethernet connectivity and download and install several Linux distros via FTP.

What can you install?


  • Ubuntu
  • Debian GNU/Linux
  • Fedora
  • openSUSE
  • Mandriva Linux
  • Scientific Linux
  • CentOS
  • Slackware


  • Now you can create a virtual machine for each distro and experiment to your heart's content. This is much safer and easier to implement that dual- or multi-booting.

    Remember that when using VirtualBox, you are only exposing the virtual hardware to Linux, not the real hardware of your machine, so learn how to identify your real hardware and learn how to use Google to determine the level of Linux support for it.

    One last suggestion. When you do decide to install a Linux distro on your machine "for real", save yourself some headaches and obtain a second hard drive for your Linux install. If your hardware permits booting from an external USB drive and the distro you have chosen permits installing on a USB drive, you are home free. Otherwise, you'll need to install the second drive as a temporary replacement to get Linux installed. Then you can move it to an external USB enclosure .

    If your BIOS does not permit booting from an external USB drive, you might find plpbt4win to be useful. It is a special bootloader that can boot an OS from an external USB drive. There are Linux and Windows versions.

    Have fun!

    Thursday, June 02, 2011

    Mageia


    The first release of Mageia 1 is out. You can download it from here and read the release notes here.

    If you've used Mandriva Linux, you'll feel right at home with Mageia. Mandriva has always had a reputation of working well for both the novice user and the power user. Installation is typically easy and hardware support is among the best of any distro. The user and administrative tools are comprehensive and easy to use. Of course, under the hood, it's all Linux and all configuration files are plain text files and all a competent administrator needs do is to choose a shell and a text editor.

    Mandriva has also been known for excellent default fully-featured configurations of the KDE, GNOME, XFCE and LXDE desktop environments as well as a broad range of available applications. Mageia is no exception in thsi regard.

    For the average user, the changes are mostly cosmetic. The Mageia art, colors and graphics are very well done (and contributed by the Mageia user community). But if it's just a pretty Mandriva, why is there a need for another Linux distro?

    Mandriva began life as Mandrake Linux, based on Red Hat 5; Mandrake was essentially "Red Hat Done Better". It offered a well-configured KDE as the default desktop as well as its own administrative tools that provided more flexibility than those tools offered by Red Hat. The under-the-hood difference in these tools was that they were (and continue to be) written in perl language rather than the python language as used by Red Hat. Mandrake/Mandriva also spent considerable effort on its unique urpmi package management tool, essentially an intelligent, powerful console/gui wrapper around the RPM system of package management.

    At some point, the business management of Mandrake/Mandriva lost its way, rallied, re-grouped and then lost its way again. The first time, they lost focus on Linux and the second time, they lost focus on their community. Mageia stepped in to fill the void in the community so that all the good things that were represented by the Mandriva distro would not be lost in the corporate buyout.

    Which is why the software is so similar and the community is so different; you only need to fix what is broken.

    Mageia offers the most recent verson of your favorite application software and all the major software you expect to be there is there. Mageia uses kernel 2.6.38.7 with additional patches for automatic process grouping andTransparent Huge Page support as well as support for AMD Fusion APUs and Intel Sandy Bridge and Panther Point chipsets.

    Both 32-bit and 64-bit installation DVDs as well as a Live CD are available. Migration from existing Manriva 2010.2 installations is easily done. A large on-line software repository is available and provides a wide range of software of both free licensed and other licensed categories (the latter is not enabled by default, but is opt-in).

    As with any initial release, you're likely to find a few minor bugs, but the Mageia community is there to help you. As a long-time user of Mandrake/Mandriva and co-author with Bill Ball of the Red Hat/Fedora Unleashed series, I believe you'll find Mageia a full-featured and easy-to-use Linux distro.