[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: akka/38: Akka autotools fixes (security, speed, beauty)
- To: developer at arabeyes dot org
- Subject: Re: akka/38: Akka autotools fixes (security, speed, beauty)
- From: "Phactorial -" <phact0rial at hotmail dot com>
- Date: Mon, 10 Jun 2002 20:24:46 +0000
First and foremost, I must state my apologies regarding my lack of CVS
updates. School will come to an end tomorrow, and then I am free to find a
decent internet connection for my development box.
- Ok. Remember, this is a really bad way to check if loadkeys actually
worked. I am not sure if you said "Yes, that's fine" to my execve(); (where
we can check loadkey's return value directly, much more accurate. Any sort
of error checking on system() is no error checking at all) or installation
idea. For tomorrow's CVS though, I will return that perror for you.
- How about we include the maps needed (by default configuration) by Akka
into the Akka package itself. It will surely make that poor excuse for
"default configuration" much more portable. I was thinking of writing an
autoconf tool, but it is needless if we just include the fonts/keymaps we
will be using.
Samy Al Bahra
From: Mohammed Elzubeir <elzubeir at arabeyes dot org>
Reply-To: developer at arabeyes dot org
To: developer at arabeyes dot org
Subject: Re: akka/38: Akka autotools fixes (security, speed, beauty)
Date: Mon, 10 Jun 2002 09:28:32 -0500
Received: from hotmail.com ([184.108.40.206]) by hotmail.com with Microsoft
SMTPSVC(5.0.2195.4905); Mon, 10 Jun 2002 07:32:11 -0700
Received: from arabeyes.org ([220.127.116.11]) by hotmail.com with Microsoft
SMTPSVC(5.0.2195.4905); Mon, 10 Jun 2002 07:30:51 -0700
Received: from pc92680.cascss.unt.edu (list at localhost [127.0.0.1])by
arabeyes.org (8.12.1/8.12.1/Debian -5) with ESMTP id g5AETJD8028237;Mon, 10
Jun 2002 09:29:20 -0500
Received: from arabeyes.org (elzubeir at localhost [127.0.0.1])by arabeyes.org
(8.12.1/8.12.1/Debian -5) with ESMTP id g5AESXD8028206for
<developer at arabeyes dot org>; Mon, 10 Jun 2002 09:28:33 -0500
Received: (from elzubeir at localhost)by arabeyes.org (8.12.1/8.12.1/Debian
-5) id g5AESWaY028202for developer at arabeyes dot org; Mon, 10 Jun 2002 09:28:32
Message-ID: <20020610142832 dot GC28079 at arabeyes dot org>
References: <F65UYfrfxhsaVHLUmcJ00001673 at hotmail dot com>
<3D048C58 dot 68C43253 at chaham dot com>
In-Reply-To: <3D048C58 dot 68C43253 at chaham dot com>
Sender: developer-admin at arabeyes dot org
Errors-To: developer-admin at arabeyes dot org
X-BeenThere: developer at arabeyes dot org
List-Help: <mailto:developer-request at arabeyes dot org?subject=help>
List-Post: <mailto:developer at arabeyes dot org>
<http://arabeyes.org/mailman/listinfo/developer>,<mailto:developer-request at arabeyes dot org?subject=subscribe>
List-Id: Development Discussions <developer.arabeyes.org>
<http://arabeyes.org/mailman/listinfo/developer>,<mailto:developer-request at arabeyes dot org?subject=unsubscribe>
Return-Path: developer-admin at arabeyes dot org
X-OriginalArrivalTime: 10 Jun 2002 14:30:53.0932 (UTC)
On Mon, Jun 10, 2002 at 01:24:09PM +0200, Chahine M. Hamila wrote:
> Salaam Samy,
> (I'm CCing Moe so he can maintain the bug tracking system with whatever
> thinks is suitable:))
And I'm moving this discussion to the 'developer' list.
> Phactorial - a *crit :
> > The UNIX world has to be a reliable world. It is better to give that
> > of retrying that pthread as systems with high loads might have that
> > If you have any problems with the changes, I am always to happy to
> > them.
> Samy, if there's an error, and you want to avoid load driven errors then
> something that will detect high loads and respond accordingly. Retrying
> checking for the exact reason the first failure occured is a bad thing,
> at best fail again. At worst, it will work, and we're likely to have
> somewhere or some buffer overflow... When it comes to software behavior,
> must be square, ot we're likely to be facing a serious bug.
> > The ioctl commenting is all what really needs commenting (other than
> > algorithms, which are actually not too difficult to understand). Some
> > potential porters might not be well versed in Linux's system
> > or FreeBSD's, etc... It is better to do this, and it doesn't waste too
> > time :D
> You're most welcome to do that if you've got motivation for it.
> > You have the Microsoft term of software:
> > - If it works for me, it works for everybodys
> > - It must work (not the best way)
> It must work, sure, but make it work the right way, no approximative
> > - We must do everything the easy way
> > My terms:
> > - It must be efficient and stable, I have completely removed glib
> > dependency (it is only left as a fribidi dependency now, which is
> > better, as it reduces our future work of removing this dependency
> > when prior versions of fribidi die out)
> ok, that's fine with me.
> > - You don't what fuzz, use what you need. Using more libraries makes
> > your program much less portable, much less efficient (not as
> > we don't want yet another layer on top of system call execution)
> Using more libs do not reduce the portability unless you're using an
> non portable lib. It certainly does not add a layer in any case, unless
> soft needs another layer, but very much the opposite. A library is a
> of pieces of code that you would otherwise write in your software, but
> teaching you anything here, am I. The only cost is at load time, and
> unsignificant. The alternative is to replicate code on the system, and
> costs time and space.
I tend to agree with Samy here. I'm all for reducing library dependencies..
is, Akka has far too many dependencies for what it does. That's just my
it. I would be very much in favor of a 'light-weight' akka.
> > - Source code must be readily reabable by the programmer, no need
> > doc++, if you wish, I can return to that ugly mung :)
> Yes, please leave doc++, not everyone is as good as you are reading
> newbies might find it useful to have a documentation besides the code.
> said before, ugly is really in the eyes of the beholder, I personally
> doc++ style quite breathable compared to the asphyxiated ANSI style, but
> really not for aesthetic reasons that I think doc++ style comments
The 'programmer' also reads the doc++ output. Thought I would note that the
commenting is incomplete and inconsistent still. I would suggest adding the
comments, but maintainng the doc++ style (which I personally like) - it's
readable when viewing src, and very nice to output documentation later.
> > - I only stuck with light ANSI things, if it involved putting back
> > the features we use, then I wouldn't have implemented these things
> > - In that system() call, I replaced perror because system does NOT
> > set errno. System is simply a wrapper to execve, the only time it
> > would errno if /bin/sh (or whatever the configured shell is) is
> > existant or has other problems (permissions, etc...).
> True, but that's precisely the kind of problems you encounter most of
> At least, these are the ones I needed when testing Akka. If you really
> strong about that, you can put both, it doesn't cost anything, and it'll
> probably be better, coz I still think it's important to leave the
Agree with Chahine here.
> > We wouldn't
> > know the return value of loadkeys this way. How about I replace
> > system with a fork();execve() and check the return value of the
> > child instead? I'll make it print the value in LOADKEYS instead.
> > Do you want me to write a configuration wrapper (to autodetect the
> > configuration files, the default configuration file is not very
> > portable at all)?
> Yes, that seems fine.
> > - I did not touch that in the main loop, as it was off the autotools
> > cvs. Maybe you should check that? Someone could've have screwed
> > with it...
> I was reading it from the patch you provided. It's during the printing
> error message, where /dev/tty%d used to send ttyn instead of consolen.
> case, we agree so no need to discuss it for years:)
> > - pthread, hrm, you must have error checking here, otherwise, we
> > be interfacing with an unexistant thread
> > - I checked the inline, it is valid
> > - Please refrain from sharing signals too much. That is probably the
> > reason for that console corruption you were talking about. I will
> > be adding a wrapper on top of terminate sig that filters/resets
> > signal handlers before jumping to terminate_sig itself.
> Yes, that's one of the things on the todo as put in the code. It would
> very good thing if you clean that indeed.
| Mohammed Elzubeir | Visit us at: |
| | http://www.arabeyes.org/ |
| Arabeyes Project | Homepage: |
| Unix the 'right' way | http://fakkir.net/~elzubeir/|
Developer mailing list
Developer at arabeyes dot org
MSN Photos is the easiest way to share and print your photos: