A Man and his Penguin

A while back, some loser sent me a message on Ubuntu Forums, asking me how to hack into a Windows system "just so I can listen to their music". They followed me to MSN.

Now that I know about Goatse, I just replied to them and told them that www.goatse.cz had a lot of Windows hacking information.

I wonder if Ashton Kulcher will host a new show on MTV called "Goatse’d"?

A while back, some loser sent me a message on Ubuntu Forums, asking me how to hack into a Windows system "just so I can listen to their music". They followed me to MSN.

Now that I know about Goatse, I just replied to them and told them that www.goatse.cz had a lot of Windows hacking information.

I wonder if Ashton Kulcher will host a new show on MTV called "Goatse’d"?

A while back, some loser sent me a message on Ubuntu Forums, asking me how to hack into a Windows system "just so I can listen to their music". They followed me to MSN.

Now that I know about Goatse, I just replied to them and told them that www.goatse.cz had a lot of Windows hacking information.

I wonder if Ashton Kulcher will host a new show on MTV called "Goatse’d"?

The latest Copland Community Preview CD image, 14-3-7 (today’s) is currently booting on my iMac. I’ve got rid of the Debian logo from the XDM login screen (God, I can’t believe how fast XDM is!) and replaced it with the Copland logo.

This morning I did a search for the script that starts xfce4-session, and although I couldn’t find it, I did find some other XFCE startup-related scripts. I made some little modifications to these, rebuilt the disc image and that fixed TWO of the bugs!

That’s right, folks: xfdesktop starts automatically, and I don’t have three terminal windows on my screen. All I’ve got to do now is figure out why xfce4-panel isn’t loading, and then I believe we’ll be able to release the Community Preview!

There are two things you must see before you can regard yourself knowingly as a veteren of the Internet.

Tubgirl and Goatse.

And I finally saw the latter today. I even have the privilege of seeing the original message from the Cake Fart Man.

Also, go to www.museumofhoaxes.com. (this site is safe-for-work, as long as your workplace allows you to visit non-work-related sites)

And final part of this entry, I think I’ve managed to convince my boss to get in some more reliable stuff than Conia.

While much of the Linux world is focusing on finding a way to package binaries in a distro-independent manner, I have a solution working itself out in my head.

Source code is already distro-independent, right? (the ./configure scripts always work out where everything is). But source is a pain to install sometimes, with you needing to read the mind of the developer in order to guess what dependency you’re missing. And source is always unfriendly for newbies to install.

In addition, Debs, RPMs and Autopackages aren’t exactly a cakewalk to create. Oh sure, you can create a Checkinstall Deb, but it’s not a proper package with dependencies and stuff. Building a proper package is beyond the abilities of most volunteer helpdesk people (such as those as Ubuntu Forums).

So, why not create some sort of scripting framework for downloading, compiling and packaging source code? I have called my proposed framework "Bleeding Edge"

For instance, take the following code snippet:

from bleedingedge import *
require("libsdl1.2debian-all", Debian)
require("libsdl1.2", Mandriva)
require("sdl1.2", Suse)
require("libgl1-mesa", AllDistros)

sourceGet("http://www.sourceforget.net/myproject/myproject-beta.tgz")
configure()
make()
debian_install(maintainer="chris@hotmail.com")
rpm_install()

Let’s take this line by line:

from bleedingedge import * - This imports all the modules from my source management system into the local namespace, for simplicity. In a real implementation, an ImportError would then call a function that downloads and installs the Bleeding Edge module.

The "require" functions take two arguments and one option: The first is the package name that is a runtime dependency of "myproject", and the second is the distribution that it is relevent to. The Bleeding Edge module has already checked to see what distribution we’re compiling on, so it only runs the statements that are true for our distribution (including the "AllDistros" one later on).

The other option taken is for a specific version. Note that no actual build dependencies are listed: Bleeding Edge would know that the build dependency for "sdl1.2" is just "sdl1.2-devel" on Suse, for instance. Like any experienced Suse user would. If a particular make system is required (like Jam or Scons), that could be listed in the requires.

Sourceget() does what you’d expect - it downloads the source code as a compressed archive. However, it also untars and ungzips the source into a directory like /usr/src/.

