Subject Re: [Firebird-Architect] Future feature priorities
Author Jason Dodson
t_j_haynes wrote:
> Hello,
> Now, I really like Firebird and I want it to do well, but at the
> moment I feel it is losing out for a number of fairly obvious
> reasons. So here is my quick two pennies worth of where I see the
> problem. I know it's just my view from the point of view of an end
> user, but I wonder what the general feeling is?
> Firebird's biggest problem today is the lack of a viable Windows
> server. In the real world everyone runs multiple CPU servers, even
> more so with hyperthreading and dual-core chips.

I do not. My firebird server is a Pentium II 400 with 384MB of memory.
My ftp server is a sparcstation 5. There is nothing multiproc on my
network... rarely do things actually "need" anything this high end.
Management tends to like to throw more money at a huge new machine,
because inevitably, you'll get a small percentage of performance
increase... but rarely have I found, will it do better than good design.

> Unfortunately the
> Superserver doesn't handle multiple CPUs and the Classic server is
> apparently not properly tested on Windows. This rules Firebird out
> of most 'real' use on Windows.

I don't know about you, but up until about 6 months ago, our firebird
ran for a few years without issue on a p75 64MB windows 95 machine.

> A multithreaded multi-CPU server
> would be the ideal answer, but this isn't scheduled until V3.0
> (Vulcan). A reliable Classic server today would at least allow those
> thinking about adopting Firebird to make a start.

I am not sure where you find things "unreliable". If 23789217329739281
people can get it to work, but a handful of people can't, logic dictates
that the handful are probably doing something wrong... or have some
peculiarity about their setup that is failed to be aknowledged.

> Next most urgent issue is the safety of information. A good backup
> (including incremental) is critical, and I gather that this is being
> addressed for version 2.0. Another not uncommon requirement is for
> simple whole-database replication, but sadly Firebird's shadow
> databases sadly fall just short of being a truly brilliant
> distinguishing feature and trigger based replication mechanisms are
> comparatively lousy.

I guess gbak is too hard to use.

Reading is hard too...

> Third is the lack of documentation. This is largely addressed by
> buying the book, but the online stuff is a mess - a mix of current
> and old Interbase stuff. It really needs to be current and Firebird
> branded.

While I agree, it is an open source project. If you want some
documentation, contribute some. Else, swallow your tongue.

> Last, but not least is the lack of a standard graphical
> administrative interface. This doesn't worry me, but some of these
> youngsters today can only function in a point-and-click world. A
> problem is that there are several GUI tools available, causing
> confusion among users who just want to install the standard package
> and have it just work 'out of the box'.

You know, most of the Sys admins in the world DO NOT use Windows. Even

That looks like a configuration GUI to me... or do YOU MEAN an client
admin package like "Enterprise Manager" that comes with SQL Server? You
get that because you are rediculous enough to pay $1000+ on the low end
for "Enterprise Software".

Want there to be a free one? Pony up some money. Ill write one for
you... you just have to pay for my time. Don't like those options? Make
it yourself.

> I know that most of this stuff is in the schedule, but it all seems
> so far away and a load of (relatively) trivial 'features' seem to be
> coming first. With a working Classic server and an incremental
> backup I could hold the PostgreSQL supporters at bay, but defending
> Firebird is quite tough right now. Help!

It doesn't seem Firebird is for you. Move on.