Redhatter (VK4MSL)

Capt. Obvious: Warning, cutlery sets contain sharp edges and implements

Nah… really?

We recently received this cutlery set as a Christmas present. We appreciate the gift, and will find it very useful. However, one little safety notice really stood out… Have a look at the photos below (click for large image).

Cutlery Set present Cutlery Set warning

Yep, that’s right… apparently they’re not toys for kids either. I would’ve thought this would be common sense … just like the revelation that fires were hot by a workplace health and safety task force in the UK.

Why can’t people use their brains occasionally? Yeah, you know… knife, cuts things… including little kiddies? People really amaze me sometimes. Hope you get as much amusement out of this as I did. 🙂

Covering the globe in one night: A look at timezones.

Hi All… Somewhat in the spirit of this festive season, I found myself thinking about a problem last night — whilst trying to get to sleep.

We’ve all heard the stories of Santa covering the globe in a sled pulled by reindeer… Now, I’m not particularly interested in what the method of transportation is, or any other details for that matter. Rather, I was more interested in whether it was feasable, for a single individual to visit each point on the globe once in a single night.

In order to visit each point on the planet within the same “night”, one would have to exploit the phenominon of timezones. Legend has it, this mythical character does his business under the cover of night. Thus, it would be logical to assume this would be between the hours of 22:00 (10PM) and 04:00 (4AM).

The natural place to start and end such a journey would be at the International Date Line, heading westward. That is, visiting New Zealand (UTC+12), the various south pacific islands, then Australia, SE Asia..etc, scanning from pole to pole following the longitudinal lines.

Assuming this is the case, one would have to be at the international date line by 22:00, local time. The time zone west of the IDL is UTC+12. The sweep would then proceed, winding around the earth to eventually finish at the other side of the IDL at 04:00 the morning, local time (UTC-12).

Thus, we have the start and end times of our journey:

Start: 22:00, 24th December UTC+12
End: 04:00, 25th December UTC-12

If we convert these back to UTC…

Start: 10:00, 23rd December UTC
End: 16:00, 25th December UTC

The total number of hours for the journey thus works out to be:

23rd Dec: 10:00 to 00:00 14 hours
24th Dec: 00:00 to 00:00 24 hours
25th Dec: 00:00 to 16:00 16 hours

Thus, 360 degrees of longitude must be covered in 54 hours. Division of these figures gives us the exact length of time one can spend at any degree of longitude. It works out that an individual has 9 minutes to cover each degree of longitude. There are 180 degrees of latitude that must be covered in that 9 minutes, thus one could spend no longer than 3 seconds at any given point on the globe.

There is some optimisation that could be done to the route… for instance, you wouldn’t be delivering goods to every point on the planet, only those inhabited by people. Thus you could skip oceans and deserts, saving valuable time. The amount of optimisation though, looks limited. It would seem unlikely that a single individual could accomplish such a feat. Needless to say, it would be an interesting exercise for someone more adventurous than myself to attempt.

Anyway, not to sound like a grinch… that was my thoughts late last night. Those looking at a way to dispell the myth for youngsters who are getting a little old, this little piece could be useful.

At the moment, I’m not home, but I’m popping in occasionally to check on things (the joys of dialup mean I’m not able to remain online). I should be home tomorrow afternoon (Boxing day) and will be getting right back into the swing of things.

My thoughts especially go out to those working throughout Christmas Day. While many of us are sitting with family, eating a christmas lunch, or just veging out (like me), there are people out there who are still stuck at work. People like the firefighters in Victoria and Tasmania, who have been battling flames for much of the last few weeks. People keeping the various hospitals running. Those in law enforcement, and other facilities we all take for granted. It’s these people that deserve the day off more than most, but choose to keep working regardless. To you, I thank you. 🙂

So to all, whether you’re relaxing or hard at work, have a Merry Christmas… and let us all hope that 2007 turns out to be a better year than 2006 has been. 🙂

PS: Ohh, and those travelling interstate this year, if you happen to be wandering through the Jet Star screening points at the Brisbane Airport — keep in mind they are people too, stuck working on Christmas day… there’s no need to give them a hard time, they, like you, want to get home too. 😉

