Time rolls on.

Indeed it does. Time rolls on and the dinosaur's disappeared. And so it is. With the above line stated I think some explanation is required, especially its deeper meaning as well as to what it is I refer to in the present tense. Many years ago some Slackware users placed many nuggets of information relating mainly to that Operating System but sometimes to every GUN Linux based Operating System. They put on to web sites information such as how to 'properly' build Slackware packages. How to get around some of the quarks that distribution had. How to change the start up scripts to make them faster at boot time. Etc, etc, etc. All this and more was put out there for public consumption and people used that information. Then other Slackware users came to be and they too put such information into the public domain. These users collected the information scattered on many web sites put there by the previous generation, updated to fit new releases and then put it all together in one place for other people to view and use. Fast forward to today and yet again a newer set of users came to be who collated information out there on the Internet, gave it a new twist, called it their own and placed the result on the Internet. The different between the three generations of Slackware users, while all had or have good intentions, follows the same path and attitudes each generations general public had or had. Lets call the generations Gen-1, Gen-2 and Gen-3. Gen-1 built the foundations the Gen-2 built on top of. Gen-2 attributed Gen-1 for the work Gen-2 created off the back of what Gen-1 created. In otherwords Gen-2 acknowledged Gen-1. Gen-3 however is a different beast all together. They took the work done by Gen-2 and called it their own. They changed the smallest bits. They give no attribution at all to Gen-1 and Gen-2. They created web sites in a mirror image of web sites created by Gen-2 and then added or edited scripts then gave no attribution to Gen-2. So, today we have a situation where Gen-3 users are coming across, and they do everything possible to put that in the minds of other people, as being the first and only generation of Slackware users that have put information and slackware build scripts on the Internet. They give not the slightest nod to all those who have gone before them doing what Gen-3 users are doing right now. I reckon there are one or two reasons for Gen-3's attitude. Reason 1 is mirrored in how todays society at large acts. Reason 2 is that most of the Gen-3 web masters are American and we all know they think they rock andthe rest of the world does not exist in their minds and that they are hellbent on ruling the world. That is my take on the current generation of Slackware users. It is bad enough to make me want to change distributions for the first time in 12 years or so. Attributes people. Attributes. Deep deep down you know I am right.

Gnome2 >2.20.0

I am unsure when Gnome2 started using PolicyKit which itself relies on SELinux and/or PAM but in my honest opinion this is a bad bad move.

I don't know how people who are building third party Gnome2 packages for Slackware are going to build it without PolicyKit. Every man and his dog knows that Slackware's author, Mr Volkerding, regards PAM as a huge security hole so does not and has said he will not include PAM in his distribution.

I have liked Gnome since its first incarnation many years ago. While I currently use the always improving without adding bloat Xfce4 I often revisit Gnome2 to see what is going on there. KDE simply does not get a look in because I have never liked QT.

But, this new reliance on PolicyKit which in turn relies on PAM and/or SELinux to be able to do its work is going to prove to be a massive turn off for me and no doubt a lot of Slackware users and for that reason alone unless I, and others, can find a way to build the latest version of Gnome2 without PolicyKit then Gnome2 will simply fall by the wayside as so many other DTE's and WM's have done over the years. Xfce4 will be the only DTE (DeskTop Environment) left on my system for those times I load up X.

Time and time again I have dabbled with PAM. Built it, installed it, configured it for my needs but always I have felt that PAM is simply a security bolt on that is not needed on a properly configured system. Because it is a bolt on this alone makes it a security hole. Look at PAM's record on vulnerabilities and you will see just how poor a record PAM has in this area. After a week or two usage with PAM running on my systems and adding a patch or 3 to cover some hole within it or updating it yet again because of a vulnerability I get fed up with it and remove it. Look around the Internet and you will see problem after problem regarding PAM and now we have parts of Gnome2 relying on it. If I feel this way how many others out there feel the same?

I downloaded the latest, at time of writing 2.21.2, Garnome (that is how I have tested various versions of Gnome2 for quite some time. Garnome itself is a wonderful tool as it allows you to test Gnome2 without actually installing it system wide) and because I have no PAM or SELinux installed it will not build. I have edited various files within the Garnome environment to try and eliminate the need for PolicyKit, PAM and SELinux but every effort resulted the same. It simply will not build.

This reliance on PolicyKit, PAM and SELinux is a shame as I said earlier on, Gnome2 has been one of my favourite DTE's and because of these reliances I will soon be consigning it to the bin.

