Archive for June, 2005

I was making a journey in the peer to peer file sharing world. I wanted to know which network is worth using. Until this time I believed that Direct Connect is the most superior network, but I'm compeletly reframed after I expanded my horizont.

It seems that the best network is eDonkey 2000. There are some reasons why:

• no stupid hub rules
• rare files are more accessible because of the balancing algorithm
• much more users (5 million) accessible simultaneously than on all the DC hubs together

I'm just scratching the surface here. As far as I know, the protocol is also better in more aspects, primarily regarding error handling. For me, DC is dead. There is one disadvantage however. If you download much faster than you upload (typical DSL situation), then the overall download speed on eDonkey will be less than on DC because the upload/download ratio should be around 1 by protocol specification. Fortunately it's only bad for leeches and I'm not one of them.

You can get some awesome statistics on the networks, as well as documentation on the available clients at Wikipedia and zeropaid.

Linux lacks sane defaults in a lot of areas. One of them is mounting a samba share with

mount -t smbfs -o
password=mypassword,codepage=cp852,iocharset=iso8859-2,uid=lee,gid=users,fmask=644,dmask=755
//hostname/sharename targetdir

or mounting a pendrive using the corresponding fstab line

/dev/sda1 /mnt/pendrive auto rw,user,noauto,shortname=mixed,dmask=022,fmask=133 0 0

There should be some kind of higher level configuration layer because that's above is what most users want.

Power 0.2 released

I've just released power 0.2. It has several small improvements.

I've just read a nice article titled The Programming Gene. It's about the three programming paradigms I'm interested in most: aspect-oriented programming, genetic programming and intentional programming.

Regarding aspect-oriented programming, AspectJ is here for a while and I wanna play with it as soon as I can. Python also has aspect-oriented features, so it's probably worth checking it out.

Genetic programming is a method which doesn't require special language features, but implementing its model in any language.

Intentional programming is a bit vague and conceptual yet, but one can learn many things about it by reading the fresh blog intentional software has put out. Very interesting read. Makes one think in new perspectives. I very dislike their way of making the source locked in an obscure proprietary format.

One of my best friends has just pointed out to a very good online self help book. It has got some interesting topics and statistics in it.

StrongDC++ Rulez

Are you using DC++? It's time to upgrade to StrongDC++. It's full of usable features. The GUI is much more intuitive, supports segmented downloading, and has many more cool features.

It's a shame that there isn't exists a quality DC client for Linux. Some would say Valknut is good enough. In my expericence, it's far from the truth.

Seriously, I'm open to many things, but this one just sounds ridiculous.

Hey, I wanna nice nice tits too! Should I consider using this stuff?

You shouldn't buy Princo DVDs. They are a piece of shit. Really. This is not "Write once", but "Write once and pray" kind of category.

Miguel in Antitrust

One of my very favourite movies, Antitrust features Miguel De Icaza. I've just wathced the related scene. Cool.

Zope versus PHP

Zope has a really unique architecture. I'm not an expert, but I know some things about it and wanna learn more in the future. I thought it's a very powerful platform to build on. I was interested why it is that PHP is used everywhere and Zope is not (well) known to the average web developer so I went after the topic and have found a thread called "PHP vs. Zope/Plone? Which better overall and for what?" on the topic. In short, Zope's nature as an application server, as a framework, and as a paradigm makes it alien and hard to grasp to the masses despite its power. It's also possible that Zope runs slower than PHP, althought I guess the difference is probably not that significant. PHP may also rule in cases where the given task is very special in nature.

Python Challenge

Python Challenge offers you the most fun way learning Python. Every pythonian should check it out.

Holy shit! It's hard to me to believe this really has happened. There is a fierce battle going on between Hungarian ISPs for a while. It goes like this: One decides to raise its cusomer's bandwidth. He gains advantage. The others don't want to leg behind him so they make the same decision. Yesterday I had 512/128K and today it's 1024/160K. Cool!

Messing with Fonts

It's relatively painful setting up correctly the coding and the fonts for a semi-hungarian installation. For me this kind of coding means native encoding, but foreign (English) language. Here is the Debian way:

# echo 'en_US ISO-8859-2' >> /etc/locale.gen
# locale-gen
# echo 'LANG=en_US.ISO-8859-2' >> /etc/environment
# echo 'G_FILENAME_ENCODING=ISO-8859-2  # several gnome apps need this' >> /etc/environment

After that I realized that several characters (? and ?) didn't show up correctly in konsole, so I checked for alternative fonts. At the same time I wanted bitmapped fonts because they render much faster than the others, so I went allowing them.

# dpkg-reconfigure fontconfig

Then I realized that KDE apps look like shit because they use unantialised fonts. I made contact with several Debian developers and have figured out that KDE uses bitmapped fonts by default. Bitmapped fonts were not allowed in the beginning so KDE falled back to outline fonts. After I set the default fonts in kcontrol, everything were fine.

101 Things to Know about GNOME

GUADEC 2005 is over. Here's a nice presentation on the history and direction of GNOME. It's both really informative and very funny.

I'm currently working on a Python application that has about 1500 lines of code. The whole stuff was in one file and it was a pain maintaining it in this form so I decided to make separate files per classes. At the same time a class browser would really skyrocket my productivity, I thought. Throughout the development I used mcedit, later Emacs, then Kwrite and my last choice is eric3, a fascinating Python IDE with class browser and lots of goodies. The only thing I don't like in it is the Qt GUI, but user interface inconsistency probably won't kill me.

My switch from mcedit to Emacs is not hard to understand I guess considering its features and the fact that I love it. But my next switch from Emacs to Kwrite doesn't make much sense, right? I can justify my decision with one word: Indentation.

When I moved to Emacs and visited the original source file, I observed that the lines are incorrectly indented in it. When I changed several of them, Python immediately reported the indentation errors as soon as I executed the script. At that time I just wanted to get over the whole thing, tried Kwrite and it handled the indentation correctly. After that when the code has grown bigger and I needed eric3, the same problem happened and I had no choice then. I had to investigate this problem.

After some time, I realized that a lot of *nix editors (like mcedit) uses half-tabs. That's an evil concept. It's basically the most stupid way one can encode indentation.

In the simplest case, there were only tabs or spaces. In a more complex case, there were both tabs and spaces and tabs had a fixed size. And finally in the braindead case, there were half-tabs. I've written spacify.py that solves this problem by converting half-tabs to spaces.

Update: In the meantime I've realized that the GNU expand utility does the same thing and is much more mature than my spacify script, so you should probably use expand.

I'm using 100% Debian Unstable. There is another distribution of Debian which is named experimental. Thinking back some years earlier I believe it didn't existed then, but I won't try it because that's probably really unstable, not like "unstable".

Beyond Relational Databases

Here is a nice article on the topic. Very interesting. It widens one's perspective. Many of us, geeks, and I'm sure on other areas of life as well, we like to create universal tools, paradigms. The problem is, that most of the time these systems don't work very well in practice. That's probably because we discount several important aspects of the picture and/or we don't have enough knowledge about the problem and we end up something not-so-usable and not-so-highly-generalized stuff.