Voyager 1 is on the edge, and so is he - <AUTHOR> http://www.latimes.com/news/local/la-me-0414-ed-stone-20110412,0,4527527.story

<comment><USER2> I once found a manual describing the machine code for the Voyager computers (can't find it anymore). Recently there was a flipped bit in memory which caused serious problems: <http://www.jpl.nasa.gov/news/news.cfm?release=2010-151>

One of the things I find most fascinating about the mission are the RF systems -- the antenna on voyager is approx 40 watts yet the ground systems can read something on the order of kilobits per second -- and they are billions of miles away.

This is an interesting read too: [http://books.google.com/books?id=yws55Rx1orEC&pg=PA28...](http://books.google.com/books?id=yws55Rx1orEC&pg=PA28&lpg=PA28&dq=voyager+mission+error+correction+codes&source=bl&ots=V2oS9O2t9d&sig=OBnExaOWkHvHZlZLpJf7p9FgUJk&hl=en&ei=tAmnTcD9NNCbtwftkOCFAQ&sa=X&oi=book_result&ct=result&resnum=4&ved=0CCgQ6AEwAw)

<comment><USER3> Potentially, optical (laser) transmitters have a lot more bandwidth, but need very fine aiming control. At those distances, a high-gain antenna would have to be too large to be feasible, even with an extensive upgrade of ground-based receivers.

<comment><USER4> In the book "Voyager : seeking newer worlds in the third great age of discovery" they said that as the crafts got further out they had to use large radio antenna's in Spain, Hawaii, and Australia to lock onto the signal, creating an Earth-scale virtual antenna.

Truly amazing stuff.

<comment><USER2> These are part of NASA's Deep Space Network, used to communicate with the fleet of interplanetary spacecraft (as well as plenty of satellites and the ISS). The you mentioned the three largest ones, each with a 70 meter dish.

<comment><USER5> And here's the pic:

[http://deepspace.jpl.nasa.gov/dsn/images/picture_70_bw_lg.jp...](http://deepspace.jpl.nasa.gov/dsn/images/picture_70_bw_lg.jpg)

</comment></comment></comment></comment></comment><comment><USER6> What a magnificent story. It's amazing to me how he he and the spacecraft are so connected. The radios go off, he works on other projects, until one day they are reunited as both reach the ends of their journey, transitioning to whatever lies beyond.

I'm saying that last part without hyperbole, which is beautiful to me.

<comment><USER7> I remember being about 5 years old in primary school and learning about & watching Voyager 1 reach Jupiter. It's incredible to think that thing has been flying through space my whole life.

A beautiful story, Ed Stone's life would make a great movie.

<comment><USER8> I remember when Voyager II reached Neptune and we watched it in science class in primary (grade) school. Different specific events, but a shared experience across a generation.

<comment><USER7> And when a Voyager crosses the heliopause in another ten or so years time, entering deep space, that'll be another new generation inspired by this incredible feat of humankind.

</comment></comment></comment></comment><comment><USER9> What wonderful writing this was. I have been really pleased with some of these more pop articles recently: the Dan Plan one and the Snider huffpost piece being two examples. Very pleasant to read between hacks.

<comment><USER10> in that case you may like to read this one as well.

[http://www.latimes.com/news/science/la-sci- language-20110414...](http://www.latimes.com/news/science/la-sci- language-20110414,0,1473928.story)

i found it very enjoyable.

</comment></comment><comment><USER11> We're where we are today because of pioneers of previous generations. My eyes always water a bit when I think about how much they would have wanted to see what we have now.

Beautiful story.

</comment><comment><USER3> While the Sun's radiation extends up to 100au or so, its gravitational influence goes to over 100K au (2 light years). In this deep freezing wasteland we may find many more orbiting bodies than in the solar system proper.

<comment><USER12> The oort cloud is supposed to lie in that range, and it is speculated to contain several trillion objects.

<http://en.wikipedia.org/wiki/Oort_cloud>

</comment></comment><comment><USER13> Here's a tool to check out some of the raw imagery from Voyager (if you can figure out how to use it. . . the tool is meant for planetary scientists). Check out Jupiter/Saturn. The next dump should get have more stuff from Uranus/Neptune. <http://pilot.wr.usgs.gov>

</comment><comment><USER14> It's easy to forget how little we knew about the Solar System prior to the wave of exploration in the 60s, 70s, and 80s. A great deal of unfounded but seemingly logical speculation was wiped away and replaced with solid observationally backed theory.

As heroic and remarkable an era of exploration as any. Indeed, perhaps all the more remarkable for its speed.</comment>


Ask HN: all the macs in the room are 41m early, do yours too? - <AUTHOR>

So basically all the macs in the room I'm in (mine included) are 41 minutes early. We are all either on Apple timeservers, but I am on pool.ntp.org. Are we the only ones? Paris timezone here.<p>See for yourself: http://i.imgur.com/D00IFMW.png <comment><USER2> I can only talk for my own Mac but no, its time is correct: 18:03. Both when using time.euro.apple.com and pool.ntp.org.</comment>


To Build a Progressive Web App or a Cross-Platform App with React Native? - <AUTHOR> https://www.bluelabellabs.com/blog/to-build-a-progressive-web-app-or-a-cross-platform-app-with-react-native/ <comment><USER2> It's always a complicated to make a choice what type of app will give you the best results in the future. I found one valuable long read aimed to help smooth this process, it reveals all pros and cons of all popular frameworks and kinds of apps [https://litslink.com/blog/mobile-applications-development- na...](https://litslink.com/blog/mobile-applications-development-native-web- cross-platform)</comment>


Mycroft – A distributed declarative logic language - <AUTHOR> https://github.com/enkiv2/mycroft

<comment><USER2> > PROLOG, partly for historical reasons, is quite slow.

This is not an easy statement to make, nor particularly accurate. There are many, many prolog systems available. Perhaps the free prolog compilers out there are not stellar in performance, but commercial production prolog systems are not likely going to be slower than what is proposed here, and yet will still probably be more feature-rich.

<comment><AUTHOR> Speed is achievable in prolog in a variety of ways. One is to make use of cuts and structure code so that it fails early. Another is to optimize the hell out of the interpreter. Another is to rewrite prolog code in another language & optimize that (which is pretty standard practice for developing expert systems). But, ultimately, prolog is always going to be comparable in time complexity to a depth-first search. Tricks with cuts and structuring code to avoid deep recursion are, at best, equivalent to a time-consuming attempt to sort a tree such that the most likely desired results are the first to be searched -- which is to say, they don't change the underlying time complexity of the process.

In worst case, MYCROFT has the same time complexity as PROLOG. However, with notation of determinate predicates, memoization is possible -- something that PROLOG _cannot_ do without fairly complicated analysis. On top of that, MYCROFT makes distribution of load trivial. Because of cutting rules and other mechanisms designed for optimization of PROLOG code on single systems without concurrency, any form of concurrency on standard PROLOG is difficult -- after all, you can spend a bunch of cycles determining a result only to discover that that result was going to be discarded by another branch and never needed to be computed in the first place. MYCROFT doesn't have this problem.

Worst case time complexity is equivalent in MYCROFT and PROLOG. However, average case in MYCROFT approaches linear time as computations occur even on non-optimized code, and average case in MYCROFT approaches linear time on non- optimized code as node count grows even for a static number of computations. Average case in PROLOG for non-optimized code is the same as worst case. Any arbitrarily large constant factor added to time for MYCROFT is irrelevant -- you can't optimize the depth first search out of a depth first search by writing it in machine code.

There have been other PROLOG implementations (commercial ones) that did automatic parallelism / distribution of tasks. I'm unaware of any that still exist, but it was being researched back in the 80s. There are PROLOG-like languages that have det vs nondet notation (MIT Church comes to mind). In this sense, I'm not breaking new ground. I'm unaware of any other system that combines det/nondet notation with aggressive distribution and memoization.

(This is not to say that the system is carefully optimized. Some behaviors are quite naive -- intentionally, because clever solutions in this case are subject to clever bugs, so it doesn't make sense to introduce them until the system is more stable. The system is written in Lua specifically to make an ESP8622 port easier -- even though a prototype in C was written & would have been more efficient. We round-robin requests rather than using a distribution mechanism based on hash similarity as originally planned in order to avoid dealing with potentially slow pure-lua hash implementations that would prevent the system from being portable. So, sure, it could be made faster. But it already has an average case better than any standards-compliant PROLOG system.)</comment></comment>


JQuery plugin which lets your users easily define keyboard shortcuts - <AUTHOR> http://suan.github.com/jquery-keycombinator/

<comment><AUTHOR> Plugin author here. There seems to be many solutions out there which let a developer specify keyboard shortcuts code-side, but nothing which lets their users easily enter/change keyboard shortcuts in a text box, with good usability. Here's my attempt at the problem.

Hopefully if this is easier, productivity sites like github will start to allow users to define their own keyboard shortcuts rather than forcing down a predefined set on you.</comment>


Show HN: K6 – developer-centric load testing using Go and JavaScript - <AUTHOR> https://k6.io <comment><USER2> This looks incredible for work I was previously using Tsung / Gatling for.

One request: please allow the output of either a) a CSV log of every request and it's timing or b) a configurable histogram of request timing, not just some percentiles and averages. That info is pretty much required for doing any more advanced analysis beyond "the service is fast enough". [https://github.com/tsenart/vegeta](https://github.com/tsenart/vegeta) does this really well (but doesn't have the scripting abilities of this tool).

<comment><AUTHOR> Thanks for the nice words! If you see anything missing, don't hesitate to create an issue about it on Github ([https://github.com/loadimpact/k6](https://github.com/loadimpact/k6)). We're trying really hard to build the things people ask for. About CSV output though, we have JSON output with single request timings, see [https://docs.k6.io/docs/results-output#section-json- output](https://docs.k6.io/docs/results-output#section-json-output)

Is JSON useful to you, or do you prefer CSV?

<comment><USER2> That looks like what I'm looking for, thanks! Is there documentation of the format of those JSON logs? CSV would probably be a useful addition just for ease of ingestion into analysis tools and databases.

Once I get a chance to test this out, I'll definitely report any issues through GH.

<comment><AUTHOR> I'll update the docs with some info on the JSON format first thing on monday!

If you should happen to try out k6 in the meantime, most of the JSON contents should be recognizable/understandable just by looking at the output, if you know what metrics k6 collects (which is documented on docs.k6.io). You can try running with e.g. 2 VUs for 2 iterations, to get a tiny amount of output data but something that looks like a real load test: k6 run --vus 2 --iterations 2 --output json=output.json script.js

</comment></comment></comment></comment><comment><AUTHOR> k6 is our attempt at creating a modern, developer/devops-centric load testing tool suitable for automation. It is released as open source on Github, scriptable in JavaScript (ES6), and built on a Golang core that provides good speed and concurrency/scalability.

</comment><comment><USER3> At work, we had to do some load testing and we used Vegeta: [https://github.com/tsenart/vegeta](https://github.com/tsenart/vegeta)

Had anyone used both to point out the main differences from k6?

<comment><AUTHOR> I am of course biased, but I have used Vegeta. I did a writeup on it, and a bunch of other load testing tools in this article: [http://blog.loadimpact.com/open-source-load-testing-tool- rev...](http://blog.loadimpact.com/open-source-load-testing-tool-review)

The single biggest difference is that k6 lets you write test cases in real code (JavaScript), while Vegeta will only let you supply a static list of URLs to hit. Vegeta has some things k6 does not have, to be fair (like constant RPS-rate load), but k6 was created to address what we saw as missing in Vegeta and most of the other existing tools. We think developers want to write _code_ to test things, so we created a tool that lets you use JavaScript + a scripting API designed for load testing and automation.

</comment></comment><comment><USER4> Any plans to support distributed testing (e.g. like Tsung) or at least the ability to aggregate results once you've run it manually on multiple nodes?

<comment><AUTHOR> Yeah, we have this issue: [https://github.com/loadimpact/k6/issues/140](https://github.com/loadimpact/k6/issues/140)

But you can actually aggregate results already, if you use InfluxDB as results storage: you can have multiple k6 instances push results data to the same InfluxDB instance. Results are just time series samples, so there are basically no bad effects if you do this - you get all the results in a single db, with correct time stamps. The only difficulty lies in orchestrating the multiple k6 instances so they're in sync and you get the traffic levels you want (i.e. they ramp up/down at the same time). But for a simple ramp configuration, or a config where you run at a stable traffic level, it shouldn't be a problem.

<comment><USER4> Super, thanks. Didn't realize it had InfluxDB support.

</comment></comment></comment><comment><USER5> The params of http.get are not documented. Is it possible to specify a random timeout for every http request to simulate long poolling?

<comment><AUTHOR> Thanks, I'll make sure the "params" object gets documented also. Currently, there is not so much you can set per HTTP request. You can basically add HTTP headers and you can also add tags that lets you single out specific results based on those tags (e.g. when using thresholds or when plotting graphs of results).

So - HTTP request timeouts can not be changed at the moment, but this is something I think would be very simple to implement. If you open an issue about it I'll see what we can do to get it implemented quickly.

</comment></comment><comment><USER6> Does this support websocket?

<comment><AUTHOR> No, there is currently no support for websockets. We have been asked for this a couple of times though, and are considering bumping up the priority for a websockets implementation.

As of now, k6 can do standard http, https (and it also supports HTTP/2)

<comment><USER6> Thanks for the info! Would love ws suppprt!

<comment><AUTHOR> If you're interested, here is the Github issue for Websockets support in k6: [https://github.com/loadimpact/k6/issues/178](https://github.com/loadimpact/k6/issues/178)

We'd really appreciate any comments/feedback you may have on exactly how it should be implemented.

</comment></comment></comment></comment><comment><USER7> Anything that uses Golang is by definition not developer centric.

<comment><USER8> That's one hell of a persnickety definition.

<comment><USER7> I knew it would be unpopular. I get a few u popular posts a year.

But I am very, very irritated by Golang while I am working with it on a daily basis.

It's entire design is informed by assuming that no developer should understand the codebase, but should instead read it over and over. Symmetrically, no insight can be offered in the code, only a rote transcription of an inductive design.

The net result is a language hostile to both those writing and those reading the code. No shortcuts are offered or taken. All error handling must be done manually. All data structures must be reimplemented over and over with different test suites for each one.

<comment><USER8> Heh. You can't say I was wrong calling you persnickety, at least!

<comment><USER7> I guess I'm gonna have to write a blog post about how hateful Go is.</comment></comment></comment></comment></comment>


Where Pizza Rat, fake news and art collide there's a wizard named Zardulu (2017) - <AUTHOR> https://www.vox.com/culture/2017/4/24/14912316/zardulu-viral-videos-mythmaking-surrealism-pedro-lasch <comment><USER2> I'd hit a like button, but that's about it. I can't really engage any enthusiasm for it. Why? None of it seems new or challenging to me. I like my art transgressive. But then again I'm old and sometimes grumpy.

</comment><comment><USER3> There is nothing challenging in her work, as another comment noted, but there is also nothing honest in it. Zardulu is an attention-seeking persona with nothing to say aside from "Look at me!"

<comment><USER4> Her work is explicitly about mythmaking and the laziness of modern media. Her work was all about "fake news" before the term (and the trend) existed.

<comment><USER3> Art speaks for itself. If you have to sit down with a reporter from the Washington Post and explain it then the art itself is not the goal.

<comment><USER5> Pizza Rat was literally speaking for itself (in the sense that all viral memes do) before anyone knew the word Zardulu.</comment></comment></comment></comment>


Ask HN: What are some positive things happening around the world? - <AUTHOR> There is too much bad news to listen to right now.  What is some good news I can share with my team going on around the world? <comment><USER2> Finally, Some Privacy: After 10 Years, Giant Pandas Mate in Shuttered Zoo -[https://www.nytimes.com/2020/04/07/world/asia/panda- mating-h...](https://www.nytimes.com/2020/04/07/world/asia/panda-mating-hong- kong.html) lol

</comment><comment><USER2> Trifecta: Taiwan reports zero new coronavirus cases for 3rd time - [https://www.taiwannews.com.tw/en/news/3918074](https://www.taiwannews.com.tw/en/news/3918074)

</comment><comment><USER3> Less pollution. Happier pets.</comment>


Fake cancerous nodes in CT scans, created by malware, trick radiologists - <AUTHOR> https://www.washingtonpost.com/technology/2019/04/03/hospital-viruses-fake-cancerous-nodes-ct-scans-created-by-malware-trick-radiologists/ <comment><USER2> I interpreted many restaging PET/CTs today and am thankful I didn't have to consider whether the nodules I saw were injected by malware.

I'd be really curious to see what the final "product" of the altered CT looked like to see if the synthetic nodules still look real across a variety of WL/WW settings or if they suddenly look "fake" or "photoshopped". I'm not sure the images have to be encrypted end to end. Wouldn't cryptographic signing be sufficient to verify the authenticity of the image?</comment>


How to act less stupid, according to psychologists - <AUTHOR> http://www.washingtonpost.com/news/wonkblog/wp/2015/10/19/how-to-act-less-stupid-according-to-psychologists/ <comment><USER2> After a moribund launch of my well-intentioned startup in 2012, I know understand what others meant by "you have a lot of courage" (to leave your job and take the risks). What they mostly meant really is that I had the courage to look stupid. Except I didn't know that or care much for what "bravery" meant.

<comment><USER3> What was your startup about, and what happened?

<comment><USER2> You mean, what was the name of the game? You can still call it Riding the Gravy Train [1].

Summary of Failure: Failed to close enterprise sales leads. (Started with the erroneous assumption that being technically able to develop an MVP will prove sufficient to "sell" to enterprises.)

      Reasons:
      1.  Small team (enterprises no like small teams [sic] ... unless ... but we learned the "unlesses" only recently)
      2.  Small team part II - fewer initial leads to grow from consultancy domain experience
      3.  Sales pitches always too technical.
      4.  Solution offering too monolithic (modules preferred by enterprises)
      5.  High overheads during sales periods (enterprise sales lead times went on for 24 months!)
      6.  Couldn't adequately manage emotional temperament during dry spell (spending on overheads - salaries esp didn't help) - resulting in poor major and minor knock-on decisions.
      7.  Emotional Temperament Part II - weak emotional resolve affected creative aspect of job (building the MVP).  Health suffered too with stress.  Spiralled.

However, and the irony is amazing - we closed our first sale after 2 years. This after letting go two staffers and an office, right before switching the lights off.

We build from here. Making new mistakes. And looking stupid for an analysis of decisions later on.

\</comment></comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>---

[1] "Have A Cigar" by Pink Floyd

Come in here, dear boy, have a cigar. You're gonna go far, you're gonna fly high, You're never gonna die, you're gonna make it if you try; they're gonna love you.

Well, I've always had a deep respect, and I mean that most sincerely. The band is just fantastic, that is really what I think. Oh by the way, which one's Pink?

And did we tell you the name of the game, boy? We call it Riding the Gravy Train.

We're just knocked out. We heard about the sell out. You gotta get an album out, You owe it to the people. We're so happy we can hardly count.

Everybody else is just green, have you seen the chart? It's a helluva start, it could be made into a monster If we all pull together as a team.

And did we tell you the name of the game, boy? We call it Riding the Gravy Train.

<comment><USER4> >You mean, what was the name of the game?

The parent poster was wondering what product or service your startup offered.

<comment><USER3> Yep!

</comment></comment></comment><comment><USER5> > Acting in a way that isn't considered stupid is a goal shared by most > reasonable people, but many of them likely overlook one key attribute that > might allow them to better achieve it: modesty.

Unfortunately that doesn't pay. We're somehow encouraged to take risks here.

<comment><USER6> Not an American, but living in the U.S.

That quote is fairly eye opening. My culture is quite a bit more modest than the general American culture, to a degree that "confident" Americans are fairly annoying for not being modest.

That's a very good way to put it, and yes, you're right, it's ingrained in this (HN/Tech) and the more general American culture.

<comment> saiya-jin to be honest, to most cultures out here/there general average American is by far the loudest person around, beyond any modesty. Usually not really appreciated, and the more traditional (ie didn't change that much in last 500 years) the culture is, the worse the effect.

Personally I like it, a very different approach to self-presentation, that in some situations is more effective than usual shy polite careful... whatever,.

But if you go backpacking in remote places somewhere in south asia for example, it can cause a bit of friction with locals sometimes.

<comment><USER7> I can assure you that there's a whole culture of Americans that aren't loud, but they don't tend to travel the world or congregate in big cities, and aren't much represented on TV except as gross caricatures.

</comment></comment></comment></comment><comment><USER8> 1\. Didn't see that coming. (had information, chose to ignore, possibly by way of narcissism or hubris)

2\. Couldn't help themselves. (lack of impulse control, compulsive behavior)

3\. Space cadets. (lack of full circumstantial awareness)

The reverse of all of these being, of course, overly cautious, prudent behavior. A coward.

The brave and the stupid.

Maybe some of us are just lucky.

<comment><USER9> In my humble and cautious opinion, somebody prudent and cautious is not a coward. That's the reason because we have different words.

Prudent is to know that your chances are not good and then refrain yourself despise the pressure you could feel to act.

To be brave is to be scared but to realize that is the moment to act and do it. To be coward is the same but not acting.

You have to be scared to be brave.

To be stupid is not to be scared when you should be.

Knowing how to balance all that would be being wise.

</comment></comment><comment><USER10> _" If you don't want to do something stupid, you probably don't want to have higher expectations of your abilities than you should..."_ I disagree with this statement. I believe that enlightenment, not stupidity, results from pushing our expectations. I think modesty is more important when it comes to understanding the factors that contributed to an outcome, "stupid" or not.

<comment><USER11> I would agree. I would suggest that people who are skilled, and good at what they do did not get to that state without making mistakes that could fall into the categories described in the article as stupid. The trick is, as you say, to determine why said mistakes occured, and importantly to avoid making the same stupid mistakes in the future.

The best practitioners of "insert discipline here" are those that have made all the (survivable) mistakes.

</comment></comment><comment><USER12> I'm a bit disappointed by the lack of source. Is anyone aware if the findings were published somewhere? There's a lot of hand waving and voodoo magic in psychology, so I try to take this type of article with a grain of salt.

<comment><USER13> This appears to be the source of the main study in the article. [http://www.sciencedirect.com/science/article/pii/S0160289615...](http://www.sciencedirect.com/science/article/pii/S0160289615001233)

</comment></comment><comment><USER14> > When given a math problem, for instance, an intelligent person might assume > they aren't capable of the same thinking errors that their peers are, which, > in turn, makes them more prone to commit them.

This is the big truth of this article. So many of the worst people I know make the assumption they can never be wrong because of schooling / general overconfidence.

<comment><USER15> I also know a number of people (myself included) who are prone to this problem. Most of them are not the worst people I know. :)

<comment><USER14> The ones I know become huge jerks if you cast doubt on their answers.

<comment><USER15> I've seen those too. I don't know if this field attracts those types, or if they're everywhere.

</comment></comment></comment></comment><comment><USER16> Number 1 is the Dunning Kruger effect [https://en.m.wikipedia.org/wiki/Dunning–Kruger_effect](https://en.m.wikipedia.org/wiki/Dunning–Kruger_effect)

(A favourite of mine and a regular on HN I bet)

<comment><USER17> The following contradiction is pasted from the British actuarial notes: (hopefully within the terms of fair use)

"Overconfidence

People tend to overestimate their own abilities, knowledge and skills. For example, if you ask 100 people if they are better than average drivers, then you might not be surprised if more than 50% of them reply "yes"!

Moreover, studies show that the discrepancy between accuracy and overconfidence increases (in all but the simplest tasks) as the respondent is more knowledgeable! (Accuracy increases to a modest degree but confidence increases to a much larger degree. ) If this is true then it may not be wise to pass the Subject ST5 exam!

Overconfidence could therefore be a potentially serious problem in fields such as investment where most of the participants are likely to be highly knowledgeable.

Moreover, the available evidence suggests that even when people are aware that they are overconfident they remain so."

<comment><USER18> > if you ask 100 people if they are better than average drivers, then you > might not be surprised if more than 50% of them reply "yes"!

Isn't it fully possible that most people are better than the average? Most people e.g. have more arms than average.

<comment><USER17> The arms distribution is an unusual example of a left skewed distribution. Mostly we are thinking of right skewed distributions, where there are lots of observations humped up towards zero, and then they spread out towards infinity, or symmetrical distributions. In the latter two cases the average would be above or equal to the median, so most people would be worse than or equal to the average.

</comment></comment></comment></comment><comment><USER19> There is a book about that - Thinking Fast And Slow.)

</comment><comment><USER20> There are certain advantages to looking stupid.

</comment><comment><USER21> Be stupid is cool

</comment><comment><USER22> Well, that's 7.2 minutes I'll never get back. Who's stupid now, brah?

</comment><comment><USER23> > "The stupidest thing someone can do is overestimate themselves,"

I wonder if this is part of the reason people self-sabotage with comments like, "It's just a beta, I was rushed, I haven't implemented X yet...", because they don't want to appear confident and then fall short?

> For example, ingested substances or excessive social support can promote > confidence disproportionate to competence.

I would sum this up with the phrase, "Hold my beer..."

<comment><USER24> > "The stupidest thing someone can do is overestimate themselves," [from the > OP] //

That's a worrying conclusion - there's a thin line between not trying for fear of failure and considering that it's only rational that something is beyond you so you should not try.

My young son has many times told me he is unable and will always be incapable of doing certain things. Many of those things he can now do because we didn't accept his considered limitations. To his mind we were overestimating his ability to do and to learn to do.

IMO sometimes it's right to try even when we [feel we] know we will fail - drink driving isn't one of those times [except in very limited circumstances where it could be made relatively safe (cf Mythbusters)].

The researchers seem to call a lot of things stupidity; ignorance IMO is not always through stupidity, equating lack of self-control and stupidity again seems strange to me. There's some overlap for sure.

Lastly, isn't part of the point of the movie Forrest Gump that the eponymous hero does things that are out of ignorance or apparent low-intelligence but that are nevertheless revealed to be acts of heroism, inner-strength, love, longstanding fortitude. Lieutenant Dan doesn't hold back in showing how foolish he sees Gump but "Stupid is as stupid does" and it turns out what Forrest does - courage under fire, friendship with the friendless, gumption beyond normal endurance, and willingness to just do [ignorant, or perhaps wilfully dismissive, of those who see or call him as stupid] - isn't stupid after all.</comment></comment>


Diffscuss – Code reviews in plain text - <AUTHOR> https://github.com/hut8labs/diffscuss

<comment><USER2> I like the interleaved comments with the header and body format. I wonder if the authors knew that unidiffs already support comment lines? From the PATCH(1) man page:

"After removing indenting or encapsulation, lines beginning with # are ignored, as they are considered to be comments."

<comment><USER3> Good question, we did consider using #, the main benefit of which would have been that diffscuss files were still legal diffs.

Against that benefit was the consideration that there could have been comments that _weren 't_ diffscuss threads in a diff, and that would have meant that you could have legal diffs that would have terribly confused any diffscuss parsing.

Add to that the fact that you can get a legal diff back just by piping a diffscuss file through a single grep -v, and we decided not to use # (which I think was probably the right call--overloading comment syntax for functional stuff always creeps me out a bit anyway).

<comment><USER4> IDK if it's too late to discuss this, but a third possibility could have been to use the second character or more of a # comment as a marker for diffscuss.

Something like: #%%%

You get standard diffs and parsability.

<comment><USER5> I like this idea. And how I see it this isn't really mixing comments and functional stuff, since the code reviews and replies are really just comments on the diff, which is the intended purpose of the # comment

<comment><USER3> But the diffscuss modes parse the comments into functional structures--threads --to decide where to insert replies, etc., which is in fact functional--just not functional for the diff part.

Here's another way to think about it:

It sounds exciting to think that "all legal diffscuss files are also legal diff files!" In fact, very few diffscuss files will be used as diff files, and those that are can be trivially transformed.

It's not awesome on the other hand if "not all legal diff files are legal diffscuss files," which is where piggybacking on the diff comment syntax gets you, because every diffscuss file _starts its life_ as a pure diff file and there's no way to transform an offensive (but legal) diff file into a legal diffscuss file without data loss.

</comment></comment></comment></comment></comment><comment><USER6> Curious why you resorted to email diffs around instead of using pull requests on GitHub? It would be cool to see this integrated with the GitHub API so I could push out my comments to GitHub after editing.

<comment><USER3> Hey there, one of the diffscuss authors here.

We were working for a client who used self-hosted svn and had no code review system.

As for GitHub API: there's a (beta-ish) import from a pull request into a diffscuss file ("diffscuss github-import" for more), but currently nothing to push it back, which is a tricky problem (since what's displayed on a github pull request is actually a mixture of pull request comments and comments made directly on the commit diffs). But if there's sufficient interest we'll take a look!

<comment><USER6> If the tricky part is that comments are a picture of PR comments and diff comments, it seems like that would be more of a problem for import than export.

<comment><USER3> It's tricky to figure out where replies should go, especially if, e.g., there's multiple comments from different sources on the same line.

There's also the whole "what if there are comments from multiple authors to write back" problem, since you're presumably only going to have access to the API on behalf of one user.

I came away from the time I spent looking at this thinking that you'd probably be better off implementing a separate mode that talked more or less synchronously to GH as you replied etc., rather than working on an import / export cycle.

But there might be a better way.

</comment></comment></comment></comment><comment><USER7> This is a fantastic idea! I love it and I'm completely sold. If you manage to get Github to let you export diff comments as this format, you'll really have something there!

<comment><USER3> Hey, one of the authors of diffscuss here.

Just FYI, there's a "diffscuss github-import" command (which is beta-ish, but should work) that can import a pull request (or series of pull requests) into diffscuss format.

</comment></comment><comment><USER8> This looks promising. I'd love to see this integrated with gerrit and similar, to provide a two-way bridge between Gerrit change comments and email.</comment>


Debian GNU/Hurd 2017 released - <AUTHOR> https://lists.debian.org/debian-hurd/2017/06/msg00017.html <comment><USER2> How feasible would it be to have Duke Nukem Forever run on it (under Wine)?

(HURD and DNF have both been synonymous with vaporware for a long time, sometimes combined to "Yeah, X is going to be finished right after Duke Nukem forever runs on the Hurd". It would be a fun gag to make it happen.)

</comment><comment><USER3> I keep hoping GNU/HURD will eventually morph into something usable and compelling... but I've been hoping that for nigh on a dozen years already. Certainly progress is being made and this release is an impressive advance in several quarters, but unless it gets traction in some manner that compels corporate sponsors to contribute to a supersonic spurt in development, it seems destined to lag increasingly far behind other open source OSes such as Linux and the *BSDs. And that's a real pity, because a usable, well- implemented micro-kernel architecture widely deployed and supported would be something very much worth everybody's while.

<comment><USER4> I don't think the kernel itself, especially a micro kernel, is all that big of deal these days.

There are already plenty of decent Unix-style and other kernels out there, mostly relegated to academia and research.

Any of these would be decent enough to lay the foundations of a free stack.

The real problem is the APIs, services, and the hardware drivers.

The locked garden style of hardware and subscription models are becoming more and more prevalent.

And even using Debian or some other Linux doesn't amount to squat if you're using a back-doored Intel chip with its 'management engine', running a browser which is making it easy for 200 trackers to follow you on every site, and a smart phone, designed by an ad company, has turned you into a broadcasting station.

<comment><USER5> > There are already plenty of decent Unix-style and other kernels out there, > mostly relegated to academia and research.

The Hurd is the only multi-server microkernel system with a POSIX persona, though. The Hurd is a very flexible system, it just needs all those Linux developers to make progress more quickly.

</comment></comment></comment><comment><USER6> If you want to test the Hurd quickly, just run this:

        wget http://people.debian.org/~sthibault/hurd-i386/debian-hurd.img.tar.gz; tar xf de*hu*gz; qemu-system-x86_64 -net user,hostfwd=tcp:127.0.0.1:2222-:22 -net nic -m 1G -drive cache=writeback,file=$(ls de*hu*g)

or, if you want to stick to 140 chars in your commandlines:

        wget http://people.debian.org/~sthibault/hurd-i386/debian-hurd.img.tar.gz; tar xf de*hu*gz; qemu-system-x86_64 -hda de*hu*g -m 1G

(via [http://www.draketo.de/english/free-software/howto- hurd-140-c...](http://www.draketo.de/english/free-software/howto- hurd-140-chars) )

For official info, see [https://www.gnu.org/software/hurd/hurd/running/qemu.html#ind...](https://www.gnu.org/software/hurd/hurd/running/qemu.html#index1h2)

</comment><comment><USER7> Does anyone know if Hurd will ever be production worthy? Impressive progress nonetheless from what I understand. I know it must be difficult to get developers as there are so many people using Linux & BSD. Fuchsia is supposed to be a micro-kernel too right? I wonder if there could be a libre fork of that.

<comment><USER8> Speaking of microkernels, MINIX 3 is open source, unlike the version of MINIX that inspired Linus to write Linux.

MINIX 3, unlike earlier versions, aims to be used in production rather than being purely a research OS.

MINIX 3 has incorporated code from NetBSD making it possible to run a lot of software on MINIX 3 from the NetBSD ports collection.

I have not used MINIX but I remain interested in it and think it deserves a mention.

<comment><USER7> Thanks for the reply! I have one of Tanenbaum's old books. Perhaps time to read it.

</comment></comment></comment><comment><USER9> > It is now possible to run subhurds as unprivileged user, thus providing easy > lightweight virtualization.

That would be amazing to achieve on Linux. Unfortunately UML is not quite the same. I wonder if they'll ever get to the place where Hurd could be a coreos- like system with better isolation.

</comment><comment><USER10> At this point, is GNU/Hurd just for people who like to hack around with OS kernels?

I mean, it's interesting to see the progress now and then, but I can't imagine seeing it on anyone's short-list for OS's that could be deployed in a production environment.

</comment><comment><USER11> Obligatory XKCD link [https://xkcd.com/1508/](https://xkcd.com/1508/)

</comment><comment><USER12> Does Hurd use systemd?

Also, how's the performance? The last time I tried Hurd the performance was atrocious.

<comment><USER3> No, it has an _initialisation server_ (helpfully called _init_ ): [https://www.debian.org/ports/hurd/hurd-doc- server#init](https://www.debian.org/ports/hurd/hurd-doc-server#init)

I'm curious to know what made you wonder whether it did, and whether you would consider that a positive or a negative (and why).

<comment><USER13> No, it has an startup server (helpfully called startup), since 2015: [http://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/NEWS#n86](http://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/NEWS#n86)

<comment><USER3> I stand corrected. Apparently things have changed since I last used it. Apologies to all.</comment></comment></comment></comment>


What every developer should know about time - <AUTHOR> http://blogs.windwardreports.com/davidt/2009/11/what-every-developer-should-know-about-time.html <comment><USER2> I hate to be pedantic, but:

> .. UTC (also known as Greenwich Mean Time)...

> (Interesting note, UTC only matches the time in Greenwich during standard > time. When it is DST there, Greenwich and UTC are not identical.)

Time is really really hard, and I don't claim to understand it, but going lightly with basic facts is a bad idea.

First, GMT != UTC. UTC observes leap seconds, GMT don't. That doesn't matter, right up until when it suddently does matter.

Second, it's grossly confusing to talk about "Greenwich time", i.e. the time at the location, when you don't mean GMT. Neither UTC nor GMT observes DST, Britain, in which Greenwich is located, does.

<comment><USER3> If you have a good reference for leap seconds and platform implementations thereof I would love to read it.

<comment><USER2> Leap seconds aren't implemented, they're announced:

 _The International Earth Rotation and Reference Systems Service (IERS) announces the insertion of a leap second whenever the difference between UTC and UT1 approaches 0.6 s, to keep the difference between UTC and UT1 from exceeding 0.9 s._

<http://en.wikipedia.org/wiki/Leap_second>

UT1 is the astronomical time. So far, there are 24 leap seconds.

Also, I got it wrong: Leap seconds aren't the difference between GMT and UTC, but between UTC and e.g. GPS or International Atomic Time.

</comment></comment></comment><comment><USER4> I can't stress enough how important it is to get dates, times and timezones correct in your code to avoid embarrassment or worse. Just yesterday, just when we thought we'd ironed out all the timezone issues in our production code, our system rejected a bunch of customer data thinking the current time was actually an hour ahead of what it was. It turns out to be a bug in the Oracle JDBC driver that happens when connections are kept open while DST flips the clocks back but it goes to show that you can never be too careful when dealing with times and timezones.

<comment><USER5> And don't forget the Zune time bug which caused a bit of embarrassment for Microsoft last year/beginning of this year. It's hard to test every boundary and edge condition, especially if you are relying on black box testing to catch bugs.

</comment></comment><comment><USER6> Fun story regarding the UTC abbreviation: English speakers wanted it to be CUT (coordinated universal time), while French speakers wanted TUC (temps universel coordonné). They compromised on UTC.

[http://en.wikipedia.org/wiki/Coordinated_Universal_Time#Abbr...](http://en.wikipedia.org/wiki/Coordinated_Universal_Time#Abbreviation)

</comment><comment><USER7> Correct handling of dates and times in the general case (i.e, arbitrary time zones and arbitrary dates in the past, including calendar and time zone changes) is one of those things that I have tentatively filed under "too complicated for me to hope to get right", along with "correct handling of Unicode"[0] and "concurrency with fully shared mutable state"[1].

In practice, my rule is that if you can avoid dealing with the full complexity of date/time, such as by working in absolute time as much as possible and explicitly restricting the allowed date range, then do so; anywhere you have to work with dates/times as non-opaque values, always prefer library functions that _explicitly say they conceptually do what you want_ , not ones that provide low level operations that let you do what you want, probably, at least in your own locale, for now. If your platform provides only a broken date/time implementation, use a third-party library.

Fun anecdote time! When an international group pushed for a standardized, absolute time, the English and French both wanted it to be named in their own language, "coordinated universal time" vs. "temps universel coordonné". The compromise of UTC provided an "acronym" that, by design, didn't make sense to anyone, which I think is somewhat telling about the whole issue. The blog post here gives a good overview of fundamental difficulties, though doesn't really convey the true horror of the subject; I often suspect that a full and complete description of the proper handling for date/times can be found only in an appendix of the Necronomicon, serving as a final deathblow to any last scraps of the reader's sanity.

[0] cf. Michael Kaplan's MSDN blog for a glimpse at all the ways Unicode can go wrong. See how many entries you can read successively until starting to doubt whether written communication was ever actually a good idea! I think my personal record is 14 or so.

[1] cf. anyone who's ever tried. I don't think I need to justify this one.

</comment><comment><USER8> His suggestion that storing datetimes in UTC may be a problem is only half- correct. If you have access to an accurate historical record of rules for a given zone, then you _can_ always store UTC.

On Unixen, this data is typically stored somewhere like /usr/share/zoneinfo, and is called the zoneinfo or Olson database (Arthur David Olson is the original creator and maintainer of this database).

Using this database, you will always get the right conversion, even for datetimes that predate recent shift in DST rules.

OTOH, if you're on a crippled system that assumes the most recent rules extend indefinitely back in time, then storing data in UTC only will be problematic.

</comment><comment><USER9> Storing as localtime+timezone is asking for bugs since most people shift timezone twice a year. That makes testing a real problem.

Store times internally as UTC (time_t epoch is a good representation, or the DateTime object of your preference), convert as needed at the boundaries of your app for display/persistent storage purposes.

<comment><USER4> I think the article was trying to point out that it is not possible to use UTC for everything. If for example you store in your database an event to occur in the distant future (e.g. opening ceremony of the 2016 Olympics) in UTC, then the time that that represents can change as rules about timezones, leap seconds and daylight savings change.

Also there is the possibility that you actually want to store the timezone information at write-time, rather than assuming a timezone at read-time. For example if you have multiple records storing event times (say the working hours of all your global employees) then storing them only using UTC, you will not be able to retrieve the actual time in the timezone of each event individually. You can only assume a global timezone to apply to all events.

When storing localtime+timezone, do as the article recommends. Store the timezone, not the offset from UTC. Store "New York time" not EST or EDT.

<comment><USER9> > When storing localtime+timezone, do as the article recommends. Store the > timezone, not the offset from UTC. Store "New York time" not EST or EDT.

The problem is that that isn't well defined, as I point out here: <http://news.ycombinator.com/item?id=919407>

There are two UTC times corresponding to each moment from 00:00->01:00 25th Oct 2009 "London Time". There are no UTC times corresponding to 01:00->02:00 29th March 2009 "London Time".

> Also there is the possibility that you actually want to store the timezone > information at write-time, rather than assuming a timezone at read-time.

Whether a given time should be displayed in the viewer's localtime or another time is a display issue (I may want to switch between seeing my plane arrival time in localtime of the destination and localtime of my body clock). I don't think it should affect the internal storage format as without help from a strong type system (or some strong coding conventions) coders _will_ intermingle the two types and miss errors in testing either due to geographical proximity or lack of testing over daylight savings boundaries.

[All the above saud, the problem of changing DST parameters and future event times is problematic. I think it depends on what you want to be doing with such a time. Note that you'd have the opposite bug if you were storing pre- calculated sunrise time in various locales, so it's an issue of the semantic meaning of the timestamp.]

<comment><USER10> I've dealt with this quite a bit, and you're right- it's difficult to deal with the conceptual impedance mismatch between the concept of a time, and its discrete meaning in persistent storage.

I wrote a blog post about a month ago that talks about some issues surrounding the concept of "all-day" events which, by definition, are conceptually ambiguous.

<http://onehub.com/past/2009/9/28/the_joy_of_calendars/>

Ah, good times.

</comment></comment></comment></comment><comment><USER11> I've had more traumatic code errors due to times than I care to admit.

The bottom line: Learn from Unix. Store everything in epoch time (even if you're in Windows.) Do all your math in that. Showing local time is for display _only_. You won't ever regret it. (Well, hardly ever.)

<comment><USER12> And retire before 2038.

<comment><USER13> And retire before 2038 if you still define time_t as a 32 bit signed integer.

</comment></comment></comment><comment><USER14> Every programmer working with dates should read <http://naggum.no/lugm- time.html> \- "A Long Painful history of time". And also the Dave Olson paper referenced therein.

</comment><comment><USER15> Jon Udell had a very interesting article recently on a related topic: [http://blog.jonudell.net/2009/10/23/a-literary- appreciation-...](http://blog.jonudell.net/2009/10/23/a-literary-appreciation- of-the-olsonzoneinfotz-database/)

Jon's particular slant was reading the comments in the timezone database and reflecting on the political influences captured within. A fun read.

</comment><comment><USER16> Great article. The author suggests saving time in two formats, (1) UTC and (2) local date-time with a geographical time zone. The app would then pick the right one to use depending on context.

BTW, let me take the opportunity to praise the Joda Time library for JVM languages. First time I've ever seen date and time primitives implemented well. It can be used for the scheme suggested in the article.

<comment><USER9> > (2) local date-time with a geographical time zone.

Note that timezones aren't just geographical. In London, you'll be in timezone GMT (+0000) for half the year and timezone BST (+0100) for half the year.

If you think instead that you're in a single timezone, then you need to know that your "timezone" isn't linear, it contained 00:00->01:00 twice on 25th October 2009 this year (when the clocks go back).

So "what was the UTC time for 00:30 on 25th October 2009 in London" isn't a question with a well-defined (or unique) answer.

<comment><USER17> > Note that timezones aren't just geographical. In London, you'll be in > timezone GMT (+0000) for half the year and timezone BST (+0100) for half the > year.

You're comparing apples and oranges. There are two different concepts here: 1) the name of a UTC offset for a given period of time in a given region i.e. BST. 2) the geographic area that has a set of rules about when to change the UTC offset.

In the US, we call #1 "Central Standard Time or Central Daylight Time" and #2 "Central Time". #1 means "UTC -6", and #2 means "convert UTC according to whatever the current rule is".

The author's point is to store local time + concept #2.

EDIT: ok, I see what you mean. If the user types in "send me a reminder at 12:30 Oct 25 London time, you don't know whether they're talking about pre- DST, or post-DST. Interesting.

</comment></comment></comment><comment><USER18> Perfect article. Short and to the point, and even though it's something I've thought about before, I learned something new.

</comment><comment><USER19> So, if I asked you to meet me for coffee at 5:00 PM EST, and I showed up when my watch said 5:00, I would be an hour early, b/c we're in DST right now.

I though that was interesting, b/c I will put EST in an email to people in another timezone, just thinking it means "Eastern Time Zone" or something like that.</comment>


Pete Buttigieg debuts a radical new approach to campaign branding - <AUTHOR> https://www.fastcompany.com/90334160/pete-buttigieg-debuts-a-radical-new-approach-to-campaign <comment><USER2> So Pete gives us a social-issues platform and a game of design to play.

Can we get some economic policy ideas? Or are we gonna pretend those dont exist again

</comment><comment><USER3> Yangs fans did it themselves.</comment>


Rails - Simple Asynchronous Processing - <AUTHOR> http://cfis.savagexi.com/articles/2008/06/16/rails-super-simple-asynchronous-processing <comment><USER2> Is anyone else using BackgroundRb? (<http://backgroundrb.rubyforge.org/>).

<comment><USER3> I use BackgrounDRb in a couple of apps because it's easy and quick to set up. When I need to scale it up or route jobs to systems that may not be Ruby based, I go with ActiveMessaging connected to ActiveMQ. ActiveMessaging supports a lot of broker types through StompConnect.

The solution outlined in this article looks a bit simpler, though, so it probably worth tinkering with.

</comment></comment><comment><AUTHOR> This seems like a good starting point to do research into multi-shard queries with Data Fabric.</comment>


Why you should never, ever, ever use fibonacci for benchmarking - <AUTHOR> http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.53.4124

<comment><USER2> But fib is a great benchmark for blog posts. You can write a naive implementation in your least-favorite language, and write a simple iterative implementation in your favorite language, and your favorite language will always win! And that's the most important part of benchmarking, who wins!

Edit: did anyone replying to this post (other than dons) actually read the linked paper?

<comment><AUTHOR> Indeed, no other benchmark is:

* so accessible to the naive -- anyone can understand fib!

* has so many ways to implement it -- each in different complexity classes!

* is so perfect for language pissing contests on the intertubes.

Endless fun!

A much better idea is to contribute programs to the Great Shootout, [http://shootout.alioth.debian.org/u64/benchmark.php?test=all...](http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=all)

<comment><USER3> fib _does_ present an interesting problem. Any language worth its weight should be able to express the problem in such a way that it can perform

      1) quickly,
      2) iteratively (tail-recursion)
      3) succinctly.

Not _that_ many languages can do that.

<comment><USER2> Tail recursion for two recursive steps per invocation? I don't think so.

(Hint: the "naive" implementation of fib that I refer to above is "fib (x + 1) = fib x + fib (x - 1)".)

<comment><USER3> What are you saying exactly? That fib shouldn't be defined in terms of tail recursion? Of course it doesn't have to be. But it's also the moment that you realize that for loops are entirely unnecessary and broken since they aren't composable the way functions are.

<comment><USER2> Iteration and tail recursion are orthogonal. Yes, you can implement iteration in terms of function application. But no, the results of benchmarking "fib" won't make your favorite version win.

</comment></comment></comment></comment></comment></comment><comment><USER4> I came to HN because CiteSeer is down and I couldn't get work done. Then I see CiteSeer on the front page of HN: my mistress killed my wife :-(

<comment><USER5> Watch it, buddy. Your mistress _is_ your wife (in VR gear), and she's out to nail your two-timing butt.

(Short-story plot by Jeffrey Archer, in an old paperback I absentmindedly read a while ago.)

</comment></comment><comment><USER6> I have read the paper before, and it's certainly right -- but Gabriel never claimed that the fib benchmark was anything other than a microbenchmark of certain aspects of a system.

For example, when discussing the TAK microbenchmark, he says:

> When called on the above arguments, TAK makes 63,609 function calls and > performs 47,706 subtractions by 1. The result of the function is 7. The > depth of recursion is never greater than 18. No garbage collection takes > place in the MacLisp version of this function because small fixnums are > used.

(See <http://www.dreamsongs.com/Files/Timrep.pdf>)

With such a precise description of what the benchmark tests, it's obvious (a) that it's a microbenchmark, but also (b) that it does indicate the speed of certain combinations of operations.

So I don't think that the title of this article is actually the takeaway message from that paper. Microbenchmarks like the Gabriel benchmarks are around for a reason.

</comment><comment><USER7> I just made a similar complaint over at Reddit. Maybe interesting, maybe not. [http://www.reddit.com/r/programming/comments/b5v64/tired_of_...](http://www.reddit.com/r/programming/comments/b5v64/tired_of_people_comparing_languages_by_doing/)

</comment><comment><USER8> The real reason why it's such a poor example is that it's contrived. If you honestly wanted to determine arbitrary elements from the Fibonacci series you would calculate them using a closed form expression that runs in O(1) (wiki Fibonacci sequence for examples).

Similarly, factorial is often a poor example problem because it's almost always completely unnecessary to tweak the performance of any algorithm for real world inputs. 13! is larger than an unsigned 32-bit int can hold, and 21! is larger than an unsigned 64-bit int can hold. The amount of performance gain you'd get from shaving down a loop or recursive call that ran at most 20 times is inconsequential in the vast majority of cases. Indeed, a simple recursive or iterative method is probably more efficient than even a lookup table method in most cases.

As example problems to see how people think through issues of iteration vs. recursion, efficiency, and performance these are ok problems but as real-world benchmarks for any kind of coding style they are terribly artificial.

<comment><USER7> The closed form solution isn't O(1). It's Ω(2^N) since the number of digits in the output is Θ(2^N).

<comment><USER8> On the most prevalent electronic computers of our time the closed form solution is effectively constant-time if the output is bounded to be within the limits of a 32 or 64 bit integer.</comment></comment></comment>


Will Bitcoin Save Us from Google? - <AUTHOR> https://www.wsj.com/articles/will-bitcoin-save-us-from-google-1531680720 <comment><USER2> Bitcoin won't do jack. It's unsustainable for any remotely common use purely due to energy consumption, the network using more electricity in a given period than some first-world countries while handling a small fraction of the transactions a network like Visa handles.</comment>


How MIT Can Honor Aaron Swartz - <AUTHOR> http://www.slate.com/articles/technology/technology/2013/01/aaron_swartz_jstor_mit_can_honor_the_internet_activist_by_fighting_to_make.html <comment><USER2> They can change the MIT license to Aaron Swartz License to honour his work.</comment>


Show HN: Startup Sticker Packs - <AUTHOR> http://startupstickerpack.com/ <comment><USER2> You can get a sickermule sample pack for $1: [http://www.stickermule.com/products/sample- pack](http://www.stickermule.com/products/sample-pack)

<comment><AUTHOR> Yeah, they do that because it will presumably lead to business. With that said, I agree that the price was too high and I lowered it to $5.

</comment></comment><comment><AUTHOR> I'm around to answer any questions.</comment>


Why I'm Productive in Clojure - <AUTHOR> http://yogthos.net/blog/49-Why+I%27m+Productive+in+Clojure <comment> dj-wonk > What matters to me in a language is whether I can use it without thinking > about it.

I love this statement. It reminds me of the what it feels to be good at mathematics (not my words): "Your intuitive thinking about a problem is productive and usefully structured, wasting little time on being aimlessly puzzled." from [http://www.quora.com/Mathematics/What-is-it-like-to- understa...](http://www.quora.com/Mathematics/What-is-it-like-to-understand- advanced-mathematics)

The author also says more about mathematics:

> To make an analogy with math, it's nicer to have a general formula that you > can derive others from than having to memorize a whole bunch of formulas for > specific problems.

> This is where Clojure comes in. With it I can always easily derive a > solution to a particular problem from a small set of general patterns. The > number of things I have to keep in my head is not overbearing.

Any language that lets you spend your brainpower on the essence of the problem is a tremendous advantage and joy. This unlocks creativity and productivity.

<comment><USER2> > Any language that lets you spend your brainpower on the essence of the > problem is a tremendous advantage and joy. This unlocks creativity and > productivity.

For some reason the only language that let me reach this level is Python. I tried Clojure and Common Lisp, but for some reason I could never be as efficient as I wanted with them, which I think is a shame because in some ways I think the Lisps are superior to Python (due to the "code is data and data is code" of Lisp).

<comment><USER3> I use Clojure a lot, and did more Python in the past. Whenever I come back to Python, I am frustrated by being unable to remember what's a plain old function and what's a method, and the differences defining functions vs classes and methods etc..

In Clojure I know it's always (except for interop) just functions on values. Some functions dispatch to an implementation based on the type of the value, as is the case with multimethods and protocols, but it's still always just function calls from my point of view while writing the code.

<comment><USER4> In general, Python method is just combination of function object and pointer to "self" namespace.

<comment><USER5> I'd like to know if it's done differently in other languages. In my view, methods are curried function over self with a '.' syntactic shortcut.

<comment><USER6> Lua does not do the currying bit, but it does a lot less OOP and a lot more "dictionaries with stuff that can do something like prototype OOP if you squint hard enough". Java and whatnot just don't let you really use methods as first class citizens, so it doesn't matter.

<comment><USER5> IIRC under the hood Java will 'evaluate' the methods body as a sophisticated function with 'this' in its environment.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> I recently migrated to clojure from the php world. I have to say that although I am still learning the language, its actually fun compared to php, which would sometimes feel like pulling teeth to get some basic functionality. Way less boilerplate, and as can be said of anything good, it just works.

Also, the idea of thinking in the problem domain versus the subset of problems that arise in languages like php is an acute difference. Just being able to focus on the product as your programming keeps you on task and thinking about new ways to implement features, etc. -- big difference.

<comment><USER8> I made a career move from dentistry to programming. And I would say that anything I've used pre-clojure is a good approximation of pulling teeth. But even pulling teeth has the benefits of knowing when you're finished and the direct customer feedback is usually good.

<comment><USER9> Why did you decide to switch from dentistry?

<comment><USER8> An intellectual, emotional disaster.

I'd been programming since a child and I think in all honesty I was pushed into dentistry by the people that love me and wanted me to make money.

However dentistry in London is medicine in two years then three years specialising in the head and neck. Then two years dentistry training.

I found it a LOT of learning facts. I know that knowledge-based systems are better than humans for that application.

I had the pleasure of learning human anatomy for two years with Prof Harrold Ellis. Which is what I really took away with me. The guy was a genius. And the other was "If you are not certain then say I don't know, never guess, always seek truth" not that many people appreciate that knowledge in my experience. Robotic surgery yes, lying about the safety of amalgamate fillings no and telling mums of the effects of sugar and carbonic acid drinks was not enough scientific exploration for me.

I think I was too young, always the youngest in my year, to really know and show what I wanted to do. I should have studied Physics but was told at the time "I'd end up a Physics teacher" as if this was a bad thing...

Pre-uni I wanted to build quantum computers but my Physics teacher at St John Ruskin College school didn't know what direction I should head in (the school at the time was also being ripped off by the head mistress, look it up, bad).

After that I got a scholarship to a private school to do A levels which was absolutely brilliant. Dulwich College an excellent school where I was treated like an adult and learnt maths, physics and chemistry. Two of the best years of my life.

Nobody noticed really that I wasn't just lazy and so it was very tempting to my parents to be told I could go to the best medical school etc when I pissed the exams.

So I went to the best medical school in the UK, Europe not really sure why.

After two years depression forced me to take some action and I quit and got a job in a bank as a COBOL programmer. I learnt that COBOL doesn't cure depression but can even make it worse. However I learnt from two old ladies who were probably employed AS computers in their prime. And they were the awesome COBOL dinosaurs.

From there on its always been a bit of struggle not having a degree. Although what I've taught myself, and continue to do so, is worth several degrees at least. Probably a PhD or two.

I now know a lot of programming languages and have lots of experience in them. Clojure took me to the next level with regards to meta-programming and language design. I still have hopes for genetic programming.

My interests now are really into augmented reality and basically augmentation of human perception, memory and "brain power" both in the progression of our species and knowledge itself.

If you really want to know where my head is at read The Beginnings of Infinity by David Deutsch [http://en.m.wikipedia.org/wiki/David_Deutsch](http://en.m.wikipedia.org/wiki/David_Deutsch).

He has interesting ideas on quantum computing, knowledge and reality which align most closely with my own.

I'm now mostly a "Senior Developer". How about you?

<comment><USER9> Have you had any "portfolio" projects? That is, projects you can showcase? This goes a long way towards the lack of degree.

My story is too long to put into text, but the short of it is that I can relate to a lot of what you went through.

<comment><USER8> That's another issue too. If it's not a public website that you're building it's quite hard to show off your work!

One of my favourites was a forward-chaining rules inference engine written in T-SQL on MS SQL Server for a sixth-form college. The Management Information System (MIS) was called unit-e built by Capita PLC and probably cost a LOT of money.

It was quite a good system, the query builder for advanced users was excellent (every MIS should have one), but it had a fair amount of data duplication - names, addresses, previous address etc. And the admin staff had lots of name changes and spelling corrections to make. Also you had the data entry dudes who'd write a lazy name like fiesta try basharat instead of Fiesta Try Basharat.

So I built the rules-engine as a stored procedure (SPROC) called by triggers on tables. The rules themselves were just simple SPROCs and some not so simple but the rule interface was simple and so the system was robust. All of a sudden every letter sent by the school was formatted properly and went to the correct address! The admin team even gave me and my junior a present! And the 'junior' became an expert in SQL and learnt a secret ninja weapon (rules, inference engines and conflict resolution).

How many good things were created? How do you demo the transition of knowledge? How do you monetize the time saved? How do you portfolio the potential for benefit of new rules that haven't been thought of yet?

Expansion of knowledge, the beginnings of infinities, there's so much out there I love it!

</comment></comment></comment></comment></comment></comment><comment><USER10> My biggest problem with Clojure (specifically ClojureScript) is that it's too workflow opinionated. Nearly all Clojure devs use 1 of 2 text editors. Nearly everyone uses Leiningen. Nearly everyone uses some sort of auto-builder. Nearly everyone uses hot-swapping.

Clojure wasn't even optimized for this workflow, it's just the only one that works. So as much as I love the language I keep going away from it because I prefer the freedom of my own workflow.

<comment><USER11> Well, people do use these tools, but honestly, do you really want a language with multiple build tools / package managers? The java world is a mess here. Leiningen is pretty great, no need to fragment the community.

As far as editors go, I'm perplexed. You can use nearly any editor, why do you perceive the need to use one of these 2?

<comment><USER10> > Well, people do use these tools, but honestly, do you really want a language > with multiple build tools / package managers?

I want multiple _workflows_. A single build tool can accommodate that, but Leiningen can't/doesn't.

For example, let's say I have a compiler called mycc. I can build something like this:

        mycc main.c -o main

I might then combine it with an file watcher utility like entr

        find . -name '*.c' | entr mycc main.c -o main

With Leiningen it has to do that all. AND you pretty much have to use the auto rebuilder capability (which means your workflow starts with turning the auto rebuilder on).

> As far as editors go, I'm perplexed. You can use nearly any editor, why do > you perceive the need to use one of these 2?

Then why do nearly all (probably 95%) Clojure devs use either Emacs or LightTable?

<comment><USER12> Right now I'm using a combination of leiningen, guard, livereload, compass and a shell script to handle my specific build workflow.

I'm confused as to why you think leiningen has to do it all.

I'm also not sure what you mean by auto rebuilder (for _clojurescript_ I use the auto feature of cljsbuild ...). My workflow starts with starting a REPL.

Also, I use vim very happily, many people use Cursive happily. But the reason there seem to be fewer editors in use is that REPL integration is so useful that only those editors with good REPL features end up being used. Clojure's ecosystem isn't stopping anyone from using other editors, those editors just haven't implemented a specific feature that is extraordinarily useful when writing Clojure.

I may have misunderstood you but it seems like you are seeing problems that don't exist because the solutions look different than what you expect.

<comment><USER10> I think you are misunderstanding. People have shown in this thread that they have a slightly different workflow from each other, but my point was that Clojure(Script) points you towards a particular type of workflow, one that I do not like. What I essentially want is 1 of three things:

1) Fast builds so I can set up an auto-build script.

2) A Leinengen daemon so I don't have to worry about building at all.

3) ClojureScript so I can just refresh the browser.

As far as I can tell none of these are possible. If I am wrong please correct me.

<comment><USER12> You can certainly get all of that stuff (except fast builds in some particular circumstances).

My project I described before is a web app, and my workflow involves my editor, a browser, a clojure repl, a clojurescript browser repl that runs code in the browser and a shell script that runs the various watchers I described before.

If I change any clojure file the browser refreshes automatically (and my tests run automatically).

If I change any clojurescript file it gets rebuilt automatically and the js file is reloaded in the browser (just the js, not a full page refresh)

If I change any sass file, it gets rebuild and the css in the browser refreshes (just the css)

If I change any html template then, depending on the template, either the page is refreshed or my clojurescript is rebuilt and the js refreshed.

So all those things are possible (I saw a cool post the other day of some ring middleware to handle using clojurescript inside <script> tags transparently).

The non-clojure stuff is handled completely outside of the clojure ecosystem, I was using LiveReload and Guard when doing python dev to get that partial refresh on file save functionality and it was pretty simple to hook clojure into that same workflow.

I will say that if you are doing a lot of compile time template processing in your clojurescript like I am (using Kioo/Om/React.js) then the compile time for the clojurescript can be a little long, but since I have a browser REPL I do my experimental stuff in there instead of hitting that recompile cycle frequently so it's only a minor imperfection in practice.

So I definitely don't worry about building at all, and I don't even have to refresh my browser thanks to LiveReload - I just have to hit save in my editor.

There unfortunately aren't a lot of tutorials for setting this kind of thing up. I've got a start on writing up my setup and will put the project skeleton on github soon-ish ... I have this damn real work that keeps getting in the way.

</comment></comment></comment></comment></comment></comment><comment><USER13> REPL-driven development is wonderful. I'm not a Clojure user (yet), but I write a lot of Scheme. My programs are living creatures that adapt and evolve as they are running. It's refreshing to see that Clojure is seeing real use in the industry. Gives me hope that I can get paid to work with a language I really enjoy some day.

<comment><USER14> I'm a bit curious about your comment. Do you mean during development you run your code on a REPL and change portions of it , or do you mean you run code in Production in a REPL and change portions of it as it's running?

I'm interested to know your setup in either of those cases. The one inconvenience I have about REPL based development is that I need to copy over an expression from my editor into the REPL and if I make any changes in the REPL, like fix a typo, I need to make sure to copy it back to my editor.I guess this may be because I don't use Emacs and have an editor and REPL in one.

<comment><USER8> REPL Driven development as it's called is really yes having your whole system running at your thingertips (even production for the adventurous). You can execute arbitrary code and get results or see what state has changed. You can also redefine anything (in Clojure at least) that is referred to, such as functions and variables (I use these terms loosely here).

Normally you have your IDE configured so that anything executed is executed in the context of the running REPL session. So there should be no need to copy/paste.

When done properly with tests running on every change you really can't, as a developer, get any quicker feedback. It's brilliant and empowering!

Your issue could be emacs but, for Clojure at least, there is the Cursive Intellij plugin which is now definitely usable. Also there are the brand new IDEs like LightTable.

LightTable.com started out with some very different ideas with regards to code organisation and there is still a lot of potential work there. But lighttable instead became open source and a core for plugins. The plugins now range from rainbow parentheses to 'pick your language' evaluation.

If you want to discuss any of these ideas or others please do or PM me. I'm always willing to discuss as my girlfriend is hopeless. But then for everything not programming she keeps me sane.

</comment></comment></comment><comment><USER15> I'm curious to see how Clojure fares against the current crop of folks becoming intrigued by statically-typed languages like Haskell, F#, etc.

<comment><USER16> I'm a strong static-typing advocate, and for years this has put me off learning Clojure. (In fact, my very first HN submission, back in 2010, was about Clojure: [https://news.ycombinator.com/item?id=1453259](https://news.ycombinator.com/item?id=1453259)). I've been coding exclusively in Clojure for the last month however, and I found it extremely enjoyable to use. Much easier to learn than Haskell, for example, because Clojure isn't purely functional.

The key of Clojure is that it's _pragmatic_ , as opposed to dogmatic. It's a language designed to solve real-world problems in production environments (hence the focus on concurrency, for example).

Also, being a lisp, it's a "programmable programming language", and once you realize the power that that gives you, it's hard not to fall in love with it.

<comment><USER17> >'s a language designed to solve real-world problems in production environments (hence the focus on concurrency, for example).

It would be nice to see example(s) of clojure solving real world concurrency problems.

<comment><USER18> I learned Clojure from the book Clojure Programming ([http://smile.amazon.com/Clojure-Programming-Chas- Emerick/dp/...](http://smile.amazon.com/Clojure-Programming-Chas- Emerick/dp/1449394701/)). Once the book gets past the basics, it starts giving lots of concrete examples for how to solve real problems idiomatically in Clojure.

<comment><USER17> Yea but I am looking for actually field reports from people solving hard concurrency problems out in the wild with Clojure. I am yet to see one.

<comment><USER19> Storm ([https://storm.incubator.apache.org/](https://storm.incubator.apache.org/)) is a great example of Clojure used to solve concurrency problems in the wild.

<comment><USER17> Sorry pardon my ignorance but that seems like parallization not concurrency. I would like examples of things like pmap being used in the wild.

<comment><USER19> Well, p in pmap does stand for parallel. :) The two are obviously linked, Storm does both parallel and concurrent processing on the data. Another example is PigPen ([http://techblog.netflix.com/2014/01/introducing-pigpen- map-r...](http://techblog.netflix.com/2014/01/introducing-pigpen-map-reduce- for.html)) from Netflix. As far as pure concurrency goes, I'm not sure any companies have articles discussing that.

<comment><USER17> Ok thank you. Implementing map reduce style parallzation doesn't need any language level support. I don't see how clojure is any better at this than say java ( hadoop is java after all).

I am looking for 'pure concurrency' in a app like videos games exctracting last ounce of processing power from a multicore machine. This what the original comment stated was the core competence of Clojure.

<comment><USER19> >I am looking for 'pure concurrency' in a app like videos games exctracting last ounce of processing power from a multicore machine. This what the original comment stated was the core competence of Clojure.

That's not actually what the parent comment stated though. It says that Clojure is designed to solve real-world problems in production environments.

In many cases this doesn't mean squeezing out the last ounce of processing power, but being able to reason about concurrent code safely. You pay an overhead of using immutability in order to facilitate higher correctness.

When your system grows it becomes important to be able to reason about parts of it in isolation. This is particularly important when you're running in a multithreaded environment.

That's what people generally mean when they say that Clojure has focus on concurrency. Since the data is immutable you can make assumptions about what the code is doing that you wouldn't be able to make otherwise.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER20> Being popular on HN is not the best thing for Webservers...

<comment><USER19> It certainly isn't, my poor server went catatonic under the relentless onslaught. :)</comment></comment>


Finally, Farm Tools For Her - <AUTHOR> http://modernfarmer.com/2014/07/finally-farm-tools/ <comment><USER2> As a man who maintains an acre of yard/garden + chickens, that shovel looks pretty nice. Better leverage/ergonomics.

Not sure about the tiller though, in my experience the weight of the tiller makes a big difference into how well it digs in. I'd be happy to be wrong, but it's personally a moot point for me, as my old JD tiller from the 70's still runs perfectly. I do like the "no vibration" handle though...just need to figure out how to hack it together for my own digger.

</comment><comment><USER3> why make it a sexist argument?

its like this comic [http://okcancel.com/comic/3.html](http://okcancel.com/comic/3.html)

it makes a nice point, but why put a girl there? don't all the nerds lack upperbody strength?

<comment><USER4> No off-topic flamewar tangents, please. If Hacker News can have a civilized discussion about women's underwear without going haywire, I hope it can discuss women's farm tools.</comment></comment>


DalmatinerDB: A fast, distributed metric store - <AUTHOR> https://dalmatiner.io/ <comment><USER2> When would you want to use something like this over just ordinary postgresql?

Say you're trying to measure/analyze the use of a feature like clicking a button. You want to record every time a user clicks the button, their user ID, and some attributes of the user (maybe in bucket A or bucket B of a test). Later you'd want to be able to answer questions like "how many times was this button pressed?" or "how many unique users pressed a button?" or "how many times did users in bucket A press the button?".

Is that an "appropriate" use for postgres? Or is that the kind of "metrics" that a DB like Dalmatiner would be more optimized for? Is there a nice overview of the various kinds of DBs out there and what use cases they're optimized for?

<comment><USER3> The situation you describe is more an event then it is an metric, and indeed postgres is much better suited for it, if asked that is what I'd recommend for this kind of issue.

What DalmatinerDB was build of is handling high numbers of metrics like CPU usage, memory usage, etc, everything where for every point in time you have exactly 1 value. In that space it can handle millions of metrics (read millions of inserts) at the same time where a system like postgres would stat to have problems in my experience.

<comment><USER4> I wouldn't use postgres for that at all! A NoSQL store is much better suited for that task.

<comment><USER5> There is not suck thing as "NoSQL store". NoSQL is just a buzzword that is used to describe dozens (hundreds?) of _very_ different solutions.

<comment><USER4> You are being obtuse. It is obvious what I'm talking about.

<comment><USER6> No, I don't think it's obvious nor are you right about this.

<comment><USER4> Look at every mobile gaming company and you will see document stores. Dynamo, BigTable, DocumentDB. Google's very own analytics is built on BigTable. The examples are countless.

<comment><USER6> Neither Dynamo nor BigTable are document stores.

And there is no reason why Postgres couldn't handle this kind of stuff. Sure it doesn't come with the needed scaling tools built in but it's doable. I'm running billions of rows through a Postgres analytics setup.

A purpose built system can be more efficient but it also doesn't need to mean NoSQL. You can see some of the serious-scale datastores adopting SQL-like query interfaces. For example Hive for Hadoop or PlyQL for Druid.

NoSQL is a loose term for a mish-mash of technologies.

<comment><USER4> Dynamo started as a document store. Bigtable is not but I included it because it is another very good option for analytics and is still lumped under the nosql umbrella.

Using relational database for event analytics means that you have a trivial use case. You might have a lot of rows, but your data is dead simple. Otherwise you would refactor every week to change the schema and sharding. Not to mention how much money you would spend on hardware.

<comment><USER6> > Dynamo started as a document store

No it didn't. The original Dynamo paper doesn't even include the word "document" once! The title of the paper makes it obvious what kind of system it is: "Dynamo: Amazon's Highly Available Key-value Store"

You should really do some fact checking on your statements.

Bigtable alone does not make an analytics system. You'll need a lot more around that.

I don't have a trivial use case. We use the jsonb data type in Postgres and have no upfront defined schema for metrics.

Postgres' jsonb can out-perform many of the open source NoSQL databases out there. Our system consists of a single digit of nodes that can handle hundreds of thousands of writes per second and as I mentioned already, billions of rows. A single CPU core can scan though more than a million rows per second. Is it the fastest that there is? No. Is it good enough for most people? Absolutely.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> Nomenclature nitpick: This is more clearly called a time series database.

A "metric" doesn't imply multiple samples over time (although researching for this comment, there doesn't seem to be a strict definition)

<comment><USER8> Yeah, what is a "metric"? Does that mean a "number"?

<comment><USER9> [http://blog.lusis.org/blog/2011/07/21/monitoring-sucks- watch...](http://blog.lusis.org/blog/2011/07/21/monitoring-sucks-watch-your- language/)

</comment></comment></comment><comment><USER10> Wow, saw the benchmarks:

[https://docs.dalmatiner.io/en/latest/benchmarks/jpc.html](https://docs.dalmatiner.io/en/latest/benchmarks/jpc.html)

"8,500,000 and 9,000,000 metrics per second" on a 5 node cluster.

This is impressive.

The 1 node is impressive as well (and it shows how it scales):

1,500,000 metrics per second

<comment><USER11> They are impressive, but let's put some context:

      No guarantee of storage

      DalmatinerDB offers a 'best effort' on storing
      the metrics, the ingress transport is UDP and
      there is no log for writes (there is the ZIL if
      enabled in ZFS) or forced sync after each write.
      This means that if your network fails packets can
      get lost, if your server crashes unwritten
      data can be lost.

[1] [https://github.com/dalmatinerdb/dalmatinerdb#no-guarantee- of...](https://github.com/dalmatinerdb/dalmatinerdb#no-guarantee-of-storage)

<comment><USER3> Actually let me put that paragraph fully in context with the reality.

UDP is no longer used (this is outdated sorry for that), the connection is TCP now as it turned out over all the performance was better.

Dataloss can still occur since DalmatinerDB keeps a cache (which other metric stores might also do). A lot of that can be mitigated by using N=2 (or 3) to store data in multiple nodes that will reduce the chance of dataloss significantly. Keeping caches isn't uncommon however, to ensure full consistency it requires a kind of transaction from that goes from client to server to client, which is 'really' costly and I am convinced not worth it for metrics, a few seconds of lost metrics doesn't warrant the cost of that.

</comment></comment></comment><comment><USER12> Some more info here:

[https://dataloopio.wordpress.com/2016/03/21/playing-with- dal...](https://dataloopio.wordpress.com/2016/03/21/playing-with-dalmatiner- db/)

</comment><comment><USER13> Another exciting and related project is Tachyon, which allows for rapid collection and sending of metrics to Dalmatiner.

[https://docs.project-fifo.net/docs/tachyon](https://docs.project- fifo.net/docs/tachyon)

</comment><comment><USER14> If you are interested in storing time series, check out [http://chronix.io/](http://chronix.io/).

A colleague of mine is working on his PhD about time series storage and created it.

</comment><comment><USER15> I see there's a Python client -- which looks fairly straightforward. I'd like to offer a ruby client, but would prefer not to duplicate an effort already underway.

What's the status of an official Ruby client?

<comment><USER16> Go write a ruby client.

</comment></comment><comment><USER17> Could somebody explain this?

"No guarantee of storage. DalmatinerDB offers a 'best effort' on storing the metrics"

[https://github.com/dalmatinerdb/dalmatinerdb#no-guarantee- of...](https://github.com/dalmatinerdb/dalmatinerdb#no-guarantee-of-storage)

<comment><USER18> it means the transport is UDP and there's no ack on write

</comment></comment><comment><USER19> There's a lot of overhead from disk seeks that plague a lot of traditional databases. Especially if you have a physical arm moving around. Any database like this that can write data sequentially and forgo update and delete operations can really speed things up. Also at scale you start worrying about things like storage costs. Sequential reads/writes make it reasonable to use spinning disks for the cost savings as SSDs cost more and lose their order-of- magnitude advantage when comparing sequential writes.

</comment><comment><USER20> Tying itself to a technology that faces some legal challenges (ZFS) doesn't look like a good thing [1]. I understand the benefits of avoiding duplicating features that are already present in the ZFS layer, but it's a roadblock today and in the foreseeable future.

1 - [https://news.ycombinator.com/item?id=11176107](https://news.ycombinator.com/item?id=11176107)

<comment><USER21> That's the case if you were going to deploy this on Linux. The packages provided are for SmartOS.

</comment></comment><comment><USER22> The docs strongly recommend running on ZFS. What is the current state of ZFS for linux? Is it common in production today?

<comment><USER12> I know quite a few companies running ZFSOL in production. In terms of our own experiences I blogged about them here: [https://dataloopio.wordpress.com/2016/03/07/zfs-on- linux/](https://dataloopio.wordpress.com/2016/03/07/zfs-on-linux/)

</comment></comment><comment><USER23> Yes! Oh sweet wonderful gift from the Gods! I can't wait to dig around in the KV data model for this.

<comment><USER23> Ah, this is based on Riak Core, not Riak KV as is suggested by the Wordpress blog post announcing DalmatinerDB.

That actually makes me even happier. :-)

<comment><USER3> The storage engine is a separate library, it might be of interest for you: [https://github.com/dalmatinerdb/mstore](https://github.com/dalmatinerdb/mstore)

<comment><USER23> So much so that I'd already been poking around there. :-)

I like to see new riak_core applications being made. For the most part it's a pretty clean framework to bootstrap something with.

I have a current particular interest in riak_core over the top of a pile of disk_log because I want something Kafka shaped, but where topics are cheap, and sloppy-leader-esque behavior is the default without destroying data. Optimizing for availability over everything else and guaranteed delivery of all ACK'd messages put into the system if the end of all logs have been reached (via continuation).

</comment></comment></comment></comment><comment><USER24> Here is a great video talking about the decisions made when designing DalmatinerDB - [https://vimeo.com/148514080](https://vimeo.com/148514080)

</comment><comment><USER10> Very nice. I like how it delegates some of the stuff to the filesystem (compression, checksumming).

</comment><comment><USER25> Looks great! ..I like the fact its built on top of proven technology like ZFS and Riak core.

</comment><comment><USER26> Is this an alternate spelling of "Dalmatian" I'm not aware of?

<comment><USER7> It's German for Dalmatian.

</comment></comment><comment><USER27> Good dog. 101 Dalmatians.</comment>


Show HN: Create a new social network website for $5 - <AUTHOR> https://www.socialpage.org <comment><USER2> This is a prime example of what I don't like about a lot of hosting companies. Offer to do all of the techy stuff and just give the user a junky prefab "social" network.</comment>