Configure() would change into the correct directory before running the configure script. The output of ./configure is piped to a piece of code that checks for error messages. If Bleeding Edge detects errors to do with dependencies, it can search the Apt database for the missing dependencies, and then ask the user whether they want to try installing them. This is really to provide a means of debugging the script for the packager, and intelligently handle any human error that may occur at that time.

Make() would probably have to have its output directed to a file, and then have the file scanned afterward for error messages. Make’s error messages always have the same form, so it would be easy to spot. The user could be told that the package failed to install, if a message was encountered. Otherwise, execution would move onto the next step.

Debian_install() simply uses Checkinstall to install the package. But the packager can choose to supply keyword arguments which will tell Checkinstall what information to put into the package, such as "maintainer" (shown here). But what’s this? Checkinstall would automatically put "beta" as the package version - dpkg will not allow this, so Checkinstall would fail. However, Bleeding Edge is smart enough to know dpkg’s rules, and will prompt the user to choose a proper version number (suggesting 0.9 as the default for "beta").

If we were on an RPM based system, the debian_install() function would not be called, and instead the rpm_install() function would run. I have no idea if an alternative to Checkinstall works for RPM systems, so I’m hazy on how this particular link would work.

See what I mean? This is a simple example and easy to write. Yet, it provides a lot of opportunities for error correction. For installations like Firefox 2, where you need to move files around to get the software to compile and run, Bleeding Edge would provide safe interfaces to the mv and rm programs (so files can be moved back to their original places should the package be uninstalled). Also, distro-specific parts (like specifying the location of Lua for installing Aleph One on Ubuntu) can be handled without confusing the other distros, because Bleeding Edge will not run parts of the script that are inappropriate.

Best of all, you can get up-to-the-minute software for all architectures, without dependency hell and without going to the command line. The finished package is optimised to your system and registered with the native package manager. Unlike other packaging formats, the installer script which runs as root is human-readable, so you can check that it’s not malicious. A package would only take up the same size as the source code (plus a kilobyte or two) and you can even use the system to install binaries!

I’d love to get started on this system for Copland 1, and introduce it to other distributions, but I still have to finish Copland 0 first! I hope hope hope that I can do the latter very soon, and that I get a number of programmers to take on the load of creating other programs so I can work on Bleeding Edge.

While much of the Linux world is focusing on finding a way to package binaries in a distro-independent manner, I have a solution working itself out in my head.

Source code is already distro-independent, right? (the ./configure scripts always work out where everything is). But source is a pain to install sometimes, with you needing to read the mind of the developer in order to guess what dependency you’re missing. And source is always unfriendly for newbies to install.

In addition, Debs, RPMs and Autopackages aren’t exactly a cakewalk to create. Oh sure, you can create a Checkinstall Deb, but it’s not a proper package with dependencies and stuff. Building a proper package is beyond the abilities of most volunteer helpdesk people (such as those as Ubuntu Forums).

So, why not create some sort of scripting framework for downloading, compiling and packaging source code? I have called my proposed framework "Bleeding Edge"

For instance, take the following code snippet:

from bleedingedge import *
require("libsdl1.2debian-all", Debian)
require("libsdl1.2", Mandriva)
require("sdl1.2", Suse)
require("libgl1-mesa", AllDistros)

sourceGet("http://www.sourceforget.net/myproject/myproject-beta.tgz")
configure()
make()
debian_install(maintainer="chris@hotmail.com")
rpm_install()

Let’s take this line by line:

from bleedingedge import * - This imports all the modules from my source management system into the local namespace, for simplicity. In a real implementation, an ImportError would then call a function that downloads and installs the Bleeding Edge module.

The "require" functions take two arguments and one option: The first is the package name that is a runtime dependency of "myproject", and the second is the distribution that it is relevent to. The Bleeding Edge module has already checked to see what distribution we’re compiling on, so it only runs the statements that are true for our distribution (including the "AllDistros" one later on).

The other option taken is for a specific version. Note that no actual build dependencies are listed: Bleeding Edge would know that the build dependency for "sdl1.2" is just "sdl1.2-devel" on Suse, for instance. Like any experienced Suse user would. If a particular make system is required (like Jam or Scons), that could be listed in the requires.

