Reviews and Ratings
After writing hand-crafted command line option parsers, then switching to getopt(), then popt, and sometimes libconfuse I have a sack full of dissatisfaction and nearly an aversion to writing easy-to-use command line tools.
However, GNU gengetopt changed all that:
- it's easy to use with a powerful grammar that covers nearly all use cases
- it's portable because it's just a code generator and the C code produced is highly portable
- it doesn't clutter your binaries with disgusting dependencies in your binaries (ever needed a static libpopt because you love static linking?)
- it's maintained and it's GNU so I guess it will be around for at least a little while
Beside all the praise I want to utter some criticism as well: I found myself doing ugly hacks to incorporate a licence string upon --version, and custom multi-line usage strings are not really well supported either. But that might change in the future, Lorenzo Bettini, the current maintainer, is open for discussions and contributions.
Summary:
It's an unfinished, pre-mature, hardly documented beast that doesn't do at all what was promised
I must say the specs sound promising and overall, in times where it's common to administer a small LAN of at least 3 or more boxes, the networking capability comes in handy. The *IDEA* is good.
Having said that, the implementation looks like the homework of a cs undergraduate gone wrong. What they call stable and mature, I'd call (at a push) a first prototype. There's hardly anything that works as *described* (if you're so lucky as to find a description without reading the source code). It starts with random crashes (I reported it, they blamed it on my compiler, yeah right, as if!), over to ridiculous default settings (who wants their sound turned off after the server consumed 60 CPU-minutes?!?!) and is topped off by unreportable bugs, like a hissing and crackling noise in glitch free mode, sure they claim it's unreproducible; but then again I wonder if they're not deaf and blind after all. I should have filmed my dog's scared face, howling and hiding as proof that *something* is wrong with the audio produced.
Great experiment, alas a total fail.
As a long-standing e16 user I must say I'm not quite ready to switch. I love the `keyboardability' of e16, and e17 has let me down a lot in that regard.
None of the actions can be bound to my `window manager keys', Hyper and Super, and seeing as that literally everything(!) else is taken for something else in my setup already, it's very hard to get the `e16 feeling'. Shame, because it looks so good :(
S
Quite slow even for tiny collections (~10000 documents, ~1KB each). Also, half the functionality is missing due to:
Exception in thread "AWT-EventQueue-0" java.lang.ArrayIndexOutOfBoundsException: -1
(in particular: sorting by Title, adding more columns in the main window) The autotagging feature needs some polishing, out of 10000 documents it was able to autotag 1, and I had to remove the tags again because they were meaningless: "analyt copyright".
After seeing so many big distros switching to this *experiment* I'm getting scared.
Tonnes of bug reports, many unnoticed, most of them unfixed. This is not entirely upstream's fault, I know, but something so under-documented and unmaintainable as systemd cries for mis-configuration and mis-use.
Stuff that Just Worked[tm] before suddenly becomes a matter of I-have-to-keep-an-eye-on-that. Taking on tasks that are best left to expert systems (like why exactly is timedated part of systemd now?) is rarely a good idea. Pair that with sheer incompetence (I'm in no way calling ntp.org competent but at least they have an idea about the complexity of time keeping) and you will see how systemd is a failed experiment.
Sure, I can file bug reports for all the little nuisances, and I'm doing so, but it's a time consuming job that is especially hindered when you realised that you have twice the knowledge about this particular subject than the guy the bug report was assigned to.
Ok, I can also just not file a bug report if I get that impression and send patches to the upstream project directly but how with a code base like this? Is this a secret game of spot-the-comments or if-you-can't-figure-out-how-this-works-you-suck.
Anyway back to my original rant, systemd is obviously designed to create problems where there have been no problems before. A big example of NIH syndrome, not even upstart caused so much trouble after a short test run.
It is unfortunate that, as a *user* and risk manager for my company, I have to wave goodbye to opensuse and recommend debian for new installations. On the other hand, as a coder and script kiddie, I welcome this new playground. LOOOOADS of work to be done and hence a GREAT chance of getting commits in :)