pjz

Daily since Google Reader shut down, via self-hosted commafeed (https://github.com/Athou/commafeed).

...and daemontools. and djbdns. He was quirky about licensing for a long time, but I think has gotten over that.

I agree it's kind of odd that our dev process is essentially a sea of broken states with intermittent workingness (if you count by states, I mean). Version control commits are an attempt to hilight/preserve those working states.

Limiting deltas to working-only states would, I think, result in something akin to MIT's 'Scratch' language, where kids put together puzzle pieces - a program can only be wrong at a semantic level, never at a source code level. OTOH, refactoring power tools available in modern IDEs are a bit of a counter-argument in that they allow code transforms that don't usually make much of a semantic difference (eg. 'inline this', 'extract this as a variable', etc) But as you say, that's "written code" not "writing code".

For writing code, I think the closest current IDE feature to tylr would maybe be syntax hilighting. It'd be cool to maybe have some kind of 'expression hilighting' mode, and maybe an 'expression editor' mode with actions like tylr supports.

His twitter was active less than an hour ago: https://nitter.net/zverok

>(Kibana is not supported with zinc. Zinc provides its own UI).

1. I was hoping for a drop-in replacement for Elasticsearch. A new/different API means Zinc can't leverage existing tools that use Elasticsearch.

2. I don't like that you're bundling zinc with a UI; that disadvantages anyone else trying to build a better UI and often (usually?) leads to tying the db too closely to the UI (or vice versa)

As far as I'm concerned, America's Test Kitchen is the gold standard, with Consumer Reports just a little behind them.

Perl 4, 5, or 6? What's CPAN's dependency resolution like?

HN has been around for at least 5 years, right? Probably some interesting stats on how many 'Show HN's are live, dead or decomposed. Live: updated in the last year Dead: not updated in the last year, but still available. Decomposed: not findable/available.

Exactly: Any _individual_ change may or may not be good - but change _in general_ is good, because without it there's no chance of getting better. And any hope of improvement is infinitely better than no hope of improvement.

...isn't that called a `try` block?

...why does everyone forget that `getattr()` has an optional `default` argument? It's helpful for stuff like this.

This is subtly incorrect. Correctly, it should be:

    libpaths = paths.split(":") if paths is not None else []

or else falsey values of paths (0, [], False) can still cause an error.

This stuck out to me too. Fractals teach us that infinite length can be fitted into finite area, so I'm dubious about this claim. Though I guess if we're in the realm of physics, the Planck constant determines a kind of minimum length, so the original statement may be true?

I don't think his point is so much about the source as it is about updating N containers. For instance, say there's a known libssl bug. Can you tell how many of your containers are running that version of libssl? And how do they get updated?

XF86Config is now Xorg and is only used in the rare cases (dealing with proprietary drivers or strange configurations, mostly) where you want to override the defaults. Most people don't have an Xorg.conf file anymore.

For all that people complain about pulseaudio, it's been working pretty well for me for the last 5 years or so.

I'll admit I'm a bit of an outlier, though: I run xubuntu as my base system but i3 as my main window manager. I'm sooo much more productive on it than anything else I've ever used - it's amazing how much time I used to spend adjusting window sizes.

...fast, correct, cheap: pick two.

Maybe durable goods should be taxed inversely based on the length of the warranty.

See http://liquidfeedback.org/

> Why would anyone prefer Python, given that there is a much faster, free alternative in Julia, which is just as easy a language to program in?

Python also has a much more mature ecosystem (read: more pre-written libraries to do what you want to do), and delivers some of the UI benefits of Mathematica if you take into account ipython notebooks and packages like Bokeh.

Your 'Less Performant' paragraph seems to misunderstand where the big CPU hit happens: It happens with database inserts (which require mining a valid nonce), not with verifies (which only require verifying that a transaction block has a specified hash). So reads/verifies are fast, but inserts/updates/deletes are slow. Also, the mining parameters can be tuned to make it easier/faster to do an insert, at a tradeoff of a larger blockchain history for initial clients to process and more orphans (See litecoin, which has a 2.5min block processing target). So I think you should consider that a 'tuning parameter' based on your application, more than a set-in-stone disadvantage.