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.

Does it actually *work* properly though?

Samba 3 had network printer driver support. Theoretically. In practice it was a buggy PITA that took 10x as much work to get to the point where it worked 1/2 as well as the Windows setup.

Overall, no, it isn't even close. Samba 4 may offer the core features of AD its self, but it doesn't offer all the powerful management and Group Policy tools, system deployment facilities, etc. Some of it could probably be hacked in on top, but IMO, it's really not worth it.

I was running a Samba3 domain on an LDAP directory for years. It was OK, but always had annoying warts and problems, plus it was a pain to run. Automatic printer drive deployment was fiddly and never that reliable. Group Policy wasn't even an option.

Eventually I gave in and moved over to win2k8. As a heavy Linux user and long-time *nix sysadmin, I have to say, for running Windows networks I am NEVER going to use anything else. Sure it has its issues, but it's reliable and it has an amazing array of system management tools.

The Microsoft Deployment Toolkit alone is worth running a Win2k8 box for : just PXE boot your clients and have them auto-re-install themselves, install software and printers, change settings, add local users, install updates, and reboot almost ready to use. You can do this with a USB key and a manually copied Windows PE image, but it's fiddly and annoying.

Then there's Group Policy. Group Policy actually makes me want to use Windows. It makes me want to get rid of my Linux thin clients - despite their reliability - because with Group Policy I can just push changes out to all machines (or defined subsets) with a few simple changes in a central directory. It's seriously impressive.

About the only irritation is that so many software packages use custom installers rather than the Microsoft Installer (MSI), so it's not always easy to roll them out via Group Policy server push. Some of those that do (I'm looking at you, Adobe) don't make it easy to just download their updates whenever they come out and push them via Group Policy; you have to go and check for updates by hand. Fail.

Despite the irritations, there's just nothing like it for booting a client off the network and having it come up ready to use. Redirect the user's desktop and documents folder and you don't even need to worry about the machine breaking or having client backups; you back up the redirected folders, and if the machine breaks you just re-image it because it has no local data of any importance on it.

The sad fact is that tools like this are no fun to work on, so they're not something we're going to be seeing in Linux/BSD land in a hurry.

Nope, turns out it's a magnetic strip system not a smartcard system, so it isn't SmartRider.

Correction. After reading the presentation, it's clear that this is not a smartcard system, it's a magentic strip system. That means it isn't Western Australia's SmartRider, and WA's old MultiRider magnetic strip system has been retired for 5 years so it's not going to be MultiRider.