[H-GEN] Is GnuCash ready for prime-time? Was: RFC: SCO

[ben.carlyle at invensys.com]

[ Humbug *General* list - semi-serious discussions about Humbug and     ]
[ Unix-related topics. Posts from non-subscribed addresses will vanish. ]

Hello,





Paul Gearon <pag at PISoftware.com>
Sent by: Majordomo <majordom at caliburn.humbug.org.au>
18/06/03 10:34
Please respond to general

 
        To:     general at lists.humbug.org.au
        cc: 
        Subject:        Re: [H-GEN] Is GnuCash ready for prime-time? Was: RFC: SCO


On Tue, 17 Jun 2003 ben.carlyle at invensys.com wrote:

> > The main thing, though is the fact that when it crashes it takes any
> > unsaved data with it. All the other problems make me want to 
contribute
> > to fix them, but that one is the one that makes me not want to use it 
at
> > all.

> If you really do like it (with the exception of these crashes) then I'd
> suggest you at least try and have a quick look.  Maybe it's something 
that
> the main developers aren't getting due to some different settings.

> So, assuming you're willing to put in the time, build it yourself with
> debugging on, and then run it.  As soon as it crashes attach gdb to it 
and
> find out where it is.  If you're lucky then it's not a big deal and you
> can fix it.  If not, then file a bug report.

The features of the program have left me with a good glow, and that makes 
me want to contribute. The lockups aren't a huge deterrant and leave me 
considering how I can examine them to prevent others having to deal with 
this kind of problem. The loss of data is a big red mark against this 
program.

Losing my data reduces my goodwill for gnucash, and I don't find myself 
wanting to support a project that doesn't have my goodwill :) I don't 
think it's useful to go looking for the lockups[1] when the real problem 
is that gnucash is losing my data[2]. What makes it worse is that the 
reason it's losing my data appears to be tied (at least partially) to the 
XML saved file format which doesn't allocate fixed field sizes for 
individual data elements and therefore requires the entire file to be 
written out at once instead of allowing updates to little sections as 
changes are made. If I were set to solve the problem then I would probably 
start by scrapping the XML saved file format in favour of little database 
files such as those provided by sqlite[3].

My gut feeling is that this would not be a change accepted by the existing 
developer and user community of gnucash, which sets my direction for the 
project agains that of those already involved. I wouldn't mind putting in 
the technical input. It sounds like a fun project. It's primarily the 
political input that I doubt I have the stomach for ;)

Benjamin
(I guess noone here is using gnucash, after all? :)

[1] I see a lockup as a minor glitch in software that's still in the 
earily in development. These glitches happen. I'm sure that my fixing 
those that currently exist won't stop new lockup problems occuring in the 
future.
[2] Losing my data due to conditions that are guaranteed to occur in 
software of this type and heritage is unacceptable to me. It's a problem 
that needs solving far more urgently than any current glitch.
[3] www.sqlite.org, a very good simple embedded public domain database 
engine


--
* This is list (humbug) general handled by majordomo at lists.humbug.org.au .
* Postings to this list are only accepted from subscribed addresses of
* lists 'general' or 'general-post'.  See http://www.humbug.org.au/