jvdongen

"I'm having a really hard time refraining from writing a really snarky "Switch to MySQL" type response, not because I think that MySQL outperforms PostgreSQL, but because there is always somebody on every MySQL article discussion who does this. Ok, that's off my chest, sorry to rant."

I can think of good reasons to switch from mysql to postgres though, and I've a hard time coming up with reasons to switch from postgres to mysql (which is something else all together than choosing mysql over postgres in the first place - although even there, for serious deployments, the only real reasons I can see are in the "it's what we know" department).

Long time Postgres user so I may be a little biased ;-), but still.

You are correct in that that appears to be the main point of the article. However, the analogy is unfair.

Airports are in relative short supply, so once you've taken the train, your stuck on it for quite a bit.

Migrating away from an ORM or using raw sql queries in addition to an ORM is possible at all times (with more or less work, depending on the ORM you've chosen). So you can start with the train and hop on the plane anytime you want or need.

You (and the article) would be correct if the ORM/no ORM was a black and white affair. However, as others already pointed out in this thread, it is not. It is perfectly viable to use an ORM as the basis and gradually switch to 'raw' sql if the need arises.

For most of my projects I use Django nowadays. Its ORM is usually sufficient. In cases where it is not I add a query method to a model class that just executes the most efficient sql query possible and returns the results in the most efficient format possible. For mature applications this can result in quite a lot of those query methods and the ORM than plays a lesser role.

However, even in those case the ORM continues to be a convenience to me as a developer, e.g. because it powers the Django admin interface and because together with South (a database schema migration tool) it makes schema management a breeze.

An ORM is a tool. And each tool has its own place and time. So, yes - there we go again ...

For my multi-lingual-content-needs I work with a main table which only has the non-translatable data items and a subtable which contains the translatable content, one row per language per row from the main table. Then I do a join to get a single full 'object' in the language of choice. And per the postgres docs I can choose collation at query time. Thus the following query would do the trick if I'm correct:

select * from main_table join sub_table on main_id=sub_id where sub_table.language='fr_FR' ORDER BY my_translatable_col COLLATE "fr_FR.utf8";

No bloating tables, just a join and correct collation.

... currently typing on a MBP with a clearly visible #, @, \ and | all reachable by merely using shift.

Is this only an issue with a US keyboard layout perhaps (I've a Dutch layout)?

How that exactly works is a bit too long a topic for a comment here (try google - "public key encryption", "X.509" and "certificate authority" are some relevant search terms if you're interested).

However what I'd like to point out is that 'simple eavesdropping' effectively is a Man-In-The-Middle attack, be it a passive one (the man in the middle is just keeping his mouth shut and only listening).

And eavesdropping on someones internet connection is, contrary to popular believe, not that simple.

The eavesdropper needs at least one of:

a) effectively have a (virtual) presence on either one of the endpoints of the connection b) unfettered access to exactly the correct pieces of equipment that are part of the internet's infrastructure. c) some way of persuading your traffic to take a de-tour from a remote location

Option a) is the easiest I guess - just drop a piece of malware on someones PC (takes care of that whole pesky SSL issue as well). Although certainly doable - I would not describe it as trivial. Most 'cyberattacks' targeted at the masses are not exactly efficient - their success largely depends on the large numbers of targets - targeting a specific person is quite a bit of work.

Option b) is, depending on who you are either relatively easy or nearly impossible. If it's easy for you, you've probably signed a piece of paper promising you a large bank account withdrawal and/or all kinds of 'benefits' in a state-sponsored facility if you abuse your powers. That won't stop everybody and there are parties for who it is actually their job to do this kind of things, but for the most part you can forget about option b) unless you happened to have attracted the interest of aforementioned parties. In which case I wish you good luck.

The feasibility of option c) depends even more on local circumstances of the victim than option a) but is a real possibility, but certainly not trivial. Something like dns-cache poisoning comes to mind.

So - eavesdropping is certainly possible, but I would by no means call it simple.

Rgds, Jeroen

If, as the article implies, the same user gets the same identifier across all KISSmetrics customers they ARE (implicitly) sharing customer activity between customers.

As the article states, customer A and B could simple put the information they each have about identity XYZ together. Without KISSmetrics having to be involved any further than in providing and maintaining the unique identity to each customer separately.