KDE 3.80.2 Test Run

KDE 3.80.2 DesktopHi All…

Well, after much waiting, I managed to get KDE 3.80.2 to build and run. What can I say? Right now it’s not much to look at (low-res screenshot 800×600 100kB, full-res screenshot 2MB 2048×1576), and there are loads of sharp edges, but this is to be expected for a pre-alpha release.

My impressions:

  • The new build system — This is going to take a bit of getting used to, but cmake seems to do a nice job building KDE. And there’s progress displayed as each package is built — very handy with long-haul builds.
  • Build Time was significantly lower in KDE 3.80.2, compared to KDE 3.5 releases
  • Some of the core apps (Konqueror, Konsole…etc) seemed to work fine, although there were some instability issues. (not suprising) Konqueror also seemed to like picking up the resources from KDE 3.5.5, leading to some oddities in the interface.
  • KDE Control Centre appeared to be broken, in that it would not display applets. kcmshell worked however.
  • Some of the kicker Panel applets failed to work (e.g. the clock)
  • The startkde script locks up half-way (loading the Window Manager). In the screenshots above, I had to run kdesktop, kicker and kwin manually from xterm.
  • There appear to be DBUS communications issues that need to be resolved.

In short though… it’s early days, but it looks like we’ll be seeing a lot of behind-the-scenes action in this release. I didn’t see anything that resembled the ideas for Plasma, but perhaps that will come later. It’ll definately be worth having another look in a few months.

Now I know a number of you have been gagging for a guide on how to install KDE 3.80.2. Here’s a very rough guide.

Part 1: KDE Dependancies

For this release, you need a number of things:

cmake is fairly trivial, just add the appropriate line into your /etc/portage/package.keywords to allow you to install version 2.4.3 (currently unstable on x86) and run emerge cmake.

For the others… you’ll need to unmask both ebuilds in package.mask, and will need to hack the Qt ebuild to enable D-BUS support. D-BUS 0.95 is masked at the moment, pending updated mono bindings. Qt 4.2 is masked, pending D-BUS 0.95. You’ll need to uninstall earlier versions of D-BUS in order to install the new release. Be prepared, this will break HAL, avahi, and anything else you have which uses D-BUS, so prepare to have a big rebuild task ahead.

To enable support for D-BUS in the Qt ebuild you’ll need to change the following:

  1. Add dbus to the IUSE variable:
    IUSE="accessibility cups dbus debug doc examples firebird gif glib jpeg mng mysql nas nis odbc opengl pch png postgres sqlite xinerama zlib ${IUSE_INPUT_DEVICES}"
  2. In DEPEND, put in the D-BUS dependancy (it’ll be commented down below):
    glib? ( dev-libs/glib )        input_devices_wacom? ( x11-drivers/linuxwacom )        dbus? ( >=sys-apps/dbus-0.93 )"
  3. Update the qt_use function to pass -qdbus to the configure script (it’ll be commented out). Also, comment out the line below as shown here:
    use dbus        && myconf="${myconf} -qdbus" || myconf="${myconf} -no-qdbus" #      myconf="${myconf} -no-qdbus"

Once the updates are complete, run ebuild qt-4.2.1.ebuild digest. Then, install all of the above: emerge dbus qt.

Part 2: Installing KDE by hand

As mentioned earlier, this new release uses the cmake build system, which is a bit different to get used to. Some of the docs (namely the ones for kdebase) haven’t been written yet, but in short, the procedure is as follows:

  1. Unpack the source tarball (tar -xjvf /path/to/sourcepkg-3.80.2.tar.bz2) into a temporary directory.
  2. Create a build directory (mkdir sourcepkg-build), then change into it.
  3. Run cmake -DCMAKE_INSTALL_PREFIX=/place/where/you/want/kde/3.80.2 -DCMAKE_BUILD_TYPE=debug /path/to/sourcepkg-3.80.2
  4. Run make
  5. (As root) Run make install

