Since Apple dropped PPC, the Linux PPC world is quite in turmoil. The architecture is perceived as almost dead. However, new interest comes from the Linux on PS3 projects.

In any case Ubuntu dropped official support for PPC. That was a sad piece of new, since I was quite satisfied with it. I had to recompile the kernel in order to fully support my machine (but this would have been solved in successive releases).

I got back to Debian. I’ve been a Debian user since Woody, and I liked it ever since. I was a Debian unstable user, and I have always been satisfied with it. However, this time it was different. I’ve had many more troubles: each upgrade broke something I needed.

I don’t know if it’s a matter of developers paying more attention to Ubuntu or whatever: the point is that using Debian unstable as a ‘reliable’ desktop system on power pc seemed quite hard. I don’t want to blame Debian developers: it’s unstable. No warranties. I used it at my own risk.

Since Debian is unsuitable for my present needs (no hassle, no config, no time), I considered switching Yellow Dog. I know that these days a PPC community mantained version of Ubuntu has been released.

I bought a Yellow Dog Enhanced account, since I did want to support their work and I was interested in support, if something was not perferct in the first place. Remember, no time.

I installed the distribution from the DVD. My hardware was entirely recognized correctly. From the soundcard to the backlit keyboard. My video card should also work with dual head, though I haven’t tried it yet. YD comes with a nice GUI to do this.

The only thing that was not working was the airport card. I just had to get the fwcutter and extract the firmware. Then it worked. Moreover, the network applet that stays in the notification area works great. I don’t know why, but in Debian and Ubuntu for some reasons it did not work properly (in Ubuntu from a certain moment the whole network-manager stopped working). I did not investigate as I needed less time to write a couple of shell scripts to configure the network interfaces when I needed to switch.

I have always been skeptical about rpm-based distros. Once I used SuSE, but after using Debian I got somewhat convinced of the superiority of the Debian packages. More accurate studies on rpm done recently seem to go in another direction: it was not that deb is better than rpm. It is just that deb repositories were maintained more carefully.

YellowDog repositories are maintained quite carefully. However, there is not a lot of software. I suppose something like 1000 packages (Debian has got ten times that). So I had to learn how to cook my own rpms or simply build software from sources and install it with make install. This is probably the major drawback. However, I’m pretty satisfied with Yellow Dog.

However, it lacks a lot of software packages. Most of them can be
taken from Fedora PPC (it’s advised to use those of Fedora Core 5
or). However, other must be compiled.

For example, I had to compile swi-prolog, since the software I’m working
on at the moment is written in Prolog. Swi Prolog itself was easy to install.
I compiled it and I had it working in a few minutes.

However, I was unable to compile XPCE. While I do not use the library itself,
I find it useful sometimes to use gtrace or the ‘graphic’ help.
The problem reported was that Xpm was not found. However, I installed
both libxpm and its development files. The ./configure script reported
that it was not able to link against libXpm.

I first tried manually linking and it worked, so I had a look at the log.
In fact it wasn’t libxpm fault. The test program tried to link both libxpm
and libxt, and the latter failed. Amazingly, the configure script did not
check for errors in linking libxt, so the erroro reported was totally
misleading.
The problem was that there was no libXt.so, but only libXt.so.6. I had to
manually create the symbolic link.

Eventually, I bumped into another error (this time during ‘make’).
The culprit was once again Xt: it seemed that some of its ’standard’ header
files were missing. I found a fedora 5 devel package that fixed that
and I was able to compile xpce.

Quite unfortunately, I can’t use it now. Another bug in the installation of
xorg conjures against me. This bug can be seen using a Tkinter canvas too.
The problem is that ‘names’ of colors are not found (probably because rgb.txt
is in the wrong place). Xpce fails and so does many stuff with Tkinter.

I don’t know where rgb.txt should be. I tried to put it in standard places,
but up to now the server does not find it. The problem is that I have to restart the server each time (and since sometimes this hangs the whole system, I have to reboot, and Red Hat derived distros have slow boots.)

Per cui, nel caso, le linko.
Link.

Per cui, nel caso, le linko.
Link.

It was a matter of mod-probing i2c-dev.
It is a custom Linux 2.6.20 Kernel on Debian Unstable. Cool!

