Agreed. You can produce good docs without the solid co-operation of the dev team, but it's much more difficult, more time consuming, and a lot more frustrating. They also tend to bit-rot a lot faster.

I love the way that people who don't contribute themselves describe those who do as "lazy" and demand that they make "excuses" for not doing what they're doing well enough to meet the standards of random other people.

This attitude actually makes the problem worse. "Screw you, why should I bother documenting something I wrote for me when some asshole's going to come along and tell me it's not good enough for them anyway? What'd they ever do? I'll just make it work for me."

Your point is somewhat accurate, if poorly made.

You neglect important externalities though. Often the devs are competent, but working to unrealistic deadlines and with priorities that specify that the product must work - not be pretty or properly documented.

You'll find this attitude in many fast-moving industries with little regulatory oversight.

Heavier regulation tends to force better processes, better documentation, higher standards for QA, etc ... and greatly increase the cost and time taken for everything.

It's a trade-off. You would clearly prefer the trade-off to be more toward a process-based, managed system than it currently is. Are you also willing to pay 3x as much for software? To greatly reduce what's available or possible for people to build for free, or make it entirely impossible?

I share your frustration, but unlike you I don't think the answers are simple, or that the explanation is that people other than you (obviously) are stupid.

Did you report a bug about it?

Sometimes the folks working on the tool just don't spot these issues and need to be poked. I know it's true for me anyway.

I find it incredibly valuable to talk to people who don't already know the system/problem/etc well. They often see what I can't because I'm already too immersed in it. When they don't, they're still useful because they force me to fully explain the problem and in the process often identify an error in my reasoning.

I often write explanations to this imaginary new user now, when I'm trying to figure something out. Or I tell it to my partner - I work from home so there's nobody else. If she's not interested, well, the baby has no choice but to listen ;-)

I'm glad to see you say that.

There's still plenty to improve in the Pg docs, and we welcome patches from everyone.

I concur - I used to use the Solaris docs heavily for Linux sysadmin, as their coverage of the POSIX-y bits was generally excellent.

Before Oracle.

Unfortunately, part of the reason Solaris's docs had to be so good was because the tools were often so bad. Any OS where the first thing you do is "overlay a GNU userspace" has a problem.

I'm not at all convinced by that. I think it'd just be even more fragmented, confusing and bitrotted than what we already have, unless it was very carefully designed to tag passages as relevant to particular versions/distros, etc.

It's not easy to get this right.

A big first step would IMO be to lock all distro devs in a single room and declare that the last one standing gets to live. Or, at minimum, do this for package formats. We need rpm OR deb. One of them has to die.

When I find a problem, I fix it where possible, and at least bring it to the attention of relevant people where I can't.

If people actually did this, instead of complain that "the docs suck" and expecting someone *else* to do the work to fix the issue, the docs wouldn't suck.

If whatever it is uses some particularly arcane and awful docs build system I'll often just send in textual changes. If it uses something sane, or something insane that I already know (docbook for example) I'll send a patch.

This is a case of JFDI.

That's an accurate and sensible response.

In fact, 3rd party client encryption tools might be better than built-in support by Dropbox. They can be produced outside the USA by companies or individuals unaffiliated with DropBox and potentially harder to pressure into backdooring the software in an update.

I'll stick to SpiderOak personally, despite the awful transfer speeds and somewhat clunky usability, because I just want a remote store that stores my gibberish bytes and gives me the same gibberish bytes back later.

Anyone developing software needs a clue about names, and about unicode and text encodings.

http://www.kalzumeus.com/2010/...

http://www.joelonsoftware.com/...

(Then learn lots, lots more about text encodings).

Also, whether or not they use SQL directly, about metacharacter attacks and SQL injection:

http://bobby-tables.com/

http://watchguard.com/infocent...

It's probably been so long since they released it because GCHQ had to vet the video to make sure you couldn't reconstruct the document from the fragments visible during the video.

They seem to be about that level of tech-literate.

Not every community is like that, thankfully. Many have standards of behaviour and take people to task when they step outside them.

The PostgreSQL team make an effort to keep discourse polite and constructive. It's generally very effective. I see such standards as valuable ways to force people to make their points with technical argument and reason, not YELLING A LOT.

Actually PostgreSQL's XML type is a thin wrapper around "text", not a compact binary representation. It does get TOAST compressed which might've what made you think so.

I work professionally with PostgreSQL and I totally agree - PostgreSQL or any RDBMS isn't the right choice for all jobs.

If the only way you can make it work is to build an inner-system or use EAV for everything, you shouldn't be using an RDBMS.

If you have a free-form data model that's not amenible to structural analysis and normalization, you shouldn't be using an RDBMS.

Unfortunately, most people think they have one or both of those things, but in fact they just haven't done the proper analysis and thought through it, so they jump straight for NoSQLWhateverIsFashionableToday. They realise all the features and code they have to write themselves at the application layer, do it badly, say their chosen database performs badly or is unreliable, and go looking for a different one.

I'm glad to see that modern RDBMSs are starting to gain better support for non-relational structures (PostgreSQL's hstore, improving json support, etc). Few applications these days work solely with data that's suited to relational modelling. Apps often benefit from globally transactional behaviour though, and it's nice not having to wrestle 2PC and transaction co-ordinators and the other horrors you get when dealing with more than one DB in an product.

(Pg plays really well with Redis too, by the way; it's a great caching layer and PostgreSQL's LISTEN/NOTIFY lets you do fine-grained invalidation of your Redis cache).