The tricky bit, is the arguments to cmake:

  • -DCMAKE_INSTALL_PREFIX= specifies the directory in which you want KDE installed. I put my installation in /usr/kde/3.80.2 so that it was placed alongside my KDE 3.5 install (but not in a place where it would get clobbered). This location is entirely up to you.
  • -DCMAKE_BUILD_TYPE= specifies the level of debugging to include. Valid values are debug (normal debugging), debugfull (full debugging) and profile (full debugging with test coverage).
  • The last argument, points to the directory containing the sources.

The KDE components need to be installed in the following order:

  1. kdelibs
  2. kdepimlibs
  3. kdebase
  4. other packages

Those three above mentioned packages, will get you the desktop shown in the screenshots. I have not yet installed the remaining packages, but these three will get things up and running.

I don’t recommend people mess with this release, unless they know what they are doing… As I say though, I’ll be keeping a close eye on this release, as it looks like there’s going to be lots of goodies going in behind the scenes for us KDE users come release time. 🙂

Common Sense Ain’t So Common

I just heard a beauty Captain Obvious moment on the radio a moment ago.  I know I’m guilty of stating the bleeding obvious on occasion, but this is unbelievable.

In Brisbane (this show is also broadcast to Melbourne, Sydney and Adelaide) there’s a late night talk show called “The Spoonman“.  I like listening to it, as there are often some interesting discussions and viewpoints being put forward.  Anyways… it seems one of the people behind the scenes was digging around on the computer system, and dug up, this sound byte.

I know some people lack a little bit in the common sense department, but damn… where has this reporter been in the last few thousand years?!

Taking KDE 3.80.2 for a test drive

I’ve been a KDE user since installing SuSE Linux 5.3, and seeing KDE 1.0 in all its glory. I later tried Gnome 1.0/Enlightenment, when Red Hat 6.0 was released, and numerous other desktops, but I always found myself moving back to KDE. Prior to this, I had been using window managers like AfterStep, WindowMaker, FVWM and Red Hat’s FVWM95 clone, AnotherLevel.
The other day, I was looking around on the KDE news site, and noticed KDE 3.80.2 had been released for testing. This is a prerelease version of the upcomming KDE 4 desktop, intended for developers to take the desktop for a spin, port their applications to it, etc… Given my interest in the desktop, I figured I’d download a copy and take it for a spin.

The new KDE uses a different build system to previous releases. KDE 3.5 and earlier used GNU autotools, but not anymore. You’ll need cmake 2.4.3 or above to compile KDE 4. You’ll also need Qt4.2, and dbus, which means fun-and-games with masking, modifying ebuilds to disable some tests, and in general, lots of nasty hacks. Unless you know what you’re doing, I wouldn’t recommend anyone try it.

KDE 3.80.2 Build SystemAnyway… after much fiddling, I managed to get it building. Already, I notice something new. The new build scripts actually show the build progress, as KDE builds. This is handy if you’re running on slow machines, and the first time I’ve seen such a feature in use. Here (right) is what the start of the build looks like (low resolution, full resolution).
I shall upload some pics of the desktop the moment I get kdebase installed, but so far, this is prooving very different to previous releases of KDE.

Gentoo/MIPS Cobalt: n32 Stage 1 complete

Hi all…

Yep, the first 64-bit userland stageballs for Cobalt are well underway. A stage 1 tarball is being uploaded right as I type this, and Catalyst is just starting up the bootstrap script now to get the stage 2.

I also began a build for µClibc, but I’ve hit technical issues with Portage there, which I need to work through before I can make stages with it.

I won’t mention the link where to download them at this early stage, because these are über-experimental. They’re totally inappropriate to be used as a root userland, even on a crash-and-burn box at this stage, and will likely be that way until at least 2007.0 or even 2007.1. For those who know what they’re doing, I’m happy to provide the links to these experimental builds, ping me on IRC/IM, or shoot me an email.

On other news… the stable 32-bit glibc builds for 2006.1 will soon be moving to a mirror near you.
As always, I’ll keep you posted on the progress. 🙂

Gentoo/MIPS Cobalt: µClibc stages on their way

Hi All…

Whilst forging ahead into new territory for the Gentoo/MIPS project on the n32 front, I also figured now would be a good time to update the µClibc stages for mipsel.