The standard procedure would be running synaptic again and then loading the markings.
However, in this cases I don’t feel like I need to start the whole synaptic thing.
I’d prefer a small command line utility that processes the saved markings.

I wrote one. It is very simple. It uses sudo, so every now and then it asks the password.
Of course one could do a better job, but I had not time to do something better.

#!/usr/bin/env ruby

args = $*
if args.size == 0
  puts "You should provide a file to process"
  exit 0
end

dict = Hash.new

File.open(args[0]) do |f|
  f.each_line do |line|
    key, action = *line.split
    dict[key] = action
  end
end

# sudo apt-get #{v} #{k}

dict.each do |k, v|
  exec(”sudo apt-get -y #{v} #{k}”) if fork.nil?
  Process.wait
end

From Wikipedia we read that:

Scripting languages (commonly called scripting programming languages or script languages) are computer programming languages that are typically interpreted and can be typed directly from a keyboard. Thus, scripts are often distinguished from programs, because programs are converted permanently into binary executable files (i.e., zeros and ones) before they are run. Scripts remain in their original form and are interpreted command-by-command each time they are run. Scripts were created to shorten the traditional edit-compile-link-run process.

Of course any self respecting computer scientist knows that definition is meaningless, because a language is a mathematical construct
and is not tied to its implementation. You can write a C interpreter, for example (and there are some). You can also write a compiler for any ‘interpreted language’ (of course the term ‘interpreted language is also meaningless). And there are theoretical constructs (Futamura projections) that given any interpreter are able to build a compiler from it (you could implement them even in practice, though it would be terribly inefficient).

However, any other definition would be misleading as well: if you define a scripting language as a language you can use to “script” (as in “bash script”), then you’ve got definition that’s even more stupid. bash is a scripting language, and so it is Python. However, if someone writes an application that is scripted in C, C becomes a ’scripting language’).

Both definitions have an additional problem: scripting languages are considered somewhat inferior to ‘non-scripting languages’. Some even use the term ‘true programming languages’ (and this ‘true programming languages’ are usually considered to be C and C++, for example).

Lisp, Haskell, OCaml, Prolog

In this dissertation on ’scripting languages’, Lisp is quite emblematic. Lisp can be compiled (there are some Lisp compilers around). But Lisp can also be interpreted. This is one of the most
widespread Lisp environments (and it is an interpreter). Moreover, in Emacs you can just run some Lisp snippets. And Emacs itself is scripted in Lisp (thus Lisp would be a scripting language according to the second definition). However, no one can assert that it is not a ‘true’ programming language. Emacs itself is a beautiful (and complex) piece of software, and a lot of ‘real’ (and extremely difficult) stuff in the AI field has been written in Lisp.

Haskell can be another example. Hugs is an interpreter, ghc is both an interpreter and a compiler. And Haskell is even statically typed (so you see, being dynamic is
not necessary ). The very same applies for OCaml or Prolog. And all this
languages have been used by the most theory-oriented computer scientist to
implement real programs.

I suppose nobody would say that Lisp or Haskell are ’scripting languages’ (even if according to the definitions they are — Haskell is used in many configuration tools by Linspire programmers).

Bash, Perl, Python, Ruby.

All this languages have been labeled as ’scripting languages’. And in fact according to definitions, they are. However, they are very different languages.

Bash is a very simple language designed to do simple things. Unix system administrators used it intensively (along with awk and sed and other utilities) to automate many repetitive tasks. Although this is surely ‘programming’, in some sense it’s different from programming an application from scratch. Some even consider it a ‘lower level’ kind of programming (and surely we must recognize that skills involved in writing a boot script are different from skills used to write a compiler)

Perl was born in this environment: its goal was textual manipulations and interactions between processes in a system. It is a nicer alternative to bash + awk in many situations. Later it has been added a fully fledged object model, but in the while it has been used to write very complex applications that go outside the ‘lower level programming domain’ that is usually associated with ’scripting’. Even though I don’t like Perl anymore, it is a general purpose language, with the same dignity of C or C++.

The ’scripting language’ monicker is not fitting anymore. And it is even less fitting for Python. Python has been an object oriented programming language from the beginning. Good software engineering practices have always been employed. However, many consider it just another scripting language. And of course Python makes a great scripting language.

