HN user

deafbybeheading

83 karma
Posts0
Comments50
View on HN
No posts found.

Only if you interrupt the actual `rm`, no? If you interrupt the main command, you won't get a 0 exit code so the `||` branch still executes.

Your mechanism is clearly safer, but the user is required to clean up `foo.tmp` themselves in case of failure, so it's not really comparable.

Fun fact: ASCII actually reserved control characters for this stuff. 1F is the "unit separator" and 1E is the "record separator". There is even a "group separator" (1D) and a "file separator" (1C).

Which means you can't safely use it for arbitrary data (since your records themselves could contain these separators). Most of the time that doesn't matter; sometimes it does.

In about a year of using Campfire, I never saw a single bug fix or new feature. We've since moved to HipChat, and while it's not perfect, it's so refreshing to pay for a service that gets regular updates (not to mention has decent mobile clients).

General usability is important in pretty much all interfaces, but discoverability isn't. There's a big difference between designing an interface a user will be instantly familiar with, and one that's optimally suited to the task at hand.

That's absurd. The law of diminishing returns comes into play, and for most cases, assembly is just not worth it (whereas C or C++ is). Rust seems like another interesting take at that sweet spot, but it seems like in Go this was an afterthought (though to be fair, the performance benefits of C / C++ are often cargo-culted even when that kind of performance is completely irrelevant, so Pike still has some valid points).

The default is determined by initdb, but was capped at 32MB due to the above issue. With this change, the cap's been bumped to 128MB.

As a big fan of the GPL, ...I'm skeptical. I don't think Valve would benefit from keeping any potential modifications (or even plugins) secret, given that these would be far removed from its bread-and-butter.

A friend once suggested that outside of licensing pressure, maintainership is a huge driving force behind open-source contributions: you find something that does almost what you need, then you make the changes you require, and if you get these accepted upstream, they're maintained for you for free, pretty much forever. In many situations, that's far more important than any IP you're trying to conceal.

Indeed. A few years ago, I worked in an Adobe Flex on a reporting front-end that had significant client-side complexity and required us to support relatively old browsers. We re-evaluated competing JavaScript solutions periodically, but we never found anything that was worth the gamble of moving off that platform (even though rumors of its death seemed less and less exaggerated every day). These days, I'd move to Ember or Angular in a heartbeat.

Sure, I was being facetious. Even with actions that are simple to execute, I'm somewhat skeptical that a black box with a single recommendation is the best answer. I think that presenting the analysis as "do this, and here is why" would be a nice alternative for more complex systems--frequently dashboards and such throw data at you and completely punt on helping you interpret it.

The thing is, unit tests are another "use case" for a given piece of code. Many people here are saying, "I wouldn't do monkey patching in production, but it's not really a problem for stubbing in test code." And what happens when you want to make different use of that code in production? Sure, "YAGNI, rewrite as necessary" and so on, but ruthlessly applying YAGNI leads to code so inflexible that you need to rewrite a whole component to make a change in one class (or start playing with monkey patching in production code, but I have not seen anyone advocate doing that liberally).

> Today was my first real usage of PostGres

Then let us welcome you with some pedantry! Postgres or PostgreSQL, but never PostGres or--FSM forbid--PostGreSQL.

More seriously,

> fdw looks easy to start, but probably hard to master it.

Yep, like a number of Postgres features, such as user-defined types and user-defined aggregates. It's a great system, and not nearly as stuffy or hard to use as you may have heard.