I’ve completed a cross-compile from x86 of an entire mipsel environment, and I’m now just about to set this up to use as a seed stage in Catalyst.  Once this is done and I’ve bootstrapped a system with it, I should be set to build a full mipsel environment.  This will be compiled for MIPS-1 class CPUs, and thus should be compatable with embedded devices such as wireless routers.  Note: This does not mean we will officially start supporting wireless routers.  They are still officially unsupported, and users are very much on their own when troubleshooting problems on these devices.

I’ll keep you all posted on the progress. 🙂

Request for Comment: Cross (X) Network Black List for IRC (and other systems?)

I’m sure we’ve all seen it. IRC network spam, trolling, cracking… all kinds of abuse. However, unless I’ve been living under a rock lately, there doesn’t seem to be a co-ordinated approach at dealing with it.

I’m a regular user of both Freenode and AustNET IRC networks, and over the years, I’ve witnessed a number of network abuses, and I’ve seen how both networks here, handle such issues. But the issue is this, if a user abuses people on one network, what’s to stop them going and abusing another? Or even abusing people by other means, such as email?

Thus, I’m thinking… a cross-network black list would help here. It’d require co-operation between the various IRC network operators… but the idea is this. I’ll use a couple of actual examples here.

Example 1: This cretin, plonks bots on a number of AustNET channels, including #atomiclinux. Alledgidly he runs off with victim’s money and doesn’t deliver.  Nonetheless, it’s a nuisance we can do without.  Address information has been removed here:

--> itsmew (itsmew@xxx.xxx.xx.xxxxx) has joined #atomiclinux
hey people i have 2 portble notbook i need to sell immediately.  message me if interested on msn at this is just mike @ DOMAIN WITHELD
< -- itsmew has quit (Banned from AustNet: Must go now, one stolen laptop spammer)

Now, in this case it was pretty quickly dealt with.  We have had this chap go on unchallenged for hours.  I don't know if he spams other networks too.

Since this was on one network, it would be reported and would go into the blacklist, with the report comming from one network.  Owners of other networks may decide to act on the blacklist based on this first report, or they may wait for a couple of independant reporters to complain, depending on the severity of the inconvenience. They may also decide to block access to other services in order to prevent abuse via email or IM protocols.

Example 2: This troll, first spammed us on #atomiclinux.  Unfortunately though, none of us were awake, and thus he soon left...

Jul 26 00:41:55 --> l33t_h4x0r (l33t_h4x0r@vw-18983.as9105.com) has joined
#atomiclinux
Jul 26 00:41:57  i kno more about computas than u all im da best
hacker eva

A few days later, he turns up in #mipslinux on Freenode.  The log is rather long, so you can find it here instead, here he got booted out by Ralf Bächle.  The next day, he also pestered the people in #edev on the same network — unfortunately his lack of understanding of Australian fauna sent him packing.
In this situation, we now have 3 reports from 2 independant groups.  The chap would be blacklisted right then and there, and banned for an appropriate length of time.

How long would you ban someone?  Well, I guess it should depend on the number and type of past offences, as well as the number of reports regarding the current offence.  This could be based on a decaying figure that gets bumped up with each report, something like the demerit points system that driver’s licenses here in Australia have.  Thus various offences would be given a weighting, and it’d be the sum of points from each type of offence, that determines the final score.  Network admins could then decide how long to ban offenders, on a per-point basis.

This blacklist could work for other protocols too.  Why does email need a special blacklist database…?  This could be shared across a number of services.  The idea: a spammer may not be bothered about being banned on one IRC network.  But they won’t like it if every host on the internet now refuses to speak to them.  This would work well in Example 2 above, where the idiot decided to use the exact same host to do his trolling from.  The first example actually looks like a comprimised host — which is still a serious issue.  Even on IRC networks that don’t implement this… it is possible for IRC clients and bots to have such filters installed, allowing per-user or per-channel filtering, the bot only needs channel operator privileges to work.
It seems to me, that the nuisance problem won’t go away unless we actually become proactive and do something about it.  I might post more on this topic. There’s a lot of logistical issues to sort out (e.g. how do the reports get filed, how to deal with false alarms…etc.), but I do believe there is a need for some system like this.