Sourceget() does what you’d expect - it downloads the source code as a compressed archive. However, it also untars and ungzips the source into a directory like /usr/src/.

Configure() would change into the correct directory before running the configure script. The output of ./configure is piped to a piece of code that checks for error messages. If Bleeding Edge detects errors to do with dependencies, it can search the Apt database for the missing dependencies, and then ask the user whether they want to try installing them. This is really to provide a means of debugging the script for the packager, and intelligently handle any human error that may occur at that time.

Make() would probably have to have its output directed to a file, and then have the file scanned afterward for error messages. Make’s error messages always have the same form, so it would be easy to spot. The user could be told that the package failed to install, if a message was encountered. Otherwise, execution would move onto the next step.

Debian_install() simply uses Checkinstall to install the package. But the packager can choose to supply keyword arguments which will tell Checkinstall what information to put into the package, such as "maintainer" (shown here). But what’s this? Checkinstall would automatically put "beta" as the package version - dpkg will not allow this, so Checkinstall would fail. However, Bleeding Edge is smart enough to know dpkg’s rules, and will prompt the user to choose a proper version number (suggesting 0.9 as the default for "beta").

If we were on an RPM based system, the debian_install() function would not be called, and instead the rpm_install() function would run. I have no idea if an alternative to Checkinstall works for RPM systems, so I’m hazy on how this particular link would work.

See what I mean? This is a simple example and easy to write. Yet, it provides a lot of opportunities for error correction. For installations like Firefox 2, where you need to move files around to get the software to compile and run, Bleeding Edge would provide safe interfaces to the mv and rm programs (so files can be moved back to their original places should the package be uninstalled). Also, distro-specific parts (like specifying the location of Lua for installing Aleph One on Ubuntu) can be handled without confusing the other distros, because Bleeding Edge will not run parts of the script that are inappropriate.

Best of all, you can get up-to-the-minute software for all architectures, without dependency hell and without going to the command line. The finished package is optimised to your system and registered with the native package manager. Unlike other packaging formats, the installer script which runs as root is human-readable, so you can check that it’s not malicious. A package would only take up the same size as the source code (plus a kilobyte or two) and you can even use the system to install binaries!

I’d love to get started on this system for Copland 1, and introduce it to other distributions, but I still have to finish Copland 0 first! I hope hope hope that I can do the latter very soon, and that I get a number of programmers to take on the load of creating other programs so I can work on Bleeding Edge.

While much of the Linux world is focusing on finding a way to package binaries in a distro-independent manner, I have a solution working itself out in my head.

Source code is already distro-independent, right? (the ./configure scripts always work out where everything is). But source is a pain to install sometimes, with you needing to read the mind of the developer in order to guess what dependency you’re missing. And source is always unfriendly for newbies to install.

In addition, Debs, RPMs and Autopackages aren’t exactly a cakewalk to create. Oh sure, you can create a Checkinstall Deb, but it’s not a proper package with dependencies and stuff. Building a proper package is beyond the abilities of most volunteer helpdesk people (such as those as Ubuntu Forums).

So, why not create some sort of scripting framework for downloading, compiling and packaging source code? I have called my proposed framework "Bleeding Edge"

For instance, take the following code snippet:

from bleedingedge import *
require("libsdl1.2debian-all", Debian)
require("libsdl1.2", Mandriva)
require("sdl1.2", Suse)
require("libgl1-mesa", AllDistros)

sourceGet("http://www.sourceforget.net/myproject/myproject-beta.tgz")
configure()
make()
debian_install(maintainer="chris@hotmail.com")
rpm_install()

Let’s take this line by line:

from bleedingedge import * - This imports all the modules from my source management system into the local namespace, for simplicity. In a real implementation, an ImportError would then call a function that downloads and installs the Bleeding Edge module.

The "require" functions take two arguments and one option: The first is the package name that is a runtime dependency of "myproject", and the second is the distribution that it is relevent to. The Bleeding Edge module has already checked to see what distribution we’re compiling on, so it only runs the statements that are true for our distribution (including the "AllDistros" one later on).