Even if it was not the intent of KISSmetrics for this to be possible (which I've a hard time believing), the chosen implementation makes it possible.

To some extend I agree - but if it wasn't for this benchmark AND the follow-up, my SSL cipher list would definitively not be the first (or second, or third) item I'd check in case of mysterious web server slowness ... Now it is.

I've learned something from this and thus find it useful.

Maybe because that's part of postgresql since 9.0 (async, sync replication coming with 9.1)?

You could use something like grinder (http://grinder.sourceforge.net/) to create a loadtest scenario which you can use to establish a baseline before a change and run after a change to assess impact.

True loadtesting requires quite a bit of thought to go into your test-setup, but for those kind of differential tests it is usually enough to make sure that your test-client and network connectivity to the application are constant factors and good enough to generate a decent load.

You won't catch the subtleties with those tests, but you will normally catch the 'oops, my perfomance dropped by 50%' type of errors. The subtleties you can then work out during normal operations.

The car/fuel analogy is a bad one. High-test fuel only makes sense if the engine in which you intend to burn it is designed to actually make use of its qualities to reach higher efficiencies (e.g. a higher compression ratio). If not, you're just burning more expensive fuel at the same efficiency.

That said, what really interests me is the mechanisms behind addictions. Why do smokers smoke, knowing full well by now that it will kill them earlier than non-smokers? Why stuff obese people themselves, knowing full well that it will cause serious health issues down the line.

Bottom-line I tend to agree with those who hold that 'a calorie is a calorie' and simply cutting down on food intake is a good enough principle, though perhaps not entirely scientifically correct, for the majority of obese people.

But why don't they do it? What makes it so attractive that they simply ignore the serious long-term disadvantages - and even in some cases deny the existence of said disadvantages even though in reality they must know they are real.

Implementing two factor auth on linux is actually fairly easy. We use a 15-odd line pam_script script that for ssh logins:

- checks to see if there is a authentication code in a hidden file in your homedir

- if not it validates the password you gave

- if that succeeds generate a 6 digit random number and stores a hash of the number in a hidden file in your homedir and sends it as an SMS to your mobile phone (phone number comes from ldap)

- rejects your login

- you login again, now using the pincode send to your mobile as a password

- the hidden file now exists and the pincode you entered is hashed and compared to the hash stored in the file before

- if they match, your allowed to login.

Simple to implement, fairly strong security wise, logical extension to password-only authentication, no additional account management overhead over standard ldap, reasonable user friendly and very cheap.

We use it also in combination with nomachines nx for remote desktop access.

[edit: formatting]

While it is a nice idea, I do not see any practical applications.

It requires a receiver who is a) knowledgeable enough to decrypt it using something like openssl and b) have access to the actual private key.

If that's the case it is highly likely that this person is either capable of using something like PGP or facilitate a file upload form on the apparently available website. Both of which are at least as secure and a whole lot more convenient.

Something related to this I would be really interested in would be a way to encrypt a file client-side, in the browser using javascript prior to uploading it (without the need for the user to do special tricks beyond picking a password). So far this only seems remotely possible using something like flash or silverlight.

Funny how the page containing the terms of service for ryanair is titled 'copywrite' :)

Also good to take into account is that Chernobyl and TMI and Fukushima are installations from the 1970's or early 1980's.

And even for those old birds the stats seem fairly favorable.