Creative XFI Fata1ity.

Is this card a dead duck under a Linux Operating System? As of this time I have to say a resounding yes. However, read on. You may be surprised.

I will hold my hand up and say up front I am no audiophile. My partner in crime on this blog seVen however is. He has often winced at sounds I have found reasonable to my ears. Anyway, what is said here in this blog post is not about sound itself but about the state of Creative's drivers for the Linux Operating System.

The last time I had a Creative sound card in my main system they had just released what turned out to be probably one of their longest life card range. The Sound Blaster Live! I had two variants of these excellent cards within a 6 month time frame. My first one was a 4.1 one. My second one about 6 months later was a SB Platinum which of course was a 5.1 card.

So called on-board audio is audio that sits on your motherboard rather than being an external PCI/ISA/PCIe etc card. Not all motherboards have on-board sound but more and more do these days and the quality, for a desktop system with an OpSys that has everyday ears for sound receptacle's, the sound is really rather good. Of course there are some on-board audio chips that suck more than a suckything at a suck fest but by and large on-board audio has come on leaps and bounds in the desktop space.

As on-board audio became more ubiquitous and became better and better with 5.1 and 7.1 being the norm the good old SB Live! was consigned to the desk drawer where all good cards go and which I call my "Use again Someday" drawer and while the sound emanating through my 5.1 speakers via the SB Live! Platinum still punched out some excellent bass from the sub woofer I had no choice but to free up a PCI slot and reluctantly move to onboard audio.

My first on-board experience came via a VIA AC`97 chip which frankly was utter rubbish. I went through motherboard after motherboard all of which had some form of on-board audio chip. I will say that the best of these is probably my current one which is a VIA High Definition Audio used via the intel driver under Linux.

This brings me to something else. Driver support. It is a rare sound chip that has no support at all, though there are some. Under a Linux Operating System many chipsets are collected into one driver. So, if you check your kernel sources you may not see your audio chip, on-board or not but via the ALSA sound sub system more often than not there is support for most sound chips. In some cases you may need third party drivers. Nvidia's nForce series is one such example as is Creative's latest and greatest the XFI range.

Not being totally enamored with my current on-board audio I decided to purchase a PCI external sound card. Plenty of choices out there but I wanted something good. My attention immediately switched to Creative's range. In particular the XFI range. I settled in the end for a Creative XFI Fata1ity. Now, usually I check Linux compatibility before purchasing any hardware but this time around I simply bought the card and thought I'll worry about support later.

Oh dear. What a mistake that was! First time in years I have not checked compatibility first and sure enough that decision came back to bite me in the arse. There was no support for the Creative XFI range whatsoever when I bought it. None. I had a card sat in my machine that registered itself but the kernel said "Unknown device". For approximately 6 months this card was useless under a Linux Operating System. I was absolutely gutted.

Then just last September Creative released some closed source driver for the XFI range. And they released it for 64bit Operating Systems only. The rights and wrongs of that decision will play out in time but for what it is worth I think it was the wrong decision. There are plenty of x86_64 or AMD64/EMT64 systems out there but by and large the majority are x86 or 32bit. I will not get into the closed versus open source argument as honestly I couldn't care less either way. As long as the driver gets my hardware working then the fact the driver is open or closed makes no odds to me at all.

Having downloaded the driver I proceeded to use their 'installer' script. This failed miserably. After some editing of the 'installer' script to fix obvious mistakes I tried again. This time it failed on some kernel header file. By now I was slightly pissed off but decided my best course of action would be to Google it. I did exactly that and found many other people around the globe had hit the same issues as I had hit. As is usual for closed source drivers, Linux users set about fixing all the issues. Notably, Gentoo users fixed the issues. Some Gentoo users are a world apart from other Gentoo and other Distribution users. I tip my hat to these people. This web site documents everything so I won't go through it here. If you have a Creative XFI range audio card then go take a look. It will save you some hair loss.

So, finally, what is the actual sound like? Hmm, it is listenable but certainly no great shakes. There are serious issues with this driver like 'scratching' as the file or video plays, the driver sometimes locking up the system on boot etc etc. I am sure that given time Creative will sort all these issues. Let us be fair here this Creative released closed source driver is ALPHA status so given that status there is plenty of room for improvement. I think Creative's best bet would be to release the driver as true Open Source with a relevant, possibly restrictive, license. By doing this they are guaranteed to have hundreds, possibly thousands, of eyes on the code which with Creative's help with 'hidden' details should yield a driver that matches or possibly beats its MS Windows driver.

As of the time of writing I am not overly happy with this card. I will sit quietly, patiently and wait for the next few releases of the driver which should see both stability and usability improve. I hope so. The card itself can and does produce excellent sound under MS Windows and apart from Creative blocking coders by withholding vital information regarding this card there is no reason why this Linux based driver cannot improve.

If you, the reader, are a Bluewhite64 or Slamd64 or any other copycat 64bit Slackware based Operating system would like a fully patched Slackpak of the Creative XFI driver then tell me and I will see what I can do about creating one for you. Do not ask me for a 32bit Slackpak of this driver as as of the time of writing the closed source portion of this driver has no 32bit support.

Slackware package build scripts

Long time Slackware users have since the beginning created their own Slackware build scripts that created Slackware compatible packages. These packages made for easy installation as well as removal. They also eased the pain for administrators with multiple machines.

Over time these long time Slackware users built up a huge collection of build scripts. Most, like myself, have kept these build scripts to themselves. Only releasing the odd one or two to friends and colleagues or if some package that came with Slackware itself could be built in an alternative way. Gaim, now called Pidgin, comes to mind here as it can be built against mozilla's NSS or against GnuTLS. Slackwares own is built again Mozilla's NSS but many users don't install Mozilla so the alternative build against GnuTLS that I created a long time ago was born. That build script was downloaded over 2 million times. The packages were downloaded over 1.2 million times. These numbers vindicated my releasing the build scripts and packages.

Many friends and colleagues urged me to release more of my own build scripts and packages but I did not. One, probably the major reason why I did not, because I considered Slackware users would rather create their own.

Latterly, lots of web sites dedicated to Slackware build scripts have popped up. Some borrowed my Gaim/Pidgin build scripts and called them their own. Others simply copied them, changed a few bits here and there within the build scripts then called them their own.

But the point of this post is not to complain about that but to ask the various administrators of those Slackware build script sites to add support to all their scripts for the x86_64 architecture.

I have no idea which of the two main x86_64 distributions, Bluewhite64 or Slamd64, is the most popular. Nor do I care. I use Bluewhite64 myself purely because the packages are one for one with Slackware itself whereas Slamd64 has some changes.

I don't care if these newer sites have stolen or reworked Slackware build scripts from other places on the Internet. Simply put these collections offer a great service to Slackware users by having lots of build scripts in one place. However, by leaving out x86_64 support in their build script repository's they are leaving out a large, and growing by the day, proportion of Bluewhite64/Slamd64 users.

P2P to throttle or not.

P2P to throttle or not. That my dear friends is the question facing ISP's the world over (apologies for the bastardised quote).

With P2P traffic gobbling up bandwidth, bandwidth owned by the ISP, well even they purchase it but for this blog post we'll put up with the consideration that they own their part of it, and purchased legally by you the customer, there are those who are seeking to kill off all P2P traffic. For that there is no justification whatsoever.

ISP's, mostly, are throttling P2P traffic. Some more than others but throttling it nonetheless.

Those that seek to kill or throttle P2P traffic seem to miss one simple point in all this and that is that the customer pays for their connection and therefore have a legal right, within the ISP's T&C's and/or FUP, to use that connection as they see fit.

Sure, there are those that use P2P to download illegal content and they should be targeted in an effort to stop them, but for the rest of us downloading free content like Linux ISO's, free applications, free video content etc etc why should we suffer these restrictions?

A lot of ISP's use self learning throttling applications that seek to level out customer usage by looking at signatures which give the application some idea what the user is actively doing. ISP's and the creators of this application claim that the self learning nature of this software allows it to differentiate between legal and none legal traffic so why can they not distinguish between those customers that download illegal stuff from those of us who want to download, via P2P, legal content?

I will tell you why. It does not matter to them if you are downloading legal content or not. They do not like the fact that P2P uses a distributed model for downloading, and uploading, which means that the bandwidth you legally purchased from your ISP is used. There can be hundreds if not thousands of distributed bits of a file or video dotted all over the world taking up bandwidth legally purchased.

There are many legitimate uses for P2P, like Linux ISO's. The idea that the only people to benefit from P2P are those who distribute ilegal content is quite simply wrong. Further, if I have the option of downloading from a distant server or from a torrent with hundreds or thousands of users, I will go for the torrent everytime quite simply because usually the torrent download will be faster even with misconfigured ISP throttling in place. Added to this is the fact that BitTorrent software is quite adept at managing large downloads. There are times I may want to throttle my torrent download because I am playing a game.

I have yet to have it explained to me why downloading via P2P is any worse bandwidth wise than downloading via a single host. I fail to see how this differs in bandwidth used. Unless of course it is easier for ISP's to throttle single downloads.

Throttling or killing of P2P is wrong. For many reasons.

Apples Leopard OS.

With all the fuss surrounding Apples release of their latest OS offering called Leopard it will come as no surprise when the users of it are disillusioned. That is assuming they dare become disillusioned.

Thing is Apple never truly innovates. They copy whatever other OSes have done and in some cases have done for years but to Apple fanboys who believe every word Mr Jobs say these "innovations" are new and truly innovative. Silly people.

Since Apples move to a Unix underbelly they have become mainstream again. Why? I have no idea. Apples OSes have turned me off for years. I honestly cannot understand how they have become what they have become.

Apples Leopard. Nothing new here. Move on.

X is NOT KDE!

Or put in pure Linux/Unix terms: X != KDE. Or Gnome, XFce4, Fluxbox etc etc.

As Linux (Linux defined here constitutes an entire distribution. In real terms, linux of course is the kernel only and a distribution, like Slackware, RedHat, Ubuntu etc are collections of programs which include the kernel.) grows exponentially in popularity there are many misnomers cropping up regarding what is what. While these misnomers are mostly harmless they do make diagnosing problems that may crop up harder for us more knowledgeable long time users.

For example. I saw a discussion recently on a forum where the user with a screen blanking problem kept referring to "The screen blanker in KDE." After much discussion going back and forth it eventually transpired that he/she was using Ubuntu. Ubuntu hides the underlaying console that all distributions have and boots straight into Gnome, by default, or KDE. This user had changed the default so instead of logging directly into GDM (the gnome login manger) from where he/she could log into Gnome or KDE he/she automatically booted directly into KDE.

Nothing wrong with this method and can in fact save a little bit of time logging in. This method also facilitates booting ones machine then walking away to do something else. On return the machine will be sat on the Gnome, KDE etc desktop so one can start work immediately upon returning to the station.

Where this sort of auto login does become an issue is when, for whatever reason, ones X or Gnome/KDE has been irreparably broken so that instead of being sat on the desktop one is sat at a scary black screen with nothing more than a bit of text at the bottom.

And so this discussion went. He/she was not having a problem with KDE but did have a problem with X blanking the screen. however, his/her constant use of "The screen blanker in KDE" kept throwing us old timers off the scent of where the problem really laid.

In very simple terms the boot process boots in 3 separate stages. First, the console, second, X and third ones chosen GUI which can be any one of many but most new users tend to use Gnome, KDE or XFce4. To blank or stop blanking the monitor each one of these stages should be addressed separately. Of course if one never uses the console directly that stage can be missed out. None of the GUI's have screen blanking themselves. Instead they offer, via their setup or configuration applets, options to setup the default GUI screen blanker which is a program called xscreensaver.

So, for console blanking we use 'setterm -blank <time in seconds>. If the value of (time in seconds> is set to 0 then blanking is disabled. Any other none negative value will blank the console after those minutes of inactivity.

For X this is a little more tricky insofar as how one goes about setting this up, but works fine once set up. If one does not add these options to /etc/X11/xorg.conf the default options, which are for X to blank the screen after 5 or so minutes of inactivity, kick in. To set X to blank the screen after so many minutes of inactivity, open /etc/X11/xorg.conf in your editor of choice. We need root access for this so use 'su' to gain root privilidges or 'sudo'. Add the following lines to 'Section "ServerLayout"' in /etc/X11/xorg.conf.

Option "BlankTime" "0"
Option "standby time" "0"
Option "suspend time" "0"
Option "off time" "0"

These options totally stop X from blanking the screen.

The third part is simple and for a new user probably the easiest way to blank or stop blanking the screen. Gnome, KDE, XFce4 or any desktop environment or any window manger for that matter do not contain any screen blanking code beyond offering configuration options for the xscreensaver program. By setting these options up one can disable screen blanking in your chosen GUI environment.

I hope you found the information given here useful and please, new users to Linux, try not mixing up the various parts that make the whole and we old timers will be better able to help you with whatever problems you may be experiencing.