The other option taken is for a specific version. Note that no actual build dependencies are listed: Bleeding Edge would know that the build dependency for "sdl1.2" is just "sdl1.2-devel" on Suse, for instance. Like any experienced Suse user would. If a particular make system is required (like Jam or Scons), that could be listed in the requires.

Sourceget() does what you’d expect - it downloads the source code as a compressed archive. However, it also untars and ungzips the source into a directory like /usr/src/.

Configure() would change into the correct directory before running the configure script. The output of ./configure is piped to a piece of code that checks for error messages. If Bleeding Edge detects errors to do with dependencies, it can search the Apt database for the missing dependencies, and then ask the user whether they want to try installing them. This is really to provide a means of debugging the script for the packager, and intelligently handle any human error that may occur at that time.

Make() would probably have to have its output directed to a file, and then have the file scanned afterward for error messages. Make’s error messages always have the same form, so it would be easy to spot. The user could be told that the package failed to install, if a message was encountered. Otherwise, execution would move onto the next step.

Debian_install() simply uses Checkinstall to install the package. But the packager can choose to supply keyword arguments which will tell Checkinstall what information to put into the package, such as "maintainer" (shown here). But what’s this? Checkinstall would automatically put "beta" as the package version - dpkg will not allow this, so Checkinstall would fail. However, Bleeding Edge is smart enough to know dpkg’s rules, and will prompt the user to choose a proper version number (suggesting 0.9 as the default for "beta").

If we were on an RPM based system, the debian_install() function would not be called, and instead the rpm_install() function would run. I have no idea if an alternative to Checkinstall works for RPM systems, so I’m hazy on how this particular link would work.

See what I mean? This is a simple example and easy to write. Yet, it provides a lot of opportunities for error correction. For installations like Firefox 2, where you need to move files around to get the software to compile and run, Bleeding Edge would provide safe interfaces to the mv and rm programs (so files can be moved back to their original places should the package be uninstalled). Also, distro-specific parts (like specifying the location of Lua for installing Aleph One on Ubuntu) can be handled without confusing the other distros, because Bleeding Edge will not run parts of the script that are inappropriate.

Best of all, you can get up-to-the-minute software for all architectures, without dependency hell and without going to the command line. The finished package is optimised to your system and registered with the native package manager. Unlike other packaging formats, the installer script which runs as root is human-readable, so you can check that it’s not malicious. A package would only take up the same size as the source code (plus a kilobyte or two) and you can even use the system to install binaries!

I’d love to get started on this system for Copland 1, and introduce it to other distributions, but I still have to finish Copland 0 first! I hope hope hope that I can do the latter very soon, and that I get a number of programmers to take on the load of creating other programs so I can work on Bleeding Edge.

While much of the Linux world is focusing on finding a way to package binaries in a distro-independent manner, I have a solution working itself out in my head.

Source code is already distro-independent, right? (the ./configure scripts always work out where everything is). But source is a pain to install sometimes, with you needing to read the mind of the developer in order to guess what dependency you’re missing. And source is always unfriendly for newbies to install.

In addition, Debs, RPMs and Autopackages aren’t exactly a cakewalk to create. Oh sure, you can create a Checkinstall Deb, but it’s not a proper package with dependencies and stuff. Building a proper package is beyond the abilities of most volunteer helpdesk people (such as those as Ubuntu Forums).

So, why not create some sort of scripting framework for downloading, compiling and packaging source code? I have called my proposed framework "Bleeding Edge"

For instance, take the following code snippet:

from bleedingedge import *
require("libsdl1.2debian-all", Debian)
require("libsdl1.2", Mandriva)
require("sdl1.2", Suse)
require("libgl1-mesa", AllDistros)

sourceGet("http://www.sourceforget.net/myproject/myproject-beta.tgz")
configure()
make()
debian_install(maintainer="chris@hotmail.com")
rpm_install()

Let’s take this line by line:

from bleedingedge import * - This imports all the modules from my source management system into the local namespace, for simplicity. In a real implementation, an ImportError would then call a function that downloads and installs the Bleeding Edge module.