But as long as emotions fueled by scare-mongering have the upper hand, rationality and facts make no chance. So really widespread adoption of nuclear energy (be it fusion or fizzion - I'd be surprised if the public at large makes any distinction between them) is probably not going to happen for the near future. And that's a shame as it could be our ticket out of both a lot of environmental issues and socio-economic issues.

Except that storing the passwords in encrypted form in a keychain is explicitly meant to shield them from prying eyes even in the event the hardware falls in the wrong hands. You may get at the file, you just can't get at the data.

At least - that is what I as a user would want and expect. And from a technical point of view, that situation can be achieved with modern crypto. Clearly, the way Apple implemented it is not sufficient in this regard. That is the news.

[EDIT: never mind, missed this response, similar in style but 2h earlier ... http://news.ycombinator.com/item?id=2197064]

May be I'm missing something, but it seems to me that there is a way to have your cake and eat it too in this case.

Say we have a site with a page /contacts/ which lists various contacts.

On this page there are completely normal links like '/contacts/john/', each link preceded by/wrapped by an anchor tag - <a href="john"> in this case.

If you visit this site without javascript enabled (e.g. you happen to be a web crawler), you just follow the links and you get just regular pages as always.

If however you've javascript enabled, onclick events on each url intercept a click on a link and fetch just the information about the contact you clicked on (using an alternate url, for example /contacts/john.json), cancels the default action and (re)renders the page.

Then it does one of two things: - if pushState is supported it just updates the url - if pushState is not supported it adds '#john' to the url

If someone visits '/contacts/#john' with javascript enabled, /contacts/ is retrieved and then john's data is loaded and displayed.

If someone visits '/contacts/#john' without javascript enabled, he gets the full contact list, with the focus on the link to john's page, which he can then click.

By using this scheme: - search engine and other non-javascript users can fully use the site and see completely normal urls - XHR page loads are supported - XHR loaded pages don't break the backbutton - XHR loaded pages are bookmarkable - Bookmarks to XHR loaded pages are fully shareable if the recipient has javascript enabled or pushState is supported, and at least not totally broken if not.

The only drawback I can see is the 'sharing bookmarks with someone who has no javascript support' issue - is that a real biggie? In addition of course to the 'made error in javascript, now all stops working' issue - but that is something that has not so much do with the #! debate as well as with the 'is loading primary content via XHR a good idea' debate.

To me it seems that current users of the #! technique have just gone overboard a bit by relying only on the #! technique instead of combining it in a progressively enhancing way with regular HTTP requests.

Bit of a negative sentiment - pity. Beautiful is a rather subjective thing. It looks not too shabby and there is the core api if you want to make it look really different. The big thing to me is - it is here NOW, it seems to work in the hodge-podge of browsers I've to support, nicely falling back with decreasing browser smartness. And it uses jquery - which I happen to use as well.

I've an application shipping in a few weeks, which has some minor features which require uploading files. Those are not that often used, so I've not spent much time on the upload part yet - just a basic file-upload form.

Things like this however allow me to make those file-uploads look way nicer (from the point of view of the end-user) with very little time investment from my side. And it allows me to do it NOW. And if I want to be cheap, I can get it even for free! (I know, I know, GPL is not about being cheap, leave the torches at home please ;-).

Given the above, I'm not overly concerned as to how it works out over 3 years from now. I've to ship in 4 weeks. And whatever solution I choose now is not set in stone.

So a big "thanks" for a) putting in the hard work and making the tool in the first place and b) bringing it to my attention.

(having said that: I also tripped over the large plus sign in the header ... - but that is easily modified of course, not a major thing).

I'm a noob regarding investing, so bear with me if I use incorrect terms or kick open doors that are already open etc. but if my interpretation of this graph is correct, it also offers some guidelines for investing in funds (not individual companies):

1) from the visual it seems to me that the starting year is the most relevant. If you start in a good year, it will mostly turn out right, regardless whenever your end (exceptions aside, for which see point 2). If you start in a bad year it will mostly work out badly unless you really have some time to spare or manage to run into a very rare occasion (e.g. starting in 1947 and ending in the mid 1950's). But that's just from the visual, which can be very misleading, so the raw data points would be interesting to do some statistic exercises. If that holds true though, it could be a good guideline - assess the current returns of a particular fund and do not invest [in it] if the current returns are not high enough. While this would make you, by definition, miss out on any really spectacular returns, it could reduce risk enormously without sacrificing much in terms of returns.

2) if you happen to have invested in a fund that took a nose-dive, hang on to it and don't sell for a long while, as in the long run you're apparently very likely to end up at the 20-year median (guess it's called a median for a reason ;-) which is not too bad. At the very least your loss is going to be minimized with time.

Exception in the way that we suspected that if there would be a european country where eating outdoors would be more common than a home cooked meal, it would be France.

But that was mostly based on observations during business trips to France - which most likely skewed our arguments quite a bit.

That definitively plays a role I think. Though that does not explain why the "bad food" seems to have won. It is easy enough to make great tasting food with high quality ingredients. Granted, that would not be cheap - but then again, we don't buy iPhones because they're cheap either.

Interesting data point - discussing this over dinner made us arrive at France as the only suspected exception in Europe, but apparently it's not.

Did Tony indicate what initiated the change?

I frequently read this kind of articles on the web, and every time I'm amazed by it. Preparing food yourself is the rule in my corner of the world (the Netherlands) - going out for dinner an exception. And up until a few years ago you'd be hard pressed to find a public place that actually served breakfast.

Of course, not every Dutchmen is a great cook (to say the least ;-) but I think you'd have a hard time to find a Dutch adult who doesn't have the means or is not able to prepare (much) more elaborate meals than discussed in this article. And probably this holds true for most of Europe as well. Maybe even for the rest of the world except the US?

Having said that though, I feel that the situation is slowly changing in recent years - primarily for the wealthier part of the population, but still. Kind of makes me sad if I see products in the supermarket which are 'ready made' and 4 times as expensive as the individual ingredients, while knowing that making the same dish from scratch would hardly take longer than preparing the 'ready made' variant and be healthier and cheaper to boot.