Cobra's bits (Posts about mandriva)

The last day of summer

Cobra — Sun, 11 Sep 2011 13:26:40 GMT

Or: How to lose loyal users: a beginners guide for soon-to-be extinct Linux distributions

Promise that the badly needed upgrade will be recognized by the update manager.
Just in case if not, put a description on the Wiki which can't possibly work. Let the user find out why.
After the user found out and forced the upgrade, arrange numerous conflicts which increase the users problem-solving ability.
When the user has sorted out all the challenges, present a kernel panic upon reboot. Give him the real deal!

Farewell, Mandriva! You were my trusted companion for a decade, and I'm sure to miss many of your amenities. But I can't use a system which offers a TeX distribution from 2007, and which breaks upon an online upgrade.

There was no question what I'd install instead: that had been clear since my discovery of Arch Linux more than two years ago. I use Debian Testing on all compute servers, but it's not quite up-to-date enough for a desktop if you ask me (I was an avid user of Mandriva Cooker until I decided that this platform, while offering comparatively current packages, is simply too unstable to be of use). In contrast, I have not seen Arch to break in the two years I'm following its progress in two virtual machines. I also became moderately familiar with Arch Linux itself, which I still believe to be the most transparent and, in a sense, most simple distribution I've ever tested and used.

The installation and configuration was, as usual, straightfoward, but two issues remain. First, 'keychain' works, but neither 'openssh-askpass' nor 'ksshaskpass' do. I thus have to manually call 'ssh-add' upon each reboot. Admittingly not a big thing. The second issue is more disturbing: while both 'privoxy' and 'pdnsd' work perfect separately, they don't work together. I just get 404s when trying, and I have no clue as to the reason.

Everything else, however, functions perfectly. There are, of course, many small things to be taken care of when changing from a very old to a very new distribution (just think about python 2.x and 3.x), but most of this tinkering is over and done. I can lean back and enjoy. 😉

The little pacman you see in the tray, by the way, is the icon of yapan, a cute little update manager which keeps the system up-to-date in its own cute little way. 😊

Mandrolla

Cobra — Sun, 19 Dec 2010 18:58:42 GMT

Many of you will know that that the future of Mandriva looks bleak. Most of the active developers of Mandriva were layed off following the liquidation of Edge-IT, a Mandriva SA subsidiary, earlier this year. A few days later, these developers announced a fork of Mandriva, purely community driven and called Mageia. The community was delighted and declared Mandriva dead almost unanimously. Mandriva SA, in turn, protested and assured that Mandriva is alive and intends to stay so.

I actually thought that all this bickering wouldn't matter to me any more, as I've planned to acquire a new computer and to install an entirely different distribution during the Christmas holidays. This won't happen for various reasons, and for a lack of both time and energy, I've decided to just let Mandriva continue to run on my trusted E6600. And why not? Everything works fine, and I have far fewer complaints than with certain other distributions. 😉

So, I was comfortably settled, when suddenly updates started to pour in. Imagine my surprise when one of these updates turned out to be a brand new kernel. Is Mandriva going to be a rolling distro after all?

No, it won't. Actually, this rather unexpected upgrade is officially a Christmas present. Others will suspect an act of desperation, but I'd say that was simply necessary to keep the distro on a competetive level. Who knows, perhaps there's life in the old dog yet. 😉

Usable

Cobra — Sun, 17 Oct 2010 21:46:35 GMT

Software tends to get fatter with time. Just look at Firefox, which started as Phoenix with the self-proclaimed aim to fight the bloat of the Mozilla project. Look at it now: a fatter browser was never seen.

Others are not better. When upgrading my Mini to Maverick Meerkat, I've noticed that Chromium now takes 50 MB of my precious SSD space, just as much as Firefox does.

But what can we do? Light-weight alternatives—such as links—are limited in ability and performance, aren't they?

Are they?

uzbl git.20100403-3
    1652.8ms +/- 3.2%
Chromium 8.0.551.0 (62128)
    1834.8ms +/- 2.0%
Firefox 3.6.10
    4163.6ms +/- 1.4%

root@mini:/home/cobra# wajig size | grep chromium
chromium-codecs-ffmpeg                  1,180
chromium-browser-inspector              3,940
chromium-browser                    49,252
root@mini:/home/cobra# wajig size | grep uzbl
uzbl                            656

root@mini:/home/cobra# wajig remove
chromium-codecs-ffmpeg
chromium-browser-inspector
chromium-browser

Adblocker? Privoxy:

vi ~/.config/uzbl/config
set proxy_url = http://127.0.0.1:8118

I also like

