Weekly Edition
Return to the Development page
| |||||||||||||
Buddi - Personal finance software for the rest of us
Buddi is a cross-platform
financial program that was written by Wyatt Olson. The project news
shows the first beta release came out in May, 2006.
![[Buddi]](/images/ns/buddi.png)
Buddi is a personal finance and budgeting program, aimed at those who have little or no financial background. In making this software, I have attempted to make things as simple as possible, while still retaining enough functions to satisfy most home users.
Buddi is released as Open Source Software.
Buddi will run on almost any computer which has a Java virtual machine installed. This can include Windows, Macintosh OS X, Linux, and many other operating systems.
Buddi is currently available in Dutch, English, French, German, Greek, Italian, Norwegian, Portuguese, Russian, and Spanish.
The feature list for Buddi includes:
See the online screenshots for a look at the software in action. More information on Buddi is available from the FAQ document. Buddi installation was trivial on an Ubuntu 7.04 system using the provided .deb package. Sun's Java Virtual Machine (at version 1.5 or higher) was a required dependency. Running the code the first time brought up a series of first-run screens, then the main control panel. There were some indications that the software is still a little young. The help menu pulldown just listed the Ctrl+Shift+H command that had to be typed in manually to get the appropriate browser screen to display. Adding information to the transaction windows was a bit rough at first, several of the form's fields had no title and attempts to enter data were initially rejected with somewhat cryptic messages. Referring to the online tutorial document cleared up most of the confusion. Once some data was entered, creating reports and graphs became fairly intuitive. Stable version 2.6 of Buddi was recently announced: "This includes numerous minor UI enhancements, which should make life a little easier for everyone. Note that the API has been upgraded to 2.6; this means that the old plugins will not work for you anymore. I have released all stable plugins in the Buddi Plugins repository for 2.6 format". Financial software is often cited as an application space that is lacking for Linux, Buddi should help to fill that vacancy. The software is already useful enough for basic finance tracking, hopefully as the code matures, it will become a bit easier to use. Buddi downloads are available in .jar format for all platforms, and as packages for Debian/Ubuntu systems. Give it a try. (Log in to post comments)
Kiss of Death Posted Aug 16, 2007 4:03 UTC (Thu) by ncm (subscriber, #165) [Link] It's unfortunate that the program depends on a JVM. That makes it more brittle, and harder for people to try out. A build using Gcj, instead, might help. Porting to a less demanding language would help more.
On Debian the pdftk package is built with Gcj. It's the only Java program on my machine.
Kiss of Death Posted Aug 16, 2007 13:19 UTC (Thu) by Frej (subscriber, #4165) [Link] What's the issue? (Considering that an open Jvm is on the horizon)I don't get why it has to compiled?
Perl,python and mono does the same - just another VM?
Kiss of Death Posted Aug 16, 2007 16:35 UTC (Thu) by vmole (guest, #111) [Link] Strictly speaking, the Perl and Python interpreters aren't VMs. But I'd guess that the real issue is that many of us had bad experiences with Java apps (big, slow, ugly, crashes) in the past, and are disinclined to try again, no matter how much the Java infrastructure may have improved recently.
Kiss of Death Posted Aug 16, 2007 21:15 UTC (Thu) by ms (subscriber, #41272) [Link] The atmosphere of this planet was once toxic to modern day humans. Thus I really feel it's unwise to ever try breathing.
Kiss of Death Posted Aug 16, 2007 16:45 UTC (Thu) by Los__D (guest, #15263) [Link] More brittle? In which way? I don't see any reason that it should be less robust from using Java. Just a little bit slower and bigger. Hardly matters for a desktop application.
Harder to try out? If anything, it's easier.
What less demanding language? Only language that is a bit less demanding is C#, but then this thread would be 10 times longer with people bitching about the programmer's language choice, instead of thanking him/her for an apparently good piece of software.
Kiss of Death Posted Aug 16, 2007 18:48 UTC (Thu) by ncm (subscriber, #165) [Link] C is less demanding: it only depends on libc. C++ is less demanding; it depends on libc and libstdc++.
There's are good reasons why so few successful user-level programs are in Java.
Kiss of Death Posted Aug 16, 2007 23:33 UTC (Thu) by dw (subscriber, #12017) [Link] Demanding by your standard here seems to be a measure of OS integration or ease of packaging. After using OS X for a year I can happily report that there were certain apps I didn't even realize were written in Java.
OS X also has single-click access to jar files, with very little noticeable startup performance hit.
This makes me think your problem is with contemporary Linux rather than Java. :)
Kiss of Death Posted Aug 17, 2007 5:56 UTC (Fri) by jordanb (guest, #45668) [Link] > OS X also has single-click access to jar files, with very little noticeable > startup performance hit.
Because after OSX bounces a few icons, twists a few windows, and spins a couple widgets, you're not going to notice a 'lil ole thing like a JVM starting up.
Kiss of Death Posted Aug 17, 2007 10:02 UTC (Fri) by dw (subscriber, #12017) [Link] I'm not sure it's just that. Compare and contrast to Mono startup on Linux which in my anecdotal experience is much faster than JVM startup on Linux. Maybe the OS X folk sat down and figured out why the disk clicks so much and the CPU burns so brightly? Seems the Mono folk have done something like that.
Kiss of Death Posted Aug 21, 2007 12:48 UTC (Tue) by massimiliano (subscriber, #3048) [Link] From a Mono JIT developer.. thanks for the appreciating our work :-) But in this case, to be really fair, it's not just that we took care to tune the startup, the main factor is that the .NET "class" file format (the files we call assemblies) is much better thought out than the jar (and .class) file formats. Even the .NET bytecode is easier to JIT than the Java equivalent! IMHO, Microsoft learned from Java's technical mistakes, and improved the situation a lot. Not that I blame the Java designers (they did it more than one decade ago), but .NET is really an improvement on many fronts.
Buddi - Personal finance software for the rest of us Posted Aug 16, 2007 9:13 UTC (Thu) by kolloid (guest, #25282) [Link] In my opinion, Java for Desktop programs is utter stupidity. Java desktop applications require ages to start, GUI is slow and unresponsive even on newest multicore CPUs with lots of memory.
Maybe Java is good for server applications, but I hate Java desktop applications. They turn your superfast PC with two processors and several gigs of RAM in an old IBM PC XT. :(
Why not write it in Python, for example? Not only it would be easier to develop, it also won't require JVM and other Java dependencies and will definitely run much faster.
Buddi - Personal finance software for the rest of us Posted Aug 16, 2007 14:33 UTC (Thu) by timschmidt (guest, #38269) [Link] Nope. Not any better on the server either. Zimbra, for instance, consumes a massive 800Mb of ram in a single java process here. Scalix behaves similarly. Similarly-featured non-java mail servers (eg. Bongo) feel spritely in comparison using 64Mb ram.
When will the FUD stop ... Posted Aug 17, 2007 15:28 UTC (Fri) by gouyou (guest, #30290) [Link] Complaining that their is no GPLd version of Java, I can understand it...
But complaining about performance, that's 100% bullshit! Especially if you start comparing it with python (and I love Python):
The main reason for choosing a language are not if a user will bitch about it, but if you are confortable with it, and it fits your requirements.
So if you are not happy about it, take the source code and port it to Python, make sure it's running on the three current major operating system, compare the performance and then come back.
Anyway ... I should stop feeding the trolls and start hoping that LWN will get back to intelligent discussion, based on some facts ...
When will the FUD stop ... Posted Aug 17, 2007 15:39 UTC (Fri) by gouyou (guest, #30290) [Link] And BTW, try to get your superfast PC with two processors and your python program to use more than one processor with multiple threads ...
|
|||||||||||||