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.

Optimise.

Having used SLS (Soft Landing Systems an ancient now defunked distribution. IIRC SLS was the first 'packaged' distribution), Slackware then when moved to an x86_64 system, Slamd64 before finally settling on Bluewhite64. I currently have over 500 packages of my own creation. That is, I download the sources and configure, compile and install a lot of stuff myself, usually with a Bluewhite64 package of the result. It never ceases to amaze me how people claim optimisations over and above the stock -march=i486 -mcpu=i686, or in some cases -march=i386, Slackware uses or the stock i386 debian is built with, results in faster load and execution times.

Gentoo users are the biggest culprits for doing this. They claim, and worse some even think and believe, that because their systems are built from the ground up (this is no longer completely true as even stage1 comes with a pre-built base install last time I checked) with some semi insane GCC settings that their OS somehow, magically, is faster than all the other Linux distributions that come pre built via packages.

As an aside, the myth that says Gentoo gives you more knowledge than other distribution is just that. A myth. Portage does all work with the user giving some, often ignored, flags to it. Portage then goes and downloads the sources, builds then installs it. No black magic there at all.

Gentoo users through this mistaken belief can be seen on various mailing lists, web forums, blogs and Usenet arguing over little known, little useful, hidden GCC flags again in the mistaken belief that these flags offer them optimisations over and above what every other OS uses.

Gentoo users are not alone in this belief but their userbase is way over and above the most vocal about it. There are other distributions that make the same claims. Sourcemage, Rock Linux are two others that come immediately to mind at the time of writing.

I cannot find the link now but a while ago there was a binary speed comparison of Gentoo, Mandrake (now Mandriva) and Debian. Debian was compiled for i386, mandrake for i586 and Gentoo for i686. I don't recall what GCC flags where used but I do seem to recall that the flags used where pretty ordinary. It turned out that Debian's i386 compiled binaries were faster in every way. The report was vilified by Gentoo fanboys at the time but what the report did show was that setting insane GCC flags does not always mean one will get a faster system load time and execution time.

The truth is that most optimisations for GCC have nothing whatsoever to do with speed but do have something to do with the resultant binary size(s). This binary size can and does give the illusion that the binary can and does load and run faster.

Where has he gone?

This blog was created not be me, Jeepster, but by a very good friend of mine called seVen. He invited me to join him and write for his blog which I accepted and do.

He lives in the U.S.A. and I live in the U.K. but our online friendship grew over time and has been established for around 5 maybe 6 years. We are so alike we could be brothers but that is by the by.

He has a habit of disappearing and because of the distance between us I cannot simply knock on his house door and ask him what the hell is going on. He has vanished of the face of the Internet once again and I am worried for his welfare. He is not returning my emails. He suffers from bouts of depression which is always a worrying thing that sits in the back of my mind.

In an email exchange we had some time ago he mentioned the fact he had found a wonderful female companion with who he hoped it would turn into a full blown love affair. He was spending more time at her place than he was his own. Her (he never did tell me her name) place has, the last time was spoke via email, no Internet.

If, and I hope this is comes true and turns out to be the reason for his seeming disappearance, he has moved in permanently with his female companion then until such a time as he or she gets an ISP account at her house then that would be the reason why he has seemingly disappeared once again.

I hope he reads this post and gets in touch with me via whatever method he chooses as once again I am worried about him.

Please Don. Get in touch.

Ho hum....