@cbind  gc<Scroogle:> = uri https://ssl.scroogle.org/cgi-bin/nbbwssl.cgi?Gw=%s&n=2
@cbind  gx<IxQuick;> = uri https://ixquick.com/do/metasearch.pl?query=%s&cat=web&pl=chrome&language=english

in ~/.config/uzbl/config.

I love this browser...its just perfect for the Mini 😊 And vi aficionadas have a new home. 😉

Workaround

Cobra — Thu, 29 Jul 2010 19:47:26 GMT

Folding@Home is, as so many times before, broken on Linux systems with a reasonably up-to-date version of libc and either segfaults or stops working with bizzare error messages such as 'Couldn't CosmHTTPOpen' or 'Cannot get ID from server'. Since many solutions posted in the interwebs are wrong or deprecated, here's a viable workaround which I know to work on Debian, Ubuntu, Mandriva, and Arch (and Fedora, I've heard).

Install nscd, then check your /etc/nscd.conf with your $EDITOR. Find the following line:

enable-cache            hosts           no

Change "no" to "yes", if necessary, then save and exit the editor. Finally, issue a

service nscd restart

and fold away.

Keep pushin'

Cobra — Sun, 18 Jul 2010 10:08:30 GMT

Mandriva 2010 Spring has been finalized (after several serious delays) at the 9th of July. The 'Mandriva Update Applet' apparently missed this event, since it did not yet offer me an upgrade, though several mirrors have been populated days ago. I finally lost my patience, and told the senile applet that a new version is out:

mdkapplet-upgrade-helper --new_distro_version=2010.1

Since then, the applet is dutyfully doing its job:

PS: Since probably nobody will be able to make the link, I'll explain: the title is a reference to a favored song of mine. 8)

make: don't know how to make love

Cobra — Sat, 28 Nov 2009 13:12:23 GMT

The title of this entry is an old joke born in times when package managers were not yet invented. All administrators thus had to know how to install programs from the source with the now well-known, and even famous sequence of commands, the "rule of three":

./configure
make
make install

Now, you can still install programs in this old-fashioned but canonical way. But aren't there better ways?

Oh yes, and we are all using them: they are called package managers. They did away with the d ependency hell, which was the source of constant irritation in the early days of Unix before the development of package managers dealing with dependencies (that, by the way, is just a decade ago). Ian Murdock called package management the single biggest advancement Linux has brought to the industry, and I fully agree. It's the prime reason why I'm using Linux and not MacOS.

You now may understand why I principally consider the above "rule of three" as the last resort. Bypassing the package management is always possible, and in the rare cases I do that, I install everything in /usr/local as recommended. Yet, this should be done in exceptional cases only, and not become the standard. Remember that these self-installed packages are not part of the automatic security updates offered by your package manager, nor can they be cleany removed in an automated way. In other words, these packages need to be looked after and pampered, and I just don't want that on my system.

But what to do if your distribution simply doesn't offer a package you're interested in, or only a grossly outdated version?

There are a number of possibilities, and there's an helpful tool which helps to explore some of them.

First of all, I always check whether the tarball of the program I've just downloaded contains a *.spec file. Then, a simple 'rpmbuild -ta .tar.gz' might suffice to create a binary rpm out of the tarball . You can then install this rpm with the package manager of your liking. 😉
Second, if there's no *.spec, or if compilation fails, there's a high chance that alien will work. For example, my versions of gdis and gwyddion are both the offspring of a conversion from a debian/sid package to an rpm by alien. To find out whether the desired program is somewhere out there, you can use whohas as mentioned above. Beware: the script does not run out of the box. One needs to specify the version numbers of current distributions in line 50 ff, and currently it is also advisable to deactivate mandriva and slackware (just underneath, switch to zero). In any case, after you found the package you need by whohas (which tells you the address!) and downloaded it, simply run 'alien --to-rpm --scripts .deb' and install the resulting rpm by your package manager. Or vice versa: 'alien --to-deb --scripts .rpm'
Third, you may, in exceptional cases, also install packages build for another distribution. Fedora packages, for example, can often be installed on Mandriva and vice versa. However, you should only do that if you're versed in this business, as it can easily wreck your system.

Murphy

Cobra — Sat, 03 Oct 2009 19:01:13 GMT

What's quite unlikely in these times? A power failure.
What's even more unlikely? Me upgrading at the exact minute of the power failure to the first release candidate of Mandriva 2010.

System didn't boot at first, but that could be fixed by a straightforward repair of grub. After that, it became obvious that all further updates were complicated by the fact that the rpm database contained more than 600 duplicates, i.e., the system believed to have the same package installed in both 2009.1 and 2010.0 version. An 'rpm --rebuilddb' didn't help. What to do?

rpm -qa --queryformat '%{NAME}-%{VERSION}\n' | sort | uniq -d > duplicates_0
while read pkg; do rpm -q "$pkg" > duplicates_1; done < duplicates_0
sed -i '/2010/d' duplicates_1
while read pkg; do urpme "$pkg" && echo "$pkg"; done < duplicates_1

Instead of the sed command, you can also load duplicates_1 in vim, and:

:g/2010/delete
ZZ

Ich weiß immer, was ich tue

Cobra — Sun, 28 Jun 2009 21:28:52 GMT

Where did I write that? When? And WHY?

Calm down: questions like that can once again be answered on KDE, this time using the Nepomuk search service:

Even easier than that: just type in your search term in krunner after issuing alt+F2:

In this example, Nepomuk/Strigi finds more than above. That's just because I created a blog entry in the meantime, and all related folders/files are found ... basically in real time. That's pretty neat.

PS: It's official home page claims that strigi is the fastest and smallest desktop searching program. Hm ... on startup it uses more than 100 MB, and after one day of usage, 400 MB. Small is different.

PPS: Yes, the title is an insider. It refers to this story. 😉

Automatic

Cobra — Sun, 14 Jun 2009 11:43:39 GMT

As promised, let's talk about automated backups to a remote server.

Let me stress, first of all: the most important characteristics of a sensible backup scheme is that the backup takes place automatically, without any user intervention. Without this automatism, the backup you'd need will be missing since it was never made. That's one of Murphy's laws which is valid strictly!

There's one very elegant and secure way to do just that, which I'll describe in the following. Note that this way is not standardized amongst the various distributions. I trust you to find the culprits and solutions for the specific distribution of interest for you ... the following, however, applies to Mandriva.

First of all, make sure that you have installed OpenSSH. Generate a SSH2-DSA key pair by executing 'ssh-keygen -t dsa' in a terminal. Set a passphrase to protect your private key! Next, issue 'ssh-copy-id server.name.xy' to copy your credentials to the remote server. Follow the instructions.

Next, install keychain as well as one of the ssh-askpass dependencies (personally, I prefer gnome-ssh-askpass). Keychain is a frontend for ssh-agent, which in turn provides a secure way of storing the passphrase of your private key. For doing that, ssh-agent creates a socket in /tmp with restrictive permissions and then checks the connections from ssh. Keychain allows you to have one ssh-agent process per system, rather than per login session. That is, keychain will ask for your ssh passphrase only upon reboot.

Now, just try and reboot. Being asked for your ssh passphrase? Good! Note that keychain also manages gpg-agent.

For automation, we utilize cron. Copy the following two lines:

#Backup
15 11,14,17,20 * * *    source $HOME/.keychain/${HOSTNAME}-sh; $HOME/bin/backup.rdiff

Save them as 'cronentry' to a temporary location. Open this file with any editor and modify the path to your backup script (which may look just like the backup.rdiff I've shown here). Furthermore, change the time (the first number indicates the minute, the second the hour of a daily backup. The above, for example, means that the backup is processed daily and each three hours between 11.15 AM to 20.15 PM.) Then, execute 'crontab cronentry' in a terminal to create your crontab entry.

That's it. You should now enjoy a fully automatic backup. If you want to change, say, the intervals of your backup scheme, use 'crontab -e'.

Size matters

Cobra — Sat, 02 May 2009 11:04:37 GMT

Last week a friend asked me for help with a rather simple LaTeX problem (he wanted to include an image and rotate it, which you can achieve with the angle option of the \includegraphics command). Of course, you'd find this solution also in the manual of the graphicx package, and I thus recommended to install the texlive documentation. Rather thoughtless, as it turned out. He later informed me that he didn't intend to waste more than 10% of the limited storage capacity of his netbook just for 'fucking manuals'. Hey, I understand! I wouldn't do that myself. 😒

However, what I regularly do is to check the size of the package I'm planning to install. All package managers I know offer this possibility. Try for yourself. 😉

Mandriva

urpmq -y <name>
urpmq -i <exact-name>

Debian

wajig search <name>
wajig detail <exact-name>

Arch

pacman -Ss <name>
pacman -Si <exact-name>

Suse

zypper search <name>
zypper info <exact-name>

Most likely, the texlive documentation will turn out to be by far the largest package avaliable for your distribution. On Mandriva, for example, it is 500 MB in size. No, you probably won't want to install this package on a netbook equipped with a 4 GB SSD...