My old Slackware box died on me a while ago and I decided to throw another box together out of spare parts I had lying around. The mobo, psu, and cpu are from a 2005 HP Pavilion. I got everything cleaned up and connected and set it to boot the optical drive first, but I dropped the Slackware disc in the drive and just got a black screen when I booted. Underscore cursor blinking in the top left corner for about 3 minutes and not a peep from the cdrom. Tried it with two other optical drives and still nothing. Is it not possible to install Linux with this OEM motherboard?

This morning, hardworking Debian developers pushed the remaining pieces of the brand new X.Org 7.3 to Debian sid (unstable) distribution. And it must be said, a well done job!

ii  x11-apps            7.3+1      X applications
ii  x11-common          1:7.3+2    X Window System (X.Org)
ii  x11-session-utils   7.3+1      X session utilities
ii  x11-utils           7.3+1      X11 utilities
ii  x11-xfs-utils       7.3+1      X font server utilities
ii  x11-xkb-utils       7.3+1      X11 XKB utilities
ii  x11-xserver-utils   7.3+1      X server utilities
ii  xbase-clients       1:7.3+2    miscellaneous X clients - metapackage
ii  xorg                1:7.3+2    X.Org X Window System
ii  xorg-dev            1:7.3+2    the X.Org X Window System development
ii  xserver-xorg        1:7.3+2    the X.Org X server
ii  xutils              1:7.3+2    X Window System utility programs


Referencing the post Nvidia Linux driver 100.14.11 and Linux kernel 2.6.23. Here I have reported the patches for older versions of Nvidia drivers. The procedure to follow is the same described in the above document.

Debian's FreeRadius package is built without support for EAP/TLS/TTLS/PEAP because of the licensing problems of the OpenSSL library. But, if you want to implement 802.1x network authentication with strong security, you'll need it. This is a short tutorial that explains how to build Debian (sid aka unstable) package linked to libssl and with EAP/TLS/TTLS/PEAP support compiled in.

First, download the newest source package (orig.tar.gz), Debian diffs (diff.gz) and description file (dsc) from the freeradius package page. The version I tested the procedure with is 1.1.7-1.

Due to software or hardware (network switch or ethernet card) error it may be possible that you need to restart auto-negotiation on the ethernet device. Here's how to do it:

mii-tool -r eth0

or

ethtool -r eth0


Then check the kernel log to see what happens:

% dmesg
eth0: link down
eth0: link up, 100Mbps, full-duplex, lpa 0x45E1


Thanks for this tip goes to Vivek.

Well, they're not working together. Unless you're not willing to tweak it a little bit. So, out of the box, you won't be able to test brand new Linux CFS scheduler, merged in the 2.6.23-rc1 release, if you drive your Nvidia card with the proprietary driver. I guess that's what we get for running binary drivers.

This one has bothered me for a long time. The solution is, of course, simple. But, I still don't understand why was it necessary to force users to search so hard for this piece of information, where all the older X server releases worked OK out of the box?

If you find that after upgrading to X.Org 7.3 your display becomes very slow, and you own ATI Radeon, all you need to do is to put this line in the Device section of your xorg.conf:

OK, this is so cool and sexy, I really don't understand how I didn't find about this earlier. Possibly because it's the recent add-on to the well known script utility?

So, I suppose you all know about script. You type script, do your work, type exit, and you have your complete session logged in the file named typescript. Quite handy if you want to log everything you did in the shell for whatever reasons.

What you might not know is that script has an interesting switch which allows you to also save the exact timing data of the screen output you're capturing. And an additional utility called scriptreplay which can later replay your session in real-time. Like a movie. With perfect timing.

Two solutions, both to be put in the .htaccess file, when you want to force your website visitors to go through SSL:

Solution A:

RewriteEngine On
RewriteCond %{SERVER_PORT} !443$
RewriteRule ^(.*)$ https://www.example.com/$1 [L,R]


Solution B:

RewriteEngine on
RewriteCond %{HTTPS} !^on$ [NC]
RewriteRule . https://%{HTTP_HOST}%{REQUEST_URI} [L]


Pick whatever solution looks nicer for you.

Although this may seem like a small catastrophe to you, it's actually very easy to recover from that situation. What you need to do is to reboot (power on) your system, but on the LILO prompt you should type something like:

LILO: Linux init=/bin/sh rw

Where Linux is the example image name, you should supply the actual data, of course. And same parameters should be provided to GRUB or any other boot loader you might use.

This is an useful regular expression if you're looking for IP addresses:

egrep '([[:digit:]]{1,3}\.){3}[[:digit:]]{1,3}'


Related:
How to sort IP addresses using the GNU sort utility

Using time zone dumper utility (zdump) like this:

zdump -v /etc/localtime | grep 2007

we can see that:

/etc/localtime Sun Mar 25 00:59:59 2007 UTC = Sun Mar 25 01:59:59 2007 CET isdst=0 gmtoff=3600
/etc/localtime Sun Mar 25 01:00:00 2007 UTC = Sun Mar 25 03:00:00 2007 CEST isdst=1 gmtoff=7200
/etc/localtime Sun Oct 28 00:59:59 2007 UTC = Sun Oct 28 02:59:59 2007 CEST isdst=1 gmtoff=7200
/etc/localtime Sun Oct 28 01:00:00 2007 UTC = Sun Oct 28 02:00:00 2007 CET isdst=0 gmtoff=3600


Use the following procedure to extract contents of an RPM package:

rpm2cpio package.rpm | cpio -dimv

As the name implies, rpm2cpio takes an RPM package file and converts it to a cpio archive. The -i flag to the cpio command indicates that cpio is reading in the archive to extract files, and the -d flag tells cpio to construct directories as necessary. The -v flag tells cpio to list file names as files are extracted, and the -m flag tells cpio to retain previous file modification times when creating files.

Useful if you're doing hardware diagnosis or similar...

setterm -blank 0


There are many ways to compress your PHP driven web pages and thus save some bandwidth, but this is probably one of the simplest. Just put:

php_flag zlib.output_compression On

into your toplevel .htaccess file and you're done.

To test the effect, go here.