forgotusername

> decrypt your messages wholesale.

Eek, that sounds fun :) Tell us more?

If I'm not mistaken (and haven't read up on this stuff in years, so probably), the majority of encryption modes rely on XORing the stream of bits from the cipher with your plain text.

In that way, both sender and receiver need only generate the same cipher bits and apply XOR to encrypt and decrypt (meaning encryption and decryption are actually identical operations!). A side effect of XOR is that a single bit flip in the ciphertext corresponds exactly to a single bit flip in the cleartext. An attacker with knowledge of your cleartext can therefore modify it without ever needing to know the cipher parameters.

Imagine a session cookie that contains a single 32bit integer, the user ID. Now attacker knows his user ID, so he merely needs to XOR the cookie with his ID, then XOR it again with his desired ID and voila admin privileges. Wrapping the cookie in a MAC prevents this kind of manipulation.

I think it's quite simple, and we're all guilty of it at some time or other: it's much easier to reinvent and reshape already solved problems in our own image than it is to innovate in any useful manner.

This explains the abundance of languages that can all trace their conceptual heritage to the 60s, the abundance of basically identical Javascript frameworks, web frameworks, ORMs, and so on, the majority of which IMHO should never have left the spinning rust in the original developer's machine (highly applicable to many of my own projects).

It's also one reason why the 'code cleanup guy' on a team might not be doing anyone a favour – what hard work is he avoiding by endlessly obsessing over his preferred syntactical representation for a 5 line function? etc.

I think this also relates to a youthful rejection of 'good enough' – the desire that, this time around and if only everything was all beautiful and homogenous, it's all going to be perfect.

Creepily, it claims someone is already signed up for my username.

It's just an alternative for someone already offering to work for free – I'm certainly not about to write a business plan around it.

My use case is simply that I like my own comments/SMS/tweets/etc. archived and searchable, as it's an easy way of keeping track of stuff with zero effort. In the case of HN it would also serve to avoid the common situation where I miss a reply until hours after the replyer's lunch break ended.

I'd pay $20/year if you build a reliable HN <-> e-mail comment gateway. I'd pay double if you convinced PG to let your app sync people's comment history. Use e.g. Gmail OAuth IMAP authentication, sync to a label, optionally sync bidirectionally (i.e. comment replies from Gmail), but that's only marginally more useful than getting e-mail archives of comments here.

Hell, if you write it in Python then I'll even donate the comments page parser I already have written (including a comment's original marked up plain text recovered from the HTML).

One of many tiny projects that just need a few concentrated days that I've never gotten around to. I suspect you might find quite a few here willing to pay that same $20/year.

Everyone bumps into this at some time on their journey through Python, however personally it's not something I've contended with in years and there is good reason for that:

> Suppose you have a function which takes a person and allows you to update the person's name, age, both, or neither

The problem is not the lack of some fundamental feature, it is one of obviousness in interface design. A trixy interface as given by the example leads exactly to the kind of problems the library hopes to eliminate. Instead how about:

    def update(person, attrs):
        pass

    def update_with_email(person, attrs):
        update(person, attrs)
        send_email(person)

Not only is the problem avoided, but a problem of namespace pollution has been fixed too. Overusing keyword arguments in a hyper-generic manner forces extension of the code to require definition of a new function in order to avoid potential breakage.

For example, how does one add a 'use_html=True' parameter to update_with_email()? Perhaps by adding a 'use_html' kwarg that hopefully doesn't conflict with Person's attribute namespace, or perhaps by adding '_use_html', hoping to skirt the problem by introduction of ugliness. For a 'clean' backwards-compatible solution, we're forced into something like:

    def _real_update_with_email(person, use_html, kwargs):
        update(person, **kwargs)
        send_email(person, use_html=use_html)

    def update_with_email(person, **kwargs):
        _real_update_with_email(person, False, kwargs)

    def update_with_html_email(person, **kwargs):
        _real_update_with_email(person, True, kwargs)

How can the caller dynamically form the attribute names if they need to?

    # TODO: something seems terribly wrong here, I can't quite put my finger on it.
    update(person, **{'previous_' + attr: value})

etc.

I realize abuse of \* \* is very much a religious issue, and at first sight, one of the superficial attractions to Python (at least for me, way back in time), however with experience it seems to regularly introduce more problems than it solves outside a few niche uses. The idea of adding an 'undefined' value has been discussed going back years (try grepping python-ideas and python-dev) and it's never made it in for good reason.

There is one place where an 'undefined' might seem useful at first, for example in the implementation of `dict.pop()` where a missing second argument signals the need to raise KeyError. The problem is that no published, public value including 'undefined' can be used as placeholder without introducing another ugly rule to the language: the ability to use `pop(..., default)` with any default value except 'undefined'! (net simplicity gain: zero)

Evil routing has been employed a whole bunch of times going back decades, most visibly a couple of years ago when IIRC Iran (?) started advertising bad routes for a bunch of big sites, including Google

Torvalds must be on drugs or also trolling hard to be talking about an absence of carrier lock-in and Android in the same sentence - an OS rendered practically unusable should you elect not to associate your device with a Google account, and all that such entails.

I've no doubt this presentation makes some interesting points, but I'm as inclined to finish reading it after noticing it's destroying my browser history as I would continue evaluating software after noticing it's randomly corrupting my home directory.

Please leave history alone or at least use window.history.replaceState().

Missed one (which I still consider valid): making it trivial for others to extend the firmware might endanger other products on sale. ATI learned this a few years ago, when it was discovered a software upgrade was all required to turn a sub-$150 graphics card into a far more expensive model.

From the user's perspective, all they see is hardware that can Do So Much More simply with a little firmware jiggery, but from the manufacturer's perspective, they've spent billions developing that firmware and if they choose to differentiate depending on its configuration, and they've paid the infrastructure costs to reach this position of privilege, then as far as I'm concerned that's their prerogative.

The cash market spread is usually something like 4-6 basis points for major pairs (i.e. 0.04%), even accounting for the fictitious mid rate, you still have orders of magnitude difference from the retail spreads. Thomas Cook, a major UK travel agent, is currently offering around 6% for GBPUSD going by their web site.

The release version is available through TechNet subscriber downloads

Couldn't help but do a little digging..

In the first 99 comments of this page, average comment text size is 231 bytes. Counting all comments in articles on the front page right now, there's 1678 of them, making somewhere around 388kb of comments for the past 12 hours.

So for safety's sake round that to 1mb/day and multiply by site age (5 years).

That gets us 1825mb, projecting forward it's difficult to imagine a time when a single recent SSD on a machine with even average RAM wouldn't be able to handle all of HN's traffic needs. Considering the recent beefy Micron P320h and its 785kIOP/sec, that could serve the entire comment history of Hacker News to the present day once every 2 seconds, assuming it wasn't already occupying a teensy <2gb of RAM.

Even if Arc became a burden, a decent NAS box, gigabit Ethernet, and a few front end servers would probably take the site well into the future. Assuming exponential growth, Hacker News comments would max out a 512GB SSD sometime around 2020, or 2021 assuming gzip bought a final doubling.