Comment by jrockway | Hacker News Reader

Comment by jrockway | Hacker News Reader

This is what's nice about using languages with libraries. If I want to do an unsalted SHA-1, like news.yc, I would write:

    use Authen::Passphrase;
    my $pw = Authen::Passphrase::SaltedDigest->new(
        algorithm  => "SHA-1", 
        passphrase => "passphrase",
    );

If I instead wanted to be secure, and use bcrypt (which I always do, even for the most trivial sites), I would just write:

    my $pw = Authen::Passphrase::BlowfishCrypt->new(
        cost        => 8, 
        salt_random => 1,
        passphrase  => "passphrase",
    );

Notice how I get better security without any extra effort? That is the joy of not being the only user of your programming language, and that's how you ensure that people do the Right Thing with your data -- make it easy for them.

(I'll also mention that it gets better; with Moose type coercions, I can basically treat the password as cleartext -- the type coercion converts a Str into a Passphrase. To set it, I supply the cleartext password as an initarg when instantiating a user; when changing it, the writer accessor handles the coerciion; when checking it, I delegate to the passphrase's check_passphrase method. A great API with great security, involving almost no effort on my part. <3.)

Don't you think (system (+ "openssl dgst -sha1 <" fname)) can be as easy replaced with (system (+ "bcrypt whatever_parameters <" fname))?

Notice how I get better security without any extra effort? That is the joy of using an operating system.

Apologies for the wording of my comment. What I mean is that you don't have to worry about libraries for languages a lot if you can use the power of your OS ecosystem (especially, *nix one) in your application (considering performance and other limitations).

If it was just as easy, why wasn't it done?

Doing system requires forking your entire interpreter/VM. That's a huge performance penalty.

There is performance penalty, but come on:

Under Linux, fork() is implemented using copy-on-write pages, so the only penalty that it incurs is the time and memory required to duplicate the parent's page tables, and to create a unique task structure for the child.

(from fork(1) man pages)

> " time and memory required to duplicate the parent's page tables "

Performance penalty is fairly significant ( unless it's done up front, i.e. to setup a pool of processes, like Apache's prefork mpm ). So doing a fork() per each request is actually a really bad idea (as is creating a new thread, but that's a whole other rant I have reserved) -- I'd say it's an anti-pattern (in Java world it's the "one thread per connection" Enterprise(TM)(R) idiocy lot of servlet containers do/users to do disregarding ThreadPools and NIO).

Memory penalty really depends on your language and its VM (and it's assuming no memory leaks). I haven't looked at arc + mzscheme, but it's actually a big issue for me at work with Perl right now at my present work (too much functionality was implement as cronjobs invoking Perl scripts which do system() after system() -- vs. doing it as daemons doing xs calls into C libraries).

I'll grant mzscheme and arc are likely lighter weight than Perl and its JIT, but unless you're doing pure C it's only a matter of degree.

Well, as you can see, HN serves a lot of traffic and has a system() call :-)

Of course, everything is compromise between performance, ease of use, features etc. I'm not arguing with this.

HN isn't a commercial site and actively tries to restrict traffic. The advantage of having already made something people want is that you can make non-commercialized sites and limit the growth to the level you find comfortable :-)

Reply on news.ycombinator.com