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).

PostgreSQL supports the SQL-standard WITH RECURSIVE clause instead of the Oracle-specific CONNECT BY.

CONNECT BY is in many ways a nicer syntax, but the functionality is there.

Pg also has XML types, schemas and extensions to serve some of the same purposes as packages, etc. Default values of function params are also supported.

That's not to say it has full coverage of Oracle's feature set; it doesn't. There's no native materialized view support until 9.3, so you have to roll your own in currently released versions. There's no synchronous multi-master clustering in Pg (we're working on it). No autonomous transactions, and stored procs can't easily return multiple result sets. Partitioning in Pg is rudimentary and manual, at least in 9.3 and older, it might change in future.

OTOH, Pg is more extensible, has saner licensing, offers choice of support, etc, per my other post.

Yeah! And while we're at it we can use Java EE 6, which makes it super-easy to write apps that'll run on any of the portable Java application server runtimes!

People who think SQL is really a meangful standard haven't used more than one SQL RDBMS. Even basic read-only querying and DML is in practice only marginally standard. For example, Oracle doesn't support multiple VALUES lists, it has its own funky syntax for multi-valued insert, which is one of the more basic things around.

2ndQuadrant, who I work for, have some PL/SQL conversion and compatibility tools in the works and are interested in hearing from more people with large PL/SQL codebases.

Like most DB comparisons, it depends on the workload, non-technical business factors, and more.

Oracle has superior clustering to PostgreSQL, better native XML support, autonomous transactions, procedures that can return multiple result sets, a really solid embedded JVM for procedures, proven scaling to absurdly huge database sizes, etc.

PostgreSQL has transactional DDL, generally better standards adherence, no lock-in, streaming replias that don't cost you anything, multi-language stored procedure support, extreme extensibility, proven scaling to multi-terabyte database sizes, and probably more I take for granted and forget about.

With Pg you get a lot of choice of support provider, including "none, I can do it myself and I can always contract someone if I need help". With Oracle you get support from Oracle, or from a vendor who must comply with what Oracle wants in order to get access to the resources they depend on to offer support.

PostgreSQL has no per-cpu or per-core license fees so you can run it on a lot more hardware. You can also afford to buy a much bigger server for the money you're saving on licensing fees and upgrade it more often. This can make a huge difference; PostgreSQL's performance is generally very good, and in areas where it does fall behind Oracle you can make up for a lot by throwing bigger hardware at the job. You also don't have to face NDAs, license audits, not being able to afford to have a second off-site hot standby backup machine, being stuck on old versions because licensing new ones is just too expensive, etc.

So, really, a huge amount of it depends on the workload, business requirements, etc.

I work professionally with PostgreSQL as a member of the 2ndQuadrant team, but if I'm discussing planning with somebody I'm still quite prepared to say "I don't think PostgreSQL will do the job as well as [blah] here given the time frame and requirements". It doesn't come up much but it has, and I'd be doing them a dis-service by saying PostgreSQL's perfect for everything all the time.

I find PostgreSQL to be the safe and sensible default, but I consider alternatives or supplements to it when I run into workloads it's not ready for or not great at - like someone who has a hard business or compliance requirement for synchronous multi-master clustering, or somebody whose query pattern and data set is going to be a better fit for Greenplum than native PostgreSQL.

While DIY data recovery has its risks, most "damaged" disks really just have minor filesystem corruption.

The wonderful (free) photorec tool from the photorec package can be used to do an amazing amount of recovery. I've never had it fail on SD cards with FAT32 damage. It can also recover all sorts of other document formats, despite the name, and works fine on hard drives - though you should *ALWAYS* disk image the drive and then attempt recovery on the image.

For imaging, look into ddrescue, it's a vital first-stage recovery tool.