The "require" functions take two arguments and one option: The first is the package name that is a runtime dependency of "myproject", and the second is the distribution that it is relevent to. The Bleeding Edge module has already checked to see what distribution we’re compiling on, so it only runs the statements that are true for our distribution (including the "AllDistros" one later on).

The other option taken is for a specific version. Note that no actual build dependencies are listed: Bleeding Edge would know that the build dependency for "sdl1.2" is just "sdl1.2-devel" on Suse, for instance. Like any experienced Suse user would. If a particular make system is required (like Jam or Scons), that could be listed in the requires.

Sourceget() does what you’d expect - it downloads the source code as a compressed archive. However, it also untars and ungzips the source into a directory like /usr/src/.

Configure() would change into the correct directory before running the configure script. The output of ./configure is piped to a piece of code that checks for error messages. If Bleeding Edge detects errors to do with dependencies, it can search the Apt database for the missing dependencies, and then ask the user whether they want to try installing them. This is really to provide a means of debugging the script for the packager, and intelligently handle any human error that may occur at that time.

Make() would probably have to have its output directed to a file, and then have the file scanned afterward for error messages. Make’s error messages always have the same form, so it would be easy to spot. The user could be told that the package failed to install, if a message was encountered. Otherwise, execution would move onto the next step.

Debian_install() simply uses Checkinstall to install the package. But the packager can choose to supply keyword arguments which will tell Checkinstall what information to put into the package, such as "maintainer" (shown here). But what’s this? Checkinstall would automatically put "beta" as the package version - dpkg will not allow this, so Checkinstall would fail. However, Bleeding Edge is smart enough to know dpkg’s rules, and will prompt the user to choose a proper version number (suggesting 0.9 as the default for "beta").

If we were on an RPM based system, the debian_install() function would not be called, and instead the rpm_install() function would run. I have no idea if an alternative to Checkinstall works for RPM systems, so I’m hazy on how this particular link would work.

See what I mean? This is a simple example and easy to write. Yet, it provides a lot of opportunities for error correction. For installations like Firefox 2, where you need to move files around to get the software to compile and run, Bleeding Edge would provide safe interfaces to the mv and rm programs (so files can be moved back to their original places should the package be uninstalled). Also, distro-specific parts (like specifying the location of Lua for installing Aleph One on Ubuntu) can be handled without confusing the other distros, because Bleeding Edge will not run parts of the script that are inappropriate.

Best of all, you can get up-to-the-minute software for all architectures, without dependency hell and without going to the command line. The finished package is optimised to your system and registered with the native package manager. Unlike other packaging formats, the installer script which runs as root is human-readable, so you can check that it’s not malicious. A package would only take up the same size as the source code (plus a kilobyte or two) and you can even use the system to install binaries!

I’d love to get started on this system for Copland 1, and introduce it to other distributions, but I still have to finish Copland 0 first! I hope hope hope that I can do the latter very soon, and that I get a number of programmers to take on the load of creating other programs so I can work on Bleeding Edge.

1. When XDM comes up, it has the Debian logo on it (being fixed for copland-cp-110307)

2. Automounter still doesn’t work - I still have no idea why not

3. Add/Remove Applications has the word "Ubuntu" in one of its dialogs (being fixed for copland-cp-110307)

4. XFCE’s logout panel button just kills the panel itself - due to Bug #6. (panel logout button will be removed in next CD image)

5. CRITICAL: "Leave this computer…" menu item just gives an error about xfce4-session not being open. Due to Bug #6.

6. CRITICAL: xfce4-session is crashing on startup. Very little of Xfce starts up before the crash happens - panel and desktop must be started manually. Thanks to someone on #xubuntu for giving me the idea to check if xfce4-session is open. This is an upstream bug, but I will work around it in copland-cp-110307.

The workaround for bugs 4-6?  Write my own logout program in Pythoncard, and write my own session manager (I’m serious; but all it will do is start xfce4-panel and xfdesktop) in shell scripting.

I also just got the idea that the automounter might not be working if it’s a service that is started by xfce4-session. I’ll check on that.

Finally, I’d just like to close by saying that you shouldn’t buy any consumer electronics by Conia or Hyundai. Their HD set-top-boxes never last longer than a couple of months, and recently one of their DVD recorders went belly-up after just 12 hours of being in the person’s home.