Grumpy?

Posted Jul 10, 2004 16:59 UTC (Sat) by yodermk (subscriber, #3803) [Link]

What I would also like to see is a "grumpy editor's" comparison of database front ends. Ease of designing forms and reports and scripting events should be considered. That one would likely be a bear to write though.

My organization was looking at replacing Access with an open source tool, but the consensus was that there isn't a suitable alternative at this time. :( Would love to be proven wrong on that!

It would need to work on 'Doze for now, which would seem to eliminate Knoda and Kexi and Rekall, and OOo is just a tad bit klutzy...

Posted Jul 11, 2004 18:50 UTC (Sun) by james (subscriber, #1325) [Link]

Would it help to post a paying-subscribers-only "article" mentioning that you are planning a Grumpy Editor's guide to (say) databases, and asking for subscribers' comments?

That could help you find all the possible projects (Grumpy Editor articles are particularly valuable when they review low-profile projects that could do with more publicity), and give you a series of features that LWN users like (or have noticed are often absent).

James

Posted Jul 16, 2004 20:20 UTC (Fri) by ringerc (guest, #3071) [Link]

I find it difficult to imagine a topic more fraught with pitfalls, due to
the impressive complexity of the subject matter and the wide range of
users needs. It's also the only topic I can think of that's likely to
result in MORE fuss than a KDE/GNOME article.

Such an article would need to extremely clearly set out the evaluation
criteria, user experience, and user needs before beginning. Comparing
feature lists is IMHO almost useless without knowing what those features
will do for you. Even constructing feature tables is almost impossible to
do in a way that is both comprehensive and vaguely comprehensible (ie not
a 5000 entry table) because what to one person is irrelevent is to another
person the straw that breaks the camel's back.

Also, lots of the things people say about databases are quite subjective.
For example, one frequently hears MySQL being described as incredibly
fast... but that depends to a huge extent on your workload. It's very fast
for many SELECTS on tables that don't see much write activity, but pays
for that in write performance, especially for concurrent clients. At
least, that's my impression. Therein lying the root of the problem - good,
meaningful benchmarks (especially up-to-date ones) are hard to come by.

Meh. It'd still be a really interesting article, it suspect it'd just be a
huge job to do well.