The domains in which Python excels are the same in which Java is used, for example. However, Python can be used for scripting, too. That is to say… some (and I’d be tempted to say ‘most’ ) ’scripting languages’ can be used both as general purpose languages and automation/scripting.

The reason why they can be used for automation/scripting and that they are easier to use and we can write programs faster. The development cycle is faster, too. And to me, they all seem good properties.

I think that the very same features that make Python (or Ruby) great for scripting, make it even greater for general purpose programming. That is to say we should consider a ’scripting language’ not a poorer language, but a better one (yeah, of course this is exaggerated, since there are languages suited for scripting that are not suited for general purpose programming — AppleScript and bash, for example).

Unfortunately enough emacsclient just quits if there is no active emacs server.

I need a process that tries to run emacsclient: if there is no active server, it runs emacs.
Moreover, emacsclient has a -n switch that makes it return ASAP, so the terminal is available for more commands.
emacs has not such a switch, but that behaviour is the one I want.

So I decided to write a small ruby script that does just this:

1. Tries to run emacsclient with the -n option.
2. If it succeeds, we are done. Otherwise we run Emacs doing some
   standard posix process manipulation in order to return to the shell as soon as possible.

This is the script:

#!/usr/bin/env ruby

fork do
  exec('emacsclient', '-n', *$*)
end
Process.wait
if $?.exitstatus != 0
  fork do
    Process.setsid
    Signal.trap('HUP', 'SIG_IGN')
    exec('emacs', *$*) if fork.nil?
    exit!(0)
  end
  Process.wait
end

Recently there are rumors that Ubuntu PPC will be discontinued.
In fact there is an IRC log about it:

Something asked a few times: Will PPC support be discontinued soon?
We will make a final decision on PPC for Feisty by the end of next week
if there is sufficient community contribution on this, then the community port can be just as good as a Canonical-supported one
we would keep the builds in place, but not block the release if things failed to build
so if people step up to unblock issues when they occur, then PPC would be on the same footing as it currently is
sabdfl, will “but ps3 is ppc” be a valid argument? (asked a few times as well)
the extra architecture costs us a lot in terms of testing bandwidth at release time, and figuring out issues like how to deal with the live CD are compicated
if SONY fund Ubuntu-on-PS3 then I guarantee it will happen

I have to say I’ve not been pleased about it. Of course Canonical should make its own interests: that is to say, if they feel that supporting PPC is not worth it, they are doing the right thing. However, it’s quite sad: there are a loto of perfectly functioning G3, G4 and G5 machines out there. Dropping support like this, seems to be the way commercial companies act.

The point is that we must realize that Canonical is a commercial company. You just can’t do anything about it and accept it.

Since at the moment I run Linux mostly on a PPC machine (my notebook), PPC support becomes a key factor in chosing the right distribution. My choice was obvious: I had been using Debian for ages before Ubuntu, why not going back to Debian? Welcome home, Debian!

Debian PPC

I downloaded the DVD iso for testing. Since I’m running on PPC, the new graphical installer is still experimental. Moreover, I quite feel at home with good old Debian textual installer.

Installation was really smooth. Debian recognised all my hardware with no need for manual intervention. Of course the airport card did not work without bcm43xx-fwcutter. Unfortunately enough, I left my working ethernet cable at the university, in the office I share with some fellow students. This was just a small delay.

Quite interesting Debian recognised my display better than Ubuntu (I still don’t know why, but I had to set the resolution manually or Ubuntu would not start X11). However, Debian did not preload pbbuttons (that are used for the notebook multimedia keys, volume, lcd backlight, etc).

In fact I think a noob prefers to find a system with no multimedia buttons and working graphics than vice-versa. It seems that the guys at Debian did a pretty good work. Nonetheless, I’m quite sad for the exclusion of pbbuttons: I did chose a macro-package (when installing) called ‘laptop’ or something like that. I think that pbbuttons should be included in the first DVD. In fact most PPC machine out there should be laptops (well, maybe not ‘most’, but surely a great number).

Everything else worked smoothly. I recompiled the kernel (I would like to have that backlit keyboard working, it should work even with the 2.6.18 default kernel, but maybe something useful was not compiled into it). The backlit keyboard still does not work, which is a pity, but is something I can live without. Beryl does not work too (but it didn’t work with Ubuntu, either). And it should work. But that is another thing I can happily live without.