Page: 0 ... 5 ... 10 ... 15 ... 20
Gnome + KDE d'n'd
Date: 30/4/2004
I was just attaching some files to an email in Linux, and you know what? It's really quick if you don't use a Gnome or KDE application as the source or destination.

For years now I've been bemoaning the craptacular lack of speed that Linux GUI apps seem to be chained to. But now that I've written a) a file manager and b) an email client for Linux I see it's not the GUI (i.e. X11) that is necessarily at fault here, it's also the applications.

You see when I drag a file from my file manager to my email client it works wonderfully. No jerking cursor, halts or long waits. It's all smooth and easy. But if I use the KDE file manager it's a mess of stuttering cursor's trails across the screen, delays and bugs when you touch the edge of a window.

I can see it now... "Matt's Linux distro"... no Gnome, no Kde... just quick and lean little applications to GET WORK DONE.


Maybe not... to "popular culture" for my taste... The Matrix is still a bitter wound in my memory that hasn't healed.

"Mattoo!" - A flavour of gentoo?
(0) Comments | Add Comment

i.Task on Debian
Date: 27/4/2004
I've heard that on Debian GNU/Linux 3.0r2 i.Task displays an error when trying to load saying it can't find the symbol 'dlopen'. So I've fixed the libraries that it links against and put a new build here.

Would someone with that OS be able to test it for me?

I'd like to know if my fix worked or not.
Update: Looks like it's fixed... thanks.
(0) Comments | Add Comment

For Sale: Fender Strat
Date: 22/4/2004
I'm selling my strat, if you interested take a look.
(0) Comments | Add Comment

i.Task Released
Date: 20/4/2004
I've released a new application for watching processes under Linux called i.Task.

Source and binaries are available.
(0) Comments | Add Comment

The new breed
Date: 11/4/2004
As if bombarding my Inbox with hundreds of small viruses, spams and scams each day wasn't enough the malware authors in their infinite wisdom are now trying to DDOS me with 1.12MB viruses.

Which must take their toll on the senders bandwidth. You can't bang them out like the 29KB rodents that I usually get. Gee, just when you thought you'd seen it all.

Currently I've written a filter to delete anything with a zip attachment as spam. So if you are trying to send me something for the first time I suggest not zipping it so that I don't filter it out.
(0) Comments | Add Comment

Scribe Dropped Mail Bug
Date: 7/4/2004
I think I may have found the cause of Scribe dropping mail, ie. downloading it but not inserting it into the mail folders.

In test9 I tried to prevent Scribe from deleting the mail from the server if the download failed. Which should mean that at least the mail is doesn't disappear. However that doesn't solve the bug it just stops the data from being lost.

Now I've discovered what I believe to be the root cause in the POP receive code where if the initial recv on the connection contains the entire message (ie. small message + fast connection) then the code goes down a slightly different path and doesn't set the status code for that message correctly. Which I've just fixed in the developement build.

It remains to be seen whether this is the only cause of the problem or there are other things causing the same problem.

In a semi-related note I'm moving the socket implementation in Lgi to non-blocking (at least on Linux) to work around other API problems. When you close a socket in Linux that is blocking in another thread the blocking function doesn't return. Whereas under Windows it does, with an error code. Which is really handy, you can fire off a thread to handle the connection and if for any reason you want to cancel out of that thread from your main GUI thread you just close the socket and everything will just error out. However all that doesn't work on Linux as I've found out. That in itself required moving to a non-blocking architecture. However I've noticed on Windows that occasionally the socket stalls in an infinite loop inside a 'connect' or 'recv' and never times out. Which is bad behaviour anyway. So a proper non-blocking implementation can easily do timeouts as well. There might be a way to set a timeout for a Windows socket using some Win32 API call which I could investigate when I care enough to do something about it.

So in the next few days I'll do some more testing and release this bug fix for the world to play with. Then I've really only got the "100% CPU" bug to track down so that I can get back to general development.
(0) Comments | Add Comment