I hate misinformation with a passion and beleive me there is a lot of misinformation about a GNU/Linux on the Internet. I was browsing around the Internet looking for nothing in particular when I happened upon the following link: http://www.associatedcontent.com/article/233123/migrating_to_ubuntu_linux_from_microsoft.html Now, having been a Linux user since around the very early 1990's I take issue with some of the bogus things mentioned in the above article. Let us look at this persons "Requirements" one by one. Here is his list of "Requirements": 1. It must have a GUI interface for installing and configuring the system. 2. Existing hardware must remain usable and the new operating system must make it "just work" without my having to edit text-based configuration files. 3. Existing software must remain usable unless the new operating system has equivalent features to the ones I use, and I can switch without losing data or doing much work. 4. Because I need to use software that has no Linux substitute, the Linux distribution must make it easy to create a dual-boot system. It has to recognize and preserve the existing operating system and its data during installation, and give me access to the data on the Windows drives after installation. Further this person says his "Requirements" are "non-negotiable". Obviously a very arrogant person who writes fluff at best and utter junk, like the article above, at worse. Option 1 in this persons list of "non-negotiable requirements" is the funniest of all of them. The question is, what constitutes a GUI? Most people consider a GUI to mean real drivers for the graphics card and real and proper windows, buttons, icons etc. The MS Window installer does not use a GUI, it uses bit mapped graphics which imitates what we all know as being a GUI. On Linux this is called the framebuffer or sometimes the VESA buffer is used. Given that this person claims to know his stuff does not bode well for whatever else he waffles on about. Throughout the article there are errors and misleading information that is so blatant is stops being funny after page 1. Anyway. Item 2 on his "non-negotiable requirements" list is almost as funny of item 1. The vast majority of hardware under MS Windows immediately after the installation phase is used in the most basic of basic states until one installs the proper driver. Under Linux the vast majority of hardware is in the most usable state from the minute the kernel loads the driver during the install phase. There is a huge difference between these two methods and those differences are at best glossed over in this article and at worst totally disregarded. Further in this persons Item 2 it is stated that the hardware must just work without the need to edit text based files. Now, given that MS Windows has all manner of "Wizards", some of which just work whilst others simply do not and almost every change requires a reboot, I think editing the odd text based file is a much prefer method as they are almost always guaranteed to "just work". Redhat, Mandriva and SuSe to name but a few all have similar wizards. Still, it has to be said that the vast majority of hardware "just works" under Linux and of those obscure bits that rely on deeply embedded MS Windows files often installed by MS Windows only drivers are not worth bothering with anyway, because those types of hardware use way too much CPU time to do their thing. Item 3 in this persons "non-negotiable requirements" list is an obscure one. The person states that "Existing software must remain usable". I do not fully understand the meaning here as it should be obvious that MS Windows software will not work on a Linux distribution as the under laying file system formats are not compatible, unless one uses cedega or qemu both of which run MS Windows within Linux. Some software packages, like the Picasso one this person mentioned run under a Linux OS but is wrapped up in Wine, another MS Windows emulator. If however, this person meant that under Linux his DATA files should be usable from the MS Windows world then that is a different thing altogether. Apart from some deeply proprietary formats the vast majority are usable under a Linux distribution. OpenOffice, which can be directly compared to MS Office, can open, edit and save in all manner of formats, some MS, some Linux but the majority of major MS formats can be opened, edited and saved back to the MS format. The programs under a Linux based OS may not be the same (how could they be when the program creators do not produce a Linux version?) but the fact is that the vast majority of file formats, be they text based ones, movie and sound based ones or even the ubiquitous MS Office formats are usable under a Linux OS but using a different program. OpenOffice in place of MS Office or Mplayer plus codecs in place of MS Media Player plus codecs etc etc. Finally, this persons Item 4. This person states that he uses some applications that have no Linux equivalents. While I agree that this situation does happen, the situation is getting less and less but there are still some areas Linux has not gone to that the MS world has. The person also mentions a dual boot situation. Now, given that both Lilo or grub (two boot loaders under a Linux OS) have been able to do this since, well, since they more or less first came onto the market and if given the choice between a Linux based boot loader and an MS boot loader I personally would go with the Linux based one every time. Why? Well, the MS operating System does not like sharing with anything and is often times the culprit when in a dual boot situation the Linux OS side suddenly either stops working or simply gets deleted. Also, when you install MS Windows it will automatically over write whatever is in the MBR irregardless of whether you wanted it to. The Linux based counterparts however will allow not only a dual boot situation but a triple or quad etc boot option. And just so this person knows it is not a Linux OS that stuffs up the MBR (Master Boot record which holds all the partitions and OS information) but the MS Windows one. The MS boot loader, or rather the MS installer does no sniffing of the MBR at all, while its Linux based counterparts do, and simply overwrites whatever was in the MBR. So, there we have it. Someone who has not the first clue about Operating Systems writing blatant rubbish about operating Systems. If these people are to gain any credibility whatsoever they should at least learn that about which they speak. Installing a Linux based OS nowadays is easier than installing its MS Windows counterpart. It will not over write whatever is in the MBR. It will open, edit and save almost all formats be they text based one, XML based ones, film based ones and music based ones. Apart from games, and even that area is getting less and less, there is very little MS Windows can do that a Linux OS cannot. This person used Ubuntu as his marker for his or her "non-negotiable requirements" which is a good choice as Ubuntu, Kubuntu, Edubuntu or any other flavour of Ubuntu does all the things one would expect from a Linux OS trying to immitate MS Windows in every area. There are other Linux Distributions out there that operate in a similar fashion but there is only one MS Windows (Windows95, Windows98, WindowsXP, and MS Windows Vista are not differing OS's in the same way that the many and varied Linux distributions are). For anyone thinking of installing a Linux OS either as the only OS on the hard drive or as a dual boot you would do well to ignore this blatantly bias rubbish as portrayed in the article above and go and find someone, somewhere that knows what they are talking about. This person in the above mentioned article clearly and unequivocally does not.