From Kafka to ZeroMQ for real-time log aggregation - <AUTHOR> https://tomasz.janczuk.org/2015/09/from-kafka-to-zeromq-for-log-aggregation.html?term=12 <comment><USER2> I used to be on a team responsible for a single small-ish Kafka cluster (between 6-12 nodes) doing non-trivial throughput on bare metal. Without commenting on whether ZeroMQ is the right alternative: I can understand being scared off. Our hand was forced such that we had to go the other way and understand what was going on in Kafka.

The kicker is that Kafka can be rock solid in terms of handling massive throughput and reliability when the wheels are well greased, but there are a lot of largely undocumented lessons to learn along the way RE: configuration and certain surprising behavior that can arise at scale (such as [https://issues.apache.org/jira/browse/KAFKA-2063](https://issues.apache.org/jira/browse/KAFKA-2063), which our team ran into maybe a year ago & is only being fixed now).

Symptoms of these issues can cause additional knock-on effects with respect to things like leader election (we wound up with a "zombie leader" in our cluster that caused all sorts of bizarre problems) and graceful shutdowns.

Add to that the fact the software is still very much under active development (sporadic partition replica drops after an upgrade from 0.8.1 to 0.8.2; we had to apply some small but crucial patches from Uber's fork) & that it needs a certain level of operational maturity to monitor it all ... it's easy to get nervous about what the next "surprise" will be.

Having said all that, I'd use Kafka again in a heartbeat for those high volume use cases where reliability matters. Not sure I'd advise others without similar operational experience to do the same for anything mission critical, though -- unless you like stress. That stress is why Confluent is in business. :)

<comment><USER3> I can attest to 'getting nervous about what the next surprise will be' with Kafka. And I'm only dealing with a single node right now.

Kafka and Confluent Platform are very much still works in progress. I had to patch Kafka Connect HDFS connector because a fix I needed was left out of the last release. Be prepared to do something similar with any of Kafka's components.

</comment></comment><comment><USER4> To me it sounds like Kafka was not understood in full detail (maybe because missing documentation or the high complexity) and they switched to a system they build themselves. Naturally they know in full detail what is going on and can set up the system as needed.

I am wondering if working on solving the actual problems with Kafka would have been the better route. I've never used Kafka and i find ZeroMQ great, but reading that their logging solution does drop log messages is a huge no-go for operations. How can you claim to run a serious business and say "babies will die" when you can't be sure to be able to find problems?

Because, when will you lose logs? Not in normal operation, but when weird things happen. When networking has a hiccup. When Load on the system is too high, so most likely when many people are using your service. Exactly when shit hits the fan. And you just made the decision that it's ok to drop log messages in such cases? That's not good.

I think you should either dive into Kafka/Zookeeper and fix your problems or switch to another logging solution. You should probably just drop that non- sense "streaming and real-time logs" requirement and live with a log delay of a few seconds and build something _really_ stable instead of building something inherently unstable. Honestly, just collecting syslogs on the core vm and sending them to a central server would have been the better solution. Better then looking into fancy real-time, streaming logs on a sunday night because the system is having a breakdown and you can't even be sure that you are not missing essential logs.

<comment><USER5> One has only two choices in those situations: drop logs or block receiving more logs. Given their availability requirements, I don't think that blocking is a viable choice. So dropping logs seems to be the only sane choice here. There's no other alternative really so I'm not sure about the consternation.

<comment><USER4> What? No. You can just save logs on the disk and buffer them. Just dropping logs or blocking because some network resource is not available are both terrible choices and that's not how logging worked for the last decades. Throwing away logs ist a major step backwards.

<comment><USER5> If you buffer to disk, the same problem will eventually show up. Queues (in memory, on disk, anywhere) are all ultimately bounded, and when they are full, you have 2 choices: block or drop. Somehow you need to make the choice, there's no getting away from it.

If you don't make the choice consciously, say by assuming that you can buffer to disk and avoid the problem, at some point you'll fill up your disks and your system will block: you'll have unknowingly picked the "block" option. If you decide to rotate logs and delete old rotations when too many logs are present, then you're picking the "drop" option...

<comment><USER4> That's why you aggregate logs in a central service. I was writing about sending logs to a central service and not about how your disks fill up with more logs. There is log rotation for that and usually your logs will have been sent way before any log rotates. If your log rotation deletes logs before you aggregated them or if you let your disks fill up with logs you have a much bigger problem you should fix, of course.

<comment><USER5> That's again the same problem; if your centralized service isn't reachable for whatever reason, your nodes can buffer for a while (in memory or on disk) but eventually the problem always will boil down to 'drop' or 'block'. However you construct it, somewhere you need to make that call. They made the call to drop logs, it's totally fine.

<comment><USER4> If your central infrastructure is down for many days you have other problems. Buffering logs on disks. Rotating and zipping files doesn't take much space. You can buffer a lot before you run into trouble. That's my point. You sound like buffering on the node is only possible for seconds whereas in real world scenarios log files are written for days, weeks or even months. Even in very large deployments and lots of logs. You would make the decision to don't use this advantage and throw logs away for no good reason.

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> I don't understand why people need such ridiculously fast systems when we are using RabbitMQ and crappy Apache flume and we generate more than 5k with spikes of 50k messages/second. Please author of the article tell me your metrics.

And our log messages are ridiculously big at times (15k to as big as 50k).

Our pipe never has problems. What fails for us is Elastic Search. In fact at one point in the past we did 100k messages/s when embarrassingly had debug turned on in production and RabbitMQ did not fail but Elastic Search and sadly Flume did as well (I tried to get rid of flume with a custom Rust AMQP to Elastic Search client but at the time had some bugs with the libraries.. Maybe I will recheck out Mozilla Heka someday).

There is this sort of beating of the developer chest with a lot of tech companies.. that hey listen we are ultra important and we are dealing with ridiculously traffic and we need ultra high performance. Please tell/show me these numbers.... Or maybe stop logging crap you don't need to log.

Or maybe I'm wrong and we should log absolutely everything and Auth0 made the right choice given their needs (lets assume they have millions of messages a second), I still think I could make a sharded RabbitMQ go pretty far.

This goes with other technology as well. You don't need to pick hot glamorous NoSQL when Postgresql or MySQL and a tiny bit of engineering will get the job done just fine particularly when mature solutions give you such many things free out of the box (RabbitMQ gives you a ton of stuff like a cool admin UI and routing that you would have to build in ZeroMQ).

<comment><USER7> We run an average of 14k logs/sec through a two-node RMQ cluster, with max sustained throughput in the ~50k range. You're spot on with the bottleneck being Elasticsearch, but the latest releases in the 2.x train have a lot of fine adjustments that have drastically improved our indexing rate, such that we actually index at a 50k/sec rate. Would be interested to hear about your ES cluster configuration.

<comment><USER6> I'm embarrassed to say that at the present moment we currently don't use ES clustering but rather a monstrous powerful bare metal machine as we had issues with the cluster failing with some network issues we had with Rackspace.

BTW I didn't mean to denigrate Elastic Search (I assume that is why I'm getting downvoted.... a comment would help). We just haven't had the chance to upgrade it and properly configure it.

In fact Elastic has been pretty darn speedy as of lately particularly since we purge some of the data after 6 months (we still have permanent filesystem storage of logs of course).

<comment><USER8> You can turn off multicast discovery and write in unicast peering addresses. If you are in the cloud and you are clustering this is step 1 =)

</comment></comment></comment></comment><comment><USER9> Did you ever try running 5 ZK's in the ensemble? 3 is the absolute minimum to survive a single machine failure. If you are having trouble with availability, it seems natural to increase your safety factor there.

I was surprised by the contrasting sense of importance of delivery guarantees in the article. At the start, losing a message was akin to the death of a child. At the end, _shrug_. Now every single machine failure (or even ømq process restart) failure will lose you log messages stored in memory :(.

Glad to hear you found a solution that worked for you though! Would love to hear about difficulties you had with the new system, in particular adding brokers.

<comment><USER10> They said availability was "death of a child", not dropping log messages. The trade-off they've made here in terms of being available with some potential loss of visibility is the right one. The system overall is clearly simpler and simpler systems have simpler failure modes and so it is easier to add mitigation components on top that can recover from those failure modes to guarantee higher uptime.

I've never heard anyone say managing a production Kafka cluster was easy or simple. Well, anyone who has had to actually maintain such clusters hasn't said it anyway.

<comment><USER11> _> They said availability was "death of a child", not dropping log messages._

True, but it appears to me that availability problems and dropped log messages often have the same root cause - network issues.

So whenever they do have availability issues (and dying babies) they won't be able to investigate properly because log messages are being lost as well.

That's obviously a very general observation. It may well be that in their architecture availability issues are mostly caused by something unrelated to networking (e.g. the database).

<comment><USER12> It would be quite simple to have a two tiered approach to the logging problem since they have separated it into 2 components. One can just write and ship files while the other is what they have described in terms of providing real time streaming.

So the question then becomes what are the failures modes of their logging setup in terms of misbehaving clients? I don't know how kafka handles misbehaving clients. I suspect it would lead to global effects and slowdown of the entire cluster because of 1 or 2 misbehaving clients whereas in the current set up local misbehavior will be localized to the nearest aggregator dropping messages. Simple memory usage and other kinds of monitoring can then be used to find these issues and then mitigate them accordingly.

This is still a heck of lot simpler setup than using kafka and worrying about all sorts of weird distributed system failure modes. I'm sure kafka got them started initially but continuing to use it is like using a sledgehammer to kill a fly. For the use case they have this setup is the correct one and migrating to kafka if it becomes necessary will be possible. So in my view this is proper engineering. They've made all the right trade-offs instead of just chasing fads and trends.

<comment><USER11> _> It would be quite simple to have a two tiered approach to the logging problem since they have separated it into 2 components. One can just write and ship files while the other is what they have described in terms of providing real time streaming._

Yes, they absolutely could do that, but they apparently don't. And maybe that's because they would lose a lot of the simplicity they won by ditching Kafka.

Anyway, I didn't want to defend Kafka specifically. The one time I considered it, I ended up not using it because it seemed too heavy weight for my use case in terms of memory usage and complexity.

</comment></comment></comment></comment></comment><comment><USER13> FYI, Kafka doesn't need to fetch from disk every time as it caches the logs pretty aggressively, as long as you have enough memory.

Running Zk and Kafka on the same nodes is likely not the best thing.

<comment><USER14> Why? I would think that, as long as there wasn't massive I/O contention between the two, that co-locating Kafka and Zookeeper on the same machines would mitigate a whole massive class of weird edge cases by removing one of the failure modes; the network boundary between the two critical components.

Though for my part I still don't understand why Zookeeper wasn't built as a library to add distributed strongly consistent coordination to software that needs/benefits from it rather than being an external service that needs to be connected to, and thus introduces a gnarly mess of new failure modes that make Zookeeper client behavior extremely critical and often fragile. Something that's more like a "libpaxos/libraft" (e.g. serf for Go-lang or riak_ensemble for Erlang) seems a lot more valuable. /shrug

<comment><USER13> But co-locating them won't actually remove a class of errors because Zk is not HA. The Kafka brokers need to communicate with the leader in the Zk cluster.

If we have K1,Z1 -- K2,Z2 -- K3,Z3 -- and one node goes down, you've now taken down both a broker and a Zk node. Remember, the brokers don't care about connecting to _any_ Zk node, they want the leader. So you aren't gaining any more fault tolerant by co-locating them.

If there's a network partition between the leader Zk node and other nodes, the local Kafka broker won't actually be able to do much because the Zk cluster will elect a new leader, on another node, so again, you aren't gaining anything.

Moreover, you're now tying the scalability of Kafka with Zk. Zk doesn't scale linearly, so there's only so many nodes you may have in a cluster. Kafka, on the other hand, scales linearly. So if you're colocating them and you have to bump up Kafka, do you still start up Zk for those nodes (but they don't actually join the cluster)? You're now special casing and adding more edge cases.

</comment></comment></comment><comment><USER15> FWIW, you can get Kafka packaged as a fully managed and HA service from [https://aiven.io](https://aiven.io) on AWS and also Azure, GCE and DigitalOcean.

But if the Auth0 runs their entire operations on AWS, maybe Kinesis would have been a more natural transition.

<comment><AUTHOR> We need an on-premise and cloud story, so cloud only solutions did not cut it for us.

<comment><USER16> The article is a little old. How has the system run since you deployed it? Do you have any interesting figures?

<comment><AUTHOR> It continues to run beautifully. Since we rolled it out back in 2015 we had zero issues with real time logging. I have particularly fond memories of the first week after rollout, it felt like vacation. I finally could get some sleep.

</comment></comment></comment></comment><comment><USER17> The author correctly points out that he is comparing apples to oranges.

Kafka gives you features that certain systems cannot live without, like on disk persistence (saved my life couple of times) and topics. Filtering messages on the client side like ZeroMQ does it not an option in many cases, just think about security. I think Kafka has a long way to go before it can be used as a general message queue (many features are not there yet like visibility timeout for example) but if you can manage Zookeeper and have means to work with it (somebody understands it and knows its quirks) it can provide a reliable platform for distributing a large number of messages with low latency and high throughput, just like it does at LinkedIN.

</comment><comment><USER18> With ZeroMQ I had the worst possible results and experience. Honestly much of what it claims is bogus. It is highly optimized for certain cases and utterly useless for distributed systems. Try and find out in PUB/SUB what the IP addresses of the subscribers are. Not possible. In many cases you will be much better off learning TCP/IP yourself. In the mentioned case you simply iterate over the vector of subscribers - much more powerful and the sane default. It seems at some point people confused internal networking solutions with the Internet.

<comment><USER19> it is trivially easy for any node to broadcast its IP address to the whole network periodically (in my case every 2 seconds) using a separate thread and UDP. Using this technique I have rock solid ZeroMQ topology that reconnects with max downtime about 2.5 seconds (because I broadcast every 2 sdconds) for any single node failure. I agree that this functionality could be better implemented in zmq but using this simple technique, the rest of zmq becomes amazing. In Python:

      import socket
      import time
      cs = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
      cs.setsockopt(SOL_SOCKET, SO_REUSEADDR, 1)
      cs.setsockopt(SOL_SOCKET, SO_BROADCAST, 1)
      while True:
          cs.sendto('Node ID', ('255.255.255.255', 54545))
          time.sleep(4)

Everybody listening on the same on port 54545 without knowing Node ID's IP address will get these messages which includes the broadcaster IP address.

      import socket
      s=socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
      s.bind(('',54545))
      m=s.recvfrom(1024)
      print m[0]

This is a very useful technique when using ZeroMQ generally as you can broadcast services without knowning any IP address so they can come up and down on new addresses if / when necessary.

<comment><USER20> This would be great, but I don't think it works on AWS -- I don't think they support broadcast.

<comment><USER21> My ZeroMQ components all register themselves in a database when coming and going. This makes it trivially easy to find where stuff is just by running a bog simple database query.

Lots of ways to skin this cat...

<comment><USER22> What if they crash without registering an exit?

<comment><USER19> They broadcast every 2 seconds. No heartbeat = dead.

<comment><USER22> So there's more machinery waiting in the wings, not just the bog-simple query. Presumably you've barely described all of the mechanisms, and I won't bother socratically making the point that handwaving complexity away isn't the same thing as simplifying. I'll simply state it.

<comment><USER19> The above code is wrapped in a thread and runs non stop in each node. It's really not very complicated. It's basically sticking a def around the top block of code and then thread.start() in the main. It's extremely cheap because it sends then sleeps for a few seconds. Any node than then listen to the broadcasts on a known port (but no IP address needed) and will know exactly what the state of the system is and all the IPs. Then in the main loop you just make sure that you've gotten a recent pulse otherwise you reconnect. If you're using zmq it's just another short poller entry amongst the others that you will already inevitably have. Literally a couple of lines. It allows you to bring nodes up and down at will for robustness and scalability.

I think it's much less complex than running an entire database node just for this, which btw will also require you constantly to poll, and will require you to bring in an (often heavyweight) client library into each node too, as opposed to standard-library sockets which if you're running multinode you're almost certainly already importing. If you're looking for "simple" distributed computing my sense is that that has yet to be invented.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER23> ZMQ's default behavior (and in some cases only behavior) of dropping new messages when buffers are full, made it a no-go for my client. We ended up switching away from ZMQ to a more traditional durable queue and ended up saving a ton of code complexity and got a lot of reliability in the process. Having now researched it I can't think of a reason I'd ever use ZMQ again. I'll either use a durable queue when I care about message delivery, or something much more traditional when I don't.

</comment><comment><USER24> Maybe TANK ( [https://github.com/phaistos- networks/TANK](https://github.com/phaistos-networks/TANK) ) would have been a good alternative on there. No features parity with Kafka, but setting it up is a matter of running one binary and creating a few topics, and it is faster than Kafka for produce/consume operations. (disclosure: I am involved in its development).

</comment><comment><USER25> Did you consider MQTT? Sound to me a more natural choice.

</comment><comment><USER26> Probably should have been running ZK and Kafka queues separate to CoreOS/container shenanigans.

If deployed using the Netflix co-processes both are very durable.

</comment><comment><USER27> You can deploy Kafka using DC/IO and it takes care about HA for you. DC/IO is quickly becoming the go-to solution for database deployments. ArangoDB even recommends it as default.

Now about Kafka vs ZeroMQ: you want Kafka if you cannot tolerate the loss of even a single message. The append-only log with committed reader positions is a perfect fit for that.

<comment><USER28> Do you mean this? [https://dcos.io/get-started/](https://dcos.io/get-started/) aka DC/OS?

From what I can see it doesn't really support database deployments except for ArangoDB and Cassandra.

<comment><USER29> Riak and MySQL are in Universe, for example: [https://github.com/mesosphere/universe/tree/version-3.x/repo...](https://github.com/mesosphere/universe/tree/version-3.x/repo/packages/M/mysql/0)

</comment></comment></comment><comment><USER30> I'm a total message queue noob. What are the usecases for them?

I used MQTT but only as a message bus.

<comment><USER31> From my point of view, the main things behind message queues (Not zMQ specifically) is guaranteed delivery, persistence, multiple-message atomicity, message passing/forwarding, and sometimes guaranteed message ordering. Other than that, all it does is facilitate communication between different actors.

Nothing magical/weird about it, just depends on whether or not you've got a nail to hammer with your MQ-hammer.

</comment></comment><comment><USER32> Did you look at nsq.io or NATS?

<comment><USER33> +1 for NSQ, it's not a magic bullet in terms of scalability but you can get quite far. When I was at Segment we were pushing an easy 2-3B messages per day through it, if not more with message "amplification" internally.

</comment></comment><comment><USER34> Why dont all these companies ever just use real enterprise software?

There are about a dozen message systems out there that will handle much more than Kafka with minimal or no operational overhead while supporting everything they need.

</comment><comment><USER35> I came up with a very different solution for real time access to logs: tail them to slack. It's not an aggregation solution and doesn't work well if you have chatty logs with nothing to filter on, but if you just want to be notified when things are happening in the logs it's pretty nice and doesn't need any infrastructure.

[http://wanderr.com/jay/tail-error-logs-to-slack-for-fun- and-...](http://wanderr.com/jay/tail-error-logs-to-slack-for-fun-and- profit/2016/05/12/)

<comment><USER35> why the downvote? the article says "Real-time access to server-side logs is what makes backend development palatable in the era of cloud computing. As a developer you want to be able to get real-time feedback from your server side code deployed to the actual execution environment in the cloud, especially during active development or staging." and this is another solution that provides that.

</comment></comment><comment><USER36> 2015

</comment><comment><USER37> Anyone use collectd + rrd for this purpose? Still trying to understand at what level it's worth to move to something else.

</comment><comment><USER38> So you used Kafka for something that should have been handled by a MQTT or ZeroMQ in the first place ?

<comment><USER39> MQTT is just a protocol, so not sure how that helps.

0MQ doesn't sound like it is the right solution either, but yeah... often you pick the wrong tool and learn something in the process.

</comment></comment><comment><USER40> But why ZeroMQ and not nanomsg?

<comment><USER16> See [http://hintjens.com/blog:112](http://hintjens.com/blog:112) for my opinion on why nano isn't (wasn't, perhaps, as it seems to be doing better) a good choice.

<comment><USER41> With sincerely the greatest respect and admiration for what you achieved with ZeroMQ, Pieter, I think perhaps one might be a bit more nuanced when one isn't a neutral party. Full disclosure - I wrote a D wrapper, but I am not involved in nanomsg development and just a user.

There was some drama when the maintainer quit briefly before rejoining. Since then the gitter channel has been more active than I remember it being before. The mailing list is quiet it is true. Somebody just released a Rust version, and version 1.0.0 of nanomsg was indeed released.

You can see commit history here: [https://github.com/nanomsg/nanomsg/commits/master/src](https://github.com/nanomsg/nanomsg/commits/master/src)

<comment><USER16> Thanks for the updates. I've edited my comment. I've always wanted nano to succeed, just disliked the negative attitude to ZeroMQ expressed in its docs, which seemed unnecessary and damaging.

<comment><USER42> Yes, well the little guy always wants to unseat the dominant player, and when there is some personal history involved, things get more mixed up (technical, emotional, manner of expression). In your shoes I would be irritated by that too. But a project if it develops eventually transcends the personalities involved, and that seems to be happening now.

<comment><USER16> ZeroMQ is hardly dominant. It's a small player in a huge market and there was and is space for many more projects in this area. I'm glad nano seems healthy again, yet it's not enough, and I'll explain why.

In the end the whole point of ZeroMQ was to build new protocols and APIs for decentralized messaging. My real disappointment with nano was that it made zero effort to build on existing work (mainly, ZMTP) and instead just started again, as if thousands of people hadn't spent years figuring out what a decentralized messaging protocol might look like.

It was worse than that, in fact. Nano launched itself on a wave of negativity. It makes good press, and poor everything else. Such hate for one's own history and knowledge base isn't healthy. If a messaging product isn't aiming at _interoperability_ as a primary goal, it is worthless.

I'm not a fan of the "IETF or bust" approach either. That just doesn't work if you're a decentralized community. We needed and still need lightweight processes for RFC development. We use such a process (Digistan's COSS) in our RFCs. It wasn't random. I built Digistan and COSS over years after seeing AMQP swallowed up and destroyed by a committee. Why isn't nano using a process like COSS?

Without interoperable protocols, all we have is a bunch of software projects. And they die. And then all this is for nothing and the proprietary systems will rule the world and our dreams of making distributed software cheap again will die as well.

And this makes me angry: nano had the chance to push this forwards, and threw it away like old trash. What a stupid, petty waste of opportunity and goodwill.</comment></comment></comment></comment></comment></comment>


Times Extra: The New York Times Opens Web Front Page to Outside Content - <AUTHOR> http://www.readwriteweb.com/archives/times_extra_the_new_york_times.php <comment><USER2> Don't know about anyone else, but <http://nytimes.com/timesextra> returns a 404 for me (7:20 a.m. PT).</comment>


CamelCase vs. underscore_case - <AUTHOR> http://denisbider.blogspot.com/2016/03/underscorecase-vs-camelcase.html <comment><USER2> The author keeps referring to camelCase but uses PascalCase in his examples.

</comment><comment><USER3> Meh - I prefer lisp-case and c_case readability wise...</comment>


NVD3.js: re-usable charts for d3.js - <AUTHOR> http://novus.github.com/nvd3/?

<comment><USER2> Somebody has to really manage to make d3 run on 7<=IE<10\. This is a powerful technology for businesses, it may even replace Power Point (the famous software for torture) for some things (especially those that are updated often since you still do this manually in PP). But it needs to run decently and painlessly in IE.

<comment><USER3> It would be great to actually figure out the steps required to make this happen. I'm not familiar with D3's code at all, but I know that it renders to SVG. Would it be possible to easily "plug in" Raphael's SVG/VML abstraction?

<comment><USER4> The problem with this is it is an abstraction, while d3 uses the DOM directly. In principle SVGweb ought to work, but again there seem to be issues in actually getting it to work. Fundamentally all these methods are much harder than it appears they ought to be at first glance, and several people have tried one or other of them and given up after varying amounts of success (I didn't stay at it long).

Chrome Frame works well though!

</comment></comment></comment><comment><USER5> Bob's currently capped on commenting at the moment so I'll relay what he'd like to say:

"As you guys can probably tell, I'm still in a very early stage of development. But, with that said, we're gonna be jumping the gun and making all of the models production ready very soon, so will be taking care of bugs left and right.

Still working out all the common features between the models. Will be making things more customize able as I go. Hopefully in the next day or two will implement a "values" accessor so you can use some slightly different data formats without issues.

I definitely want to hear what people are looking for and what they would do differently, I'll do my best to balance my needs with everyone else's."

</comment><comment><USER6> Does anyone have any other recommendations for other interesting JS charting frameworks to evaluate? I'm using flot at the moment, I'm really keen to have a dig around in this now.

(My particular sunny day wish list is for live & historical scientific strip chart style data logging: flexible date support, intuitive horizontal timeline dragging & zooming, live updating, line charts with gaps in them, rendering largish datasets (especially in a drill-down style), and logarithmic axes - especially if you can mix them with linear axes.)

<comment><USER7> I recently evaluated lots of them for a dashboard project, and settled on flot. I built alternate working implementations in Flotr2 and Rickshaw, and less thoroughly evaluated Dygraphs, Envision, RGraph, elycharts, grafico, AwesomeChartJS, Morris.js, and Highcharts.

Highcharts is very nice, but commercial (although there's a free license for non-commerical work available). I settled on flot eventually because it has a reasonably complete set of features, easy API, and there are lots of plugins available to complete all the features I wanted to have. A lot of the newer frameworks are less complete (for now, anway).

That said, I've admired D3 for a long time, it just didn't have a good basic time-series chart wrapper to help a JS newbie like me jump in. Rickshaw's a good start at that, but missing some features I need, like multiple Y-axes. A D3-based library is attractive, because I also want to integrate Cubism.js's horizon charts, and keeping them on the same rendering engine will cut down code size and be nicely consistent.

I did notice that browser performance at rendering SVG is still noticeably behind Canvas when you have lots of complex graphs on screen at once. The Rickshaw implementation of my dashboard (Rickshaw uses D3) slowed down considerably on my MacBook Air compaired to the flot version.

Cubism, D3, and now NVD3 are still very much in the running for v2 of my dashboard project.

<comment><USER8> We were using flot when I started. As soon as I found out about protovis I redid all our charts (and boy was everyone happy with that improvement). Shortly after that, d3 came out, in which case I ported all the protovis charts to d3. NVD3 is my second go at a collection of charts for d3.js... it was re-done from the ground up, and hopefully is much more true to d3's style than my previous attempt.

<comment><USER7> I might have used protovis for my first iteration, if not for the fact that I discovered it just as d3 was introduced :)

I'm normally a server guy, but needed a good dashboard for our OpenTSDB metrics project, so I started diving into client-side JS -- going whole-hog on d3 without a good chart lib on top of it seemed to be a bit too steep of a learning curve. But I do love the possibility of open-ended charts, where we can dip into the power of d3 at will when we need something more custom.

Like DiabloD3 commented below, I feel like doing an end-zone victory dance :). Nice work.

</comment></comment></comment></comment><comment><USER9> They look great and we can never have enough cool JavaScript graphing technologies.

However the performance of these graphs is currently too slow for me. When I hover my mouse over a line the response is very stuttery while flot and highcharts are smooth as silk.

<comment><USER10> This must be something to do with the way they've set the transitions up (i.e. they've built in some delay). I've had no performance problems with d3. Do you mean when the tooltip fades in or something else?

<comment><USER9> Yes, it is the transitions of the tooltips, the circles that appear when you hover over a datapoint and the colour changes.

All of these stutter sometimes, especially if you are moving your mouse to a point and happen to trigger a few other events on the way.

Firefox 13.0, Kubuntu 10.04 Intel Xeon CPU X3450 @ 2.67GHz 4 core 16GB RAM

</comment></comment></comment><comment><USER11> Looks great. What's up with the scroll bar dancing around (chrome) as you mouse over the chart?

<comment><USER8> Working on that, something funky with the tooltips.

</comment></comment><comment><USER12> Excuse me, I have an end zone victory dance to deliver.

<comment><USER13> Tell me about it -- I've been waiting more someone to build a higher-level framework on top of d3. It's not a whole lot more than can be found in the d3 examples at the moment, but I can see this growing into an incredible toolkit, and one that can be customized at will using d3's power.

</comment></comment><comment><USER14> Noob question. What does re-usable mean in this context? What is NVD3 adding on top of D3?

</comment><comment><USER15> Anyone got any examples using NVD3.js or d2.js to render charts from constantly updating data? Like reading a websocket stream or query a json source every 2s and updating chart.

<comment><USER16> What is this d2.js? I'm finding nothing about it on Google or Github...

<comment><USER17> Most likely a typo, I'm fairly sure he/she meant d3.js

</comment></comment></comment><comment><USER8> OK, I should be allowed to post again (At least I hope so).

Let me know if you guys have any questions and/or feature requests. If I like the feature, I will implement it right away.. or if its a very bug feature, I'll at least put it in the TODO list.

Also would love to hear things people don't like about the library... that will be much more useful than what people like. No promises that I'll listen.. but I'll try to.

</comment><comment><USER18> Very nice, I'll be definitely looking into it closer.

[1] seems to have a bug. When you disable a particular line by clicking it on the graph legend, if you attempt to disable another line you end up re- enabling the first one.

<http://novus.github.com/nvd3/ghpages/line.html>

<comment><USER8> Not a bug, I did this by design. When you try to disable the last series, all series become enabled. There's no point, IMO, of disabling all series.

<comment><USER18> There's no point in keeping all series disabled, though I can imagine it being useful as an intermediate step.

Let's say I play around with some series A, B, C and D. I disable all except B and then realize that I want to see only A instead. So now I have two options, that IMO should lead to the same final state: I can either disable B and enable A, or enable A and disable B. In current implementation, the first option leads to re-enabling all series, while second option leads to desired state of having only series A visible. Now one of those two proposed actions may seem redundant until you realize that the choice between them depends on subconsciously analyzed things like mouse position ("is my mouse closer to series A or series B?") and having both available would, in my opinion, help in keeping user in the flow.

I understand it's only a minor issue. Current implemetation is more complex in philosophical sense that it does Surprising Magic instead of the Obvious Thing, and that bugs me just a little.

Or maybe I'm just whining because I got used to how HighCharts.js does this. ;).

<comment><USER8> Understandable, but not something I'll be implementing (though would be pretty easy to fork and edit.. that piece of code is VERY straight forward).. but would be too much of a pain in the ass to me, when the user could easily in A (after just having B enabled) then disable B.

Like you said, you're jsut used to high charts.... by no means was this project designed after high charts (in fact haven;t looked at high charts in over a year). Working off of d3 examples, Tufte principles, and whatever my gut decides makes sense at the time.

<comment><USER19> I would argue this has nothing to do with being used to highcharts and in fact is how a user would think. A chart library that follows anything from Edward Tufte should allow a user to make the chart as simple as they require it.

If a user has 10 series, and disables all but 1 to look at it and then decide to look at another in isolation, he would, in his naivety as a user, perhaps disable the one he's looking at before enabling the one he wishes to look at. After-all, he's looking at one at a time, so having two on at once could seem wrong to him for his current process. Disabling that one isn't disabled, nor does it blank the chart. Instead it does something completely unexpected, and is in no way predictable. It enables all 10 series again.

If you're designing a charting library that you want to be usable then it should follow user expectation. And no user will expect that turning off all series will in fact re-enable them all. It would make more sense to disable turning off all the series and requiring one on at any one time.

</comment></comment></comment></comment></comment><comment><USER20> This is great work and it's still early days. Looking forward to seeing the code clean up and having more extensible options for things like legends and fewer properties tightly coupled to chart instances.

</comment><comment><USER21> Going to update our batsd-dash web app to use this instead of Flot.

</comment><comment><USER22> would love to see circle packing charts in this...

<comment><USER8> Will be adding more and more models as I go... right now just taking care of what I need immediately for work. Really a can't wait till I get a chance to implement some of the more unique charts.

Of course people are always welcome to contribute some new models, and I'll do my best to keep them consistent with everything else.

</comment></comment><comment><USER23> Thanks Bob</comment>


NASA May Put Greenhouse on Mars in 2021 - <AUTHOR> http://www.space.com/25767-nasa-mars-greenhouse-rover-plant-experiment.html

<comment><USER2> This is an interesting experiment, especially juxtaposed with NASA's meticulous sterilization of probes.</comment>


Yes, eshell is [his] main shell - <AUTHOR> https://www.reddit.com/r/emacs/comments/6y3q4k/yes_eshell_is_my_main_shell/ <comment><USER2>
        It's undeniable however that, as of Emacs 25.2, Eshell has numerous rough edges.

And this sums up exactly why it isn't used more widely. According to the changelog, Eshell has been in development since _2000_ and still has "numerous rough edges", up to and including "doesn't support INPUT REDIRECTION". Even the list of "bugs & issues" in the documentation refers to Emacs 22 (from 2008). Not that newer software is always better, but users can't look at that timeline as reassurance that the bugs will ever be fixed.

I'd also find arguments like "you don't need THING_X, you can just use Emacs!" way more convincing with examples. One person's "trivial computation in Lisp" != another person's.</comment>


When Someone Says, "Why would you want to do that?" - <AUTHOR> http://nickmudge.info/index.php?post=131 <comment><USER3> My favorite bash.org quote is relevant here.

<glyph> For example - if you came in here asking "how do I use a jackhammer" we might ask "why do you need to use a jackhammer"

<glyph> If the answer to the latter question is "to knock my grandmother's head off to let out the evil spirits that gave her cancer", then maybe the problem is actually unrelated to jackhammers

</comment><comment><USER4> Disagree with the article. Most of the time, this question, coming from geeks, is helpful. The implicit statement is, "Hmm, why do you want to do that? What problem are you solving? Are you sure that's the best tool for the job? Let's look at the bigger problem first, before drilling down to some arcane and difficult detail."

And yes, "because I want to learn how it works" is a valid answer. But the question is valid too.

<comment><USER5> "Why would you want to do _that_?" is a very different question from "Hmm, why do you want to do that?"

The emphasis on " _that_ " in the first one is usually rather accusatory and the "Hmm" in the second one dramatically changes the entire tone. In face to face conversation, the vast majority of meaning is not in the words but in the body language, facial expression, and voice tone (and maybe a few other things I am forgetting). The actual words we use are a tiny part of it, which is part of why online communication can be so rife with pitfalls of misunderstanding (which can lead to flame wars etc, which would probably be avoided IRL by voice tone, etc while saying possibly the exact same thing as was written).

</comment></comment><comment><USER6> I usually use this phrase to signal, that deed that the person asking me is trying to perform is really not a good idea for a variety of reasons, while simultaneously I can't think of a single good reason for performing the deed: e.g.: If somebody asked me "how do I go about writing an XML parser for Java", I would firstly respond with the question. And then proceed to explain to our little grasshopper. That ALL the grasshoppers I know have been ignorant enough to go and write their own XML parsers which weren't really good, and made them waste precious life energy (not to mention community's resources) on something they had no business doing.

There is a big difference between writing an XML parser for purpose of learning how they work, and writing an XML parser because you are too ignorant to learn how many times before they were already done badly, but still way better than what you will produce.

I would also respond with forementioned question if somebody asked me: "How do you go about mending car chassis with duct-tape??".

But then I might also ask the question, when faced with a new concept that might be really, really cool. But I was thus far completely unaware of - <USER2> to either my own ignorance or lack of experience.

In either case - I use the phrase to introduce some humor (or vent some frustration) in an awkward situation.

</comment><comment><USER7> Bill Hicks offers another answer:

I've noticed a certain anti-intellectualism going around this country; since about 1980, oddly enough. … I was in Nashville, Tennessee, and after the show I went to a Waffle House. I'm not proud of it, but I was hungry. And I'm sitting there eating and reading a book. I don't know anybody, I'm alone, so I'm reading a book. The waitress comes over to me like, [gum smacking] "What'chu readin' for?" I had never been asked that. Not "What am I reading?", but "What am I reading _for_?" Goddangit, you stumped me. Hmm, why do I read? I suppose I read for a lot of reasons, one of the main ones being so I don't end up being a fucking _waffle waitress_.

</comment><comment><USER8> I think, when trying to help someone, asking for more context is a good thing. The examples that are given in the article are often things that arguably sound a bit more complicated than necessary (writing a windows app in assembly). Thus, the question is a valid way to establish a bit of context and by no means an implicit denial of the validity of what is being asked. "Because I want to know how it works" or "because I have reason to believe it is the only way it will work/be fast enough" are good replies and the whole thing leads on to a nice discussion (No not an exchange of tweets, a real discussion!)

</comment><comment><USER9> The question I ask is "What problem are you trying to solve?", which more unambiguously states what I mean.

In a tutorial, like the book referenced in the article, the reader is being demonstrated things that they might need someday.

</comment><comment><USER10> I disagree with almost all the replies here. Answering the followup question may be helpful, but it is not providing anything in the way the request.

In my opinion it is more polite and less ego centric to simply answer the question first, and then, if you are still inclined to prejudge the query as something reflecting the ignorance, mention you are suspicious of its intent.

</comment><comment><USER11> This sort of question annoys me to no end. My bosses and coworkers always asked me this whenever I proposed refactoring code (improving "perfectly good" old spaghetti or removing unused code). How would one go about answering this question in such a situation?

<comment><USER5> Figure out why they are resistant and find some means to reduce their resistance. For example: Did they write the code? If so, they may feel you are 'attacking' them/their competence in some way and you would need to find a means to reassure them that you respect them (yadda yadda) while still arguing for improvements. In many cases, ego and other personal stuff gets in the way of productivity. When that happens, the most effective thing to do is address the two issues separately.</comment></comment>


Physicists Confirm Quantum Theory Proposed in the 1930s - <AUTHOR> http://www.sci-news.com/physics/quantum-tunneling-water-05422.html <comment><USER2> This story was submitted with the current title, but from the URL it is clear that sci-news change the title before. The previous title was better. I guess it was something like "Physicist confirm quantum tunneling in water" that is more specific and makes more sense.</comment>


Can Silicon Valley workers rein in big tech from within? - <AUTHOR> https://www.theguardian.com/commentisfree/2018/aug/09/silicon-valley-tech-workers-labor-activism <comment><USER2> I'm quoted in the article as one of the engineers fired for unionizing and as an advocate of experimenting with a hiring hall model of organization. Happy to discuss either here.

<comment><USER3> Did you have any problems getting hired at your next job because you made waves at your last?

Does the company you're currently working for have a union?

<comment><USER2> When I and all of my coworkers were fired, and the office we worked in shut down, it came as an immense shock. I was terrified I'd never do the work I loved again, particularly after I became the de facto spokesperson for the group.

As it happens, I did not have any difficulty finding another job.

I had interviews with several companies within four weeks of being fired (despite spending a great deal of time cooperating with the NLRB investigation in addition to job hunting). I was sitting at my desk at a new job less than eight weeks after being fired.

I worked with a recruiter, who was not particularly interested in why my last employer had terminated me after hearing that all non-supervisory engineers had been terminated. I don't know whether the recruiter shopped me around to employers who decided to pass on me for having supported a union.

When asked by prospective employers why I'd left my last job I replied that the company had characterized the situation as a "lay off" of all engineers due to a "change in direction". I was never pressed for more information. One employer brought up unions in an oblique way, presumably because they'd googled my name and read coverage of the case. They made me an offer anyway.

My former coworkers, none of whom went public the way I did while looking for a job, didn't seem to have any problems either. I believe all but one have found new jobs better than or comparable to their old jobs. No employer could know who did and did not support the union, so everyone but me had plausible deniability. To my knowledge none were asked about it.

The company I'm working for now is a fairly typical media company and is not unionized.

<comment><USER3> Are you going to press for the formation of a union at your new job as you did on your last?

If not, could you talk about why not?

<comment><USER2> No. I don't believe in "salting" (taking jobs with an eye to certifying a union). I think I want what most devs want: a job where I spend most of my time writing code to solve interesting problems, to have opportunities to deepen my understanding of mathematics and computer science, etc.

People have problems at work all the time; they usually try to solve them as individuals. Sometimes that works, more often it doesn't -- they just come to expect less out of life.

At Lanetix, collective action was well underway by the time I became involved. The real catalyst of organization was the firing of an excellent engineer who had become the de facto spokesperson for grievances in one office (see: [https://gist.github.com/bwestergard/a5ddc5583d37554cc40a0e2b...](https://gist.github.com/bwestergard/a5ddc5583d37554cc40a0e2b86511371)). It was only after management's effort to suppress a collective response that I became involved. I was one of several who advocated for the NLRA route; I would not have done so in any "hot shop" situation.

</comment></comment></comment></comment></comment><comment><USER4> Not without conspiracy or organization.

Those who say yes when asked to engage in profit-generating yet morally ambiguous or immoral behaviors will rise and be rewardedm; those who say no will be marginalized and removed.

This is an essentially inevitable outcome for anything other than a nonprofit or benefit corp. Witness the decay of Google's moral compass, and more recently, the outright contempt for ethics at darlings like Uber.

</comment><comment><USER5> [https://en.wikipedia.org/wiki/Betteridge's_law_of_headlines](https://en.wikipedia.org/wiki/Betteridge's_law_of_headlines)

This is why we have governments with the power to enact regulations. I'd like to think no one still believes in any sort of market fundamentalism that believes firms will self-regulate against their own financial interest.</comment>


Intel Launches 4 and 8S Broadwell-EX Xeons E7-4800v4 and E7-8800v4 Up to 384 Threads - <AUTHOR> http://www.anandtech.com/show/10401/intel-launches-4s-and-8s-broadwellex-xeons-e74800-v4-and-e78800-v4-families-up-to-24-cores <comment><USER2> Love this, from the table, "Suited For ... World Domination"

8 sockets x 24 cores x 2 threads... wow... that is a beast of a machine to say the least.</comment>


The Man Who Allowed Bill Gates To Become The Richest Man In The World - <AUTHOR> http://www.kirps.com/web/main/_blog/all/the-man-who-allowed-bill-gates-to-become-the-richest-man-in-the-world.shtml <comment><USER2> yeah, my private jet has let me down countless times.

</comment><comment><USER2> so has my wife.</comment>


Ask HN: Approaching day job's customers about startup? - <AUTHOR>

I'm posting this from a fresh account, hope that's OK. I've been a HN member for 2+ years.
I'm in a situation that I hope some of you have been in as well. I have a day job but spend nights and weekends building out different ideas.
I've identified a need from my work at the day job, but it's not the company I work for that experiences the pain I'd want to solve, but some of the customers.
Now, my question is: what would you think about me approaching my day job's customers about being beta customers for my new app? Is it unethical, business-wise?
I wouldn't be competing with my day job, as this is a new offering that they don't have, but I would be using the fact that the customers know me from working with me at company X to sell them on idea Y, while still being employed by X. <comment><USER2> Yes, it would be unethical. Simply put yourself in the shoes of your employer - what would you think if you were in their place? You've used the detailed business knowledge you gained through their business to develop a product that competes in the same space (it doesn't matter if it's not a direct competitor - it might be part of their future development plans). And now you're going to also use the contacts you made through your job with them to sell your new product!?

Of course they'll think it unethical. I think the only way to do this ethically would be to leave your employment and either go full-time on your new product, or do some freelancing in your current industry to support yourself, or find employment in a different industry before you start approaching potential customers. I'd go for the second option, myself, if you can.

<comment><AUTHOR> Thanks for the reply. It might just come to that, although like we discussed on #startups, I don't think there is an ethical difference since I will be using knowledge and contacts gained through my employment anyway.

</comment></comment><comment><USER3> I think it really comes down to the degree in which your idea competes or potentially does so with the company you are currently work for.

If it's _completely_ unrelated ... to come up with something wild off the top of my head, say you've noticed something that could improve the landscaping you see as you go to the targets' front door, and your company sells business software of some sort, sure, go for it with care and the points that _delirium made.

But if it's something you could suggest to the company you're working that they add to their lineup, then you really need to separate from it before pursuing this. And states have very strong and enforceable laws about using the customer lists of your old company (note this doesn't have to be codified in your employment agreement), I'd consult a law library and lawyer for that. And of course if you live outside of California you may have to wait a year or two for a non-compete to expire.

</comment><comment><USER4> What kind of customers are we talking about? I think it's more likely to run into trouble if the customers are themselves large companies. If the customers are small---individuals or mom-and-pop restaurants or something---it's probably easier to reuse the contacts. That's just a guess, though. The current company would probably not be happy about it either way (though that's not necessarily determinative, because companies are unhappy about anything that remotely smells like competition, regardless of whether it's ethical or not).

</comment><comment><USER5> As far as I know, many employment contracts specifically disallow the use of the employers clients regardless of if you compete or not - but I'd check your contract with your current employer.

<comment><USER3> And get some legal advice. Just because they put it in a contract doesn't mean the provision is enforceable.

Lots of things employers try in this area are held to be against public policy (e.g. you can't sign away your right to be employed by anyone or to be employed in your general field of e.g. programming). Other restrictions are held to be over broad, i.e. duration and territory stuff, but that would generally take a court case to hash out.

The contract must also be a real contract, e.g. there must be consideration on both sides. Signing one when you get a new job is OK, your consideration is the new job. Being presented one after you're hired with a "sign it or lose your job" is _not_ , they've got to give you something in return.

<comment><USER5> Some good points! Thanks for pointing them out.</comment></comment></comment>


Dad sets up search algorithm to find kidney donors for "chained" transplants - <AUTHOR> http://www.nytimes.com/2012/02/19/health/lives-forever-linked-through-kidney-transplant-chain-124.html?partner=rss&emc=rss&src=ig <comment><USER2> Loved the piece. An amazing combination of math + medicine.

Does anyone know what type of math they're using to make the chains?</comment>


GeoGuessr – Let's Explore the World - <AUTHOR> https://www.geoguessr.com/ <comment><USER2> Also check bellingcat for the type of Open Source Intelligence (OSINT) that can be gleaned from pictures.</comment>


Forcing passive voice in LaTeX documents - <AUTHOR> http://bamos.github.io/2014/10/26/forcing-passive-voice-latex/

<comment><AUTHOR> This post has moved to [http://bamos.github.io/2014/10/26/preventing-passive- voice-l...](http://bamos.github.io/2014/10/26/preventing-passive-voice-latex/)</comment>


The Recursive Women in Tech Issue - <AUTHOR> http://gistofthegemini.blogspot.com/2017/12/the-recursive-women-in-tech-issue.html <comment><USER2> I think partly people want an explanation for why women's participation in tech has declined so much since the 1980s. Consider:

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

 _Suppose there was overwhelming evidence that 95% of women were terrible at technology and 5% of women were awesome at technology. There are roughly 7 billion people on the planet, roughly 3.5 billion women, roughly 1.5 billion women who work outside the house for a wage. In this scenario, where only 5% of women love technology, there are 75 million working women who are awesome at technology. According to the Bureau Of Labor Statics, the USA had 1,256,200 software developers in 2016. The BLS also tracks some other minor categories, such as Web Developer, which have about 150,000 jobs. Lump all the sub- categories together, and let's say there are 2 million such jobs in the USA. Let's be wildly generous and double the number for the EU, and triple it for Asia. That gives 12 million software developer jobs in all of the advanced and developing economies. So even with exaggerated assumptions about women's inherent weakness in technology, we still end up with a scenario where every single programming job in the world can be filled by a woman who will be awesome at the job. There is no need for men, at all, in the tech industry._

[http://www.smashcompany.com/business/business- productivity-h...](http://www.smashcompany.com/business/business-productivity- has-been-undermined-by-the-hubris-and-power-grabbing-of-elite-computer- programmers)</comment>


12 Obsolete Technologies Americans Still Use - <AUTHOR> http://www.livescience.com/37004-12-outdated-technologies-refuse-to-die.html

<comment><USER2> Consumerism: Use something because it works (regardless of its age) and we'll mock you for not replacing it with something newer.

If you use these products and they work for you, awesome. You know who misses out on the benefits of you switching? Corporations.

So laugh at others for saving money while you spend half your paychecks on what's new and cool, just because it's new and cool. /rant

</comment><comment><USER3> A fairly stupid article, which seems to be pushing the silly idea that as soon as neat new tech A becomes popular, old tech B _suddenly becomes completely obsolete and useless_. The "cult of the new" you might call it.

In reality almost all new tech, even that which is a good general replacement for something older, involves tradeoffs. Sometimes the bad points outweigh the good ones for use-cases slightly out of the mainstream. In other cases, the advantages of the new tech simply aren't great enough to warrant replacing something you already own.

[I own a (small) old CRT TV. A new LCD TV might be neat and appeal to my gadget instinct, but ... why bother? I don't really use it so much, and the old one works well enough. I just don't care about it very much, and would rather spend the money on something I _do_ care about.]

</comment><comment><USER4> I can't tell if this article is supposed to be mocking these technologies or justifying their use.

I don't see why landlines are dying, mobile phones are way too expensive for general use. Hell, I don't think I know anyone who doesn't have a landline.

<comment><USER5> Serious?

Where I live (across the pond) cellphones are the cheaper alternative.

Landlines are all swapped for ip "landlines" or mobile phones not only for convenience but also for price.

<comment><USER3> Cellphone pricing can be a bit of the wild-west...

I have unlimited free calls to anybody with the same carrier—but calls to _other_ carriers are really expensive, much more than a payphone.

[I'm actually surprised this is even _legal_ , but ...]

</comment></comment></comment><comment><USER6> Actually, I can see why people want Dot Matrix Printers, <http://theoatmeal.com/comics/printers> sums it nicely.

Also, CRTs don't have only disadvantages, as [http://en.wikipedia.org/wiki/Cathode_ray_tube#Advantages_and...](http://en.wikipedia.org/wiki/Cathode_ray_tube#Advantages_and_disadvantages) explains.

The problem with faxes is that people continue to (wrongly) assume that you can't spoof them. Especially now that you can fax arbitrary PDF.

</comment><comment><USER7> I'd take a CRT television or computer monitor over any widescreen flat display. The one I have next to my some-what old LCD looks much better when playing video. It can render 640x480 games correctly without some horrible scaling artefacts.

I also wish there were still more pay phones in my local area.

</comment><comment><USER8> Fax machines are the big one. They were obsolete ten years ago and still cheerfully screwing up documents and wasting paper today.

I'd argue that the printer and books pretty much qualify.

<comment><USER9> But then, fax machines are still the fastest and most usable way to transmit paper documents.

It's way easier to fax something, than to scan and send it, then having the others print it. I think that we haven't found a good replacement for the fax machine.

<comment><USER10> i'm pretty much a convert to hellosign.com

most documents I deal with never make the transition to paper in the first place anymore.

</comment></comment></comment><comment><USER11> In other words poor people, people living in rural areas and people in niche markets are using old technology. Hardly a surprise.</comment>


When Not to Use Lock Files with Node.js - <AUTHOR> https://www.twilio.com/blog/lockfiles-nodejs <comment><USER2> The reason why not to use lock files in libraries doesn't make sense to me.

Yes, you should ignore lock files in the .npmignore, so that they won't be published to npm, because library users don't consume them. As a library author, where a lot of people are collaborating on a package, you will gain the same benefits: reproducibility and easier triage of bugs. If you are concerned about updates, you can utilize tools to automatically update your lock files (greenkeeper, dependabot, renovate). Renovate has a mode to completely update your lock file in a defined interval.

Edit: your ci could also have a scheduled job which ignores the lock file (scheduled?), if you want to emulate a "integration" test and a "fresh" install

<comment><USER3> I agree. I have a bunch of little modules published on npm, and for all of them, I have a yarn.lock (or package-lock.json) lockfile committed in the git repo, but also listed in .npmignore so it's not part of the package published on npm. I do this so that all of the test/dev dependencies stay pinned to guaranteed working/tested versions, and so that there's a record of which versions of (non-dev) dependencies the library is known to work with. Here's a bunch of painful problems that happen when you don't check in your lockfile:

* One of the most frustrating things in the world is checking out a git repo that's missing any lockfiles and then finding out that its build script or unit tests are broken with the current versions of the dependencies, so you're blocked on doing any work with the repo until you fix that. The extra frustrating thing is that people who previously checked out the repo (including the maintainer) won't run into this issue, so this issue will fall onto new contributors and be an obstacle to them specifically!

* The next worst thing is getting a report from a user that your library no longer works with the current versions of its dependencies, and you don't even know which dependency is the problem or know of a good version of the dependency it worked with.

Putting the lockfile in .gitignore opens you up to the two above issues, and then barely helps. Your CI system isn't going to re-run your tests when your dependencies or sub-dependencies get updates. You're going to have to set that up separately and then you could set that process up to ignore or update your lockfile so it's not a reason to git-ignore your lockfile.

<comment> why-oh-why > Your CI system isn't going to re-run your tests when your dependencies or > sub-dependencies get updates.

Yes and no. Your CI system runs when you want it to. If you want to check the latest dependencies,

\- with a lockfile you have to delete it, create a new one and commit it;

\- without a lock you just press the "rerun tests" on your CI

<comment><USER3> Are you going to press the rerun tests button on every project every day in perpetuity? No one does that. If you're going to automate something to deal with this (that either reruns on dependency updates or just every day), then you can make that automation ignore or update your lockfile, and then the big problems in my post stay solved. If you run into a problem with a new version of a build/test dependency, then your project stays working for developers in the meantime until it's solved.

</comment></comment></comment></comment><comment><USER4> "however, if you want to make sure you have the same experience as your users, I'd recommend to add it to .gitignore."

That's just plainly wrong. Lock files are ignored in libraries so that shared common dependencies can be hoisted and number of dependencies reduced. That means that two users that depend on your library will get different resolutions for you dependencies according to other libraries that they use.

</comment><comment><USER5> > However, just because we are getting rid of the package-lock.json doesn't > mean we won't have the ability to pin the dependencies and child > dependencies we have. There is another file we can use called npm- > shrinkwrap.json.

> It's basically the same file as package-lock.json and is produced by npm > shrinkwrap and actually packaged and published to the npm registry.

> So by adding npm shrinkwrap to your npm scripts as a prepack script or even > a git commit hook, you can make sure that the same versions of dependencies > are used in your dev environment, with your users and in your CI.

So you are still pinning for dev and CI, even though your actual users will not be pinned.

Why is this preferable to just using the yarn.lock or package-lock.json, that would appear to do the same thing? Whats the difference that makes using npm shrinkwrap preferable?

It _can_ be confusing that you are pinning in dev/CI, but your downstream users will be using different versions. It seems to be the lesser evil though, neither trying to pin all users to exact versions of every dependency in the tree, nor refraining from pinning at all for dev/CI -- are really feasible.

I don't understand why the OP is suggesting `npm shrinkwrap` is a better solution than a checked-in yarn.lock or package-lock.json that are excluded from the npm module publish.

</comment><comment><USER6> This sounds more like a fix for an issue that should not exist in the first place. Why is npm ignoring the lock file to begin with? Why not publish and respect it on install?

<comment><USER7> It's a consequence of modularization, and it's not at all unique to Node.js. (Although Node.js has hyper-modularization, so the situation is more pronounced.)

Ruby gem has lock files, Python pip has lock files. I wish everyday that apt/dpkg had lock files.

The balance is between permissive versions (small install size) and pinned versions (reproducibility).

Some situations call for one, some call for the other.

<comment><USER8> But doesn't Node give each module its own deps? Python can't do this because it doesn't support multiple versions of the same dep.</comment></comment></comment>


How to Make a Microcosm of the Ocean - <AUTHOR> http://nautil.us/blog/how-to-make-a-microcosm-of-the-ocean <comment><USER2> Fantastic. There's some video of it in action here: [https://www.youtube.com/watch?v=CiHcgCwAw84](https://www.youtube.com/watch?v=CiHcgCwAw84)</comment>


One-sixth of Americans don't have enough food to eat - <AUTHOR> http://www.nationalgeographic.com/foodfeatures/hunger/

<comment><USER2> > It can be tempting to ask families receiving food assistance, If you're > really hungry, then how can you be—as many of them are—overweight? The > answer is "this paradox that hunger and obesity are two sides of the same > coin," says Melissa Boteach, vice president of the Poverty and Prosperity > Program of the Center for American Progress, "people making trade-offs > between food that's filling but not nutritious and may actually contribute > to obesity." For many of the hungry in America, the extra pounds that result > from a poor diet are collateral damage—an unintended side effect of hunger > itself.

This doesn't make sense to me. Doesn't calorie intake directly correlate with gaining weight?

From earlier in the article:

> Chances are good that if you picture what hunger looks like, you don't > summon an image of someone like Christina Dreier: white, married, clothed, > and housed, even a bit overweight. The image of hunger in America today > differs markedly from Depression-era images of the gaunt-faced unemployed > scavenging for food on urban streets. "This is not your grandmother's hunger

Is this not because the people in the depression era were actually starving? I'm not intending to downplay the issues here, but I find it hard to follow the disconnect of people being overweight not having enough food to eat.

<comment><USER3> YMMV

No. Have you ever noticed the "pot-bellies" of undernourished kids from all those poverty photos from Africa?

That's because they get the cheapest crap we can send/buy them - Rice.

It's not as simple as general thermodynamics. Kcal in and out is just half the equation.

We eat too much sugar today. Everything has so much damn sugar in it. All sorts of different varieties of carbs that eventually just become blood sugar and activating your insulin causing you to store it all as fat.

<comment><USER2> I think the distended stomachs are caused by actual starvation: [http://en.wikipedia.org/wiki/Kwashiorkor](http://en.wikipedia.org/wiki/Kwashiorkor)

Though it's possible you're referencing something else.

</comment></comment></comment><comment><USER4> "In 2006 the U.S. government replaced "hunger" with the term "food insecure" to describe any household where, sometime during the previous year, people didn't have enough food to eat. By whatever name, the number of people going hungry has grown dramatically in the U.S., increasing to 48 million by 2012... "

There are lots of people in the US in terrible situations, and we should try to help them, but that does not give reporters a license to make up facts. "Food insecurity" _does not mean_ that people are going hungry. It means people who are "at risk of" going hungry, a much broader group. From the Texas Food Bank Network ([http://tfbn.org/food-insecurity/](http://tfbn.org/food- insecurity/)):

"What does "food insecure" NOT mean?

Food insecurity is not "the government's definition of hunger." It is a broader term that captures outright hunger and the coping mechanisms that households use to avoid hunger.

Food insecurity is a household situation, not an individual situation. While food insecurity affects everyone in a household, it may affect them differently. Therefore it is not correct to state that specific individuals in a food insecure household (such as children) definitely experience outright hunger or specific coping mechanisms. Rather than describing these individuals as being "food insecure", they should be referred to as "living in a food insecure home."

Food insecurity is a year-long measure. Therefore, it is not correct to assert that every food insecure household is experiencing food insecurity "right now," will experience hunger "tonight" or "does not know where their next meal is coming from." Research shows that food insecurity tends to be episodic and often cyclical.

Food insecurity does not mean that a household lacks access to grocery stores, lives in a "food desert," or does not have time to shop/cook. It only refers to lack of food access based on financial and other material resources."

A much better, but less pageview-generating, term for the problem a large number of Americans face is "malnutrition". If you are malnourished, you may not be going hungry (and may actually be overweight), but still don't get the nutrients you need to be healthy.

</comment><comment><USER5> As a visiting New Zealander, the one thing I've noticed about the American price structure is that food is reasonably expensive, while superfluous goods aren't. A decent-ish pair of shoes is $50USD; a board game off Amazon $35, (which I'll admit to blitzing while visiting!). Both would probably set you back a minimum of $120NZD back home. Comparatively, our food is cheaper, and generally healthier (Whole Foods feels the closest to a New Zealand supermarket; lots of fresh fruit, vegetables, bulk bins).

The other surprising thing is that debit cards are new-ish here; credit cards are prevalent. Couple the accompanying fees (?) with pricing structures that are less declarative (food advertised sans tax; tipping expected), and it's more difficult to budget. Further, having/using credit means it's always tempting to dip further into it. In comparison, we've had EFTPOS (debit) for decades, sales tax is included in the advertised price, and there isn't a tipping culture.

NZ has its own problems with growing inequality which need addressing, and this is anecdata at best, but I can see why avoiding temptation and sticking to a good budget might be more troublesome.

<comment><USER6> Where are you shopping? While the average american supermarket (Kroger, Gerbes, Safeway, Wal-Mart) has a lot of unhealthy food available, there are also a lot of fresh fruit and vegetables.

Whole foods is a REALLY bad example of the average cost of food in the US-- it's well known for being expensive and catering to the organic/locally grown/whatever crowd. You're not going to get an accurate idea of US food prices shopping there.

<comment><USER5> Sure, I'm aware that costs are higher at Whole Foods :). Sorry, I shouldn't have left that unqualified. I've been elsewhere too; they just had a selection which reminded me the most of a supermarket at home (partly because this particular one wasn't massively oversized like the Wal-Mart I visited -- everything here is _bigger_!).

I'm also staying in an area (Downtown in an nice city) where food _would_ be more expensive anyway, which may be influencing my perception. So, again -- it's just an anecdote, but the area I'm in back home is generally regarded as an expensive one too.

</comment></comment></comment><comment><USER7> Here's a visual approach to cost per calorie: [http://www.mymoneyblog.com/what-does-200-calories-cost- the-e...](http://www.mymoneyblog.com/what-does-200-calories-cost-the- economics-of-obesity.html)

When I made my own cost-per-calorie calculations, I found that the much maligned non-synthetic FATS are a wonderfully cheap source of calories. They're nutritious, satisfying, and make veggies taste great.

There's a lot of bias against fat, and most Americans believe that eating fat makes you fat, but what does the evidence say? Look to the research, and you'll see that the opposite is true, provided you're staying away from vegetable oils and trans-fats.

Here's a sample from my calculations, for comparison with the link above (where foods were chosen to make the point that low-cost foods are bad for you). I live where food is pretty cheap. The most economical picks are very unpopular, I suppose because of the popular non-evidence-based, government- touted slander of eating a high-fat diet. Yes, it's bad for rodents. I'll give you that. But when you look at humans who are eating high-fat AND low carb, the research looks pretty awesome. And we could use more of it.

All prices are per 200 calories. (Grass fed items and etc. included to show the level of health and principle that can be achieved while keeping it cheap):

Trader Joe's PEANUT BUTTER (non-hydrogenated, no sugar added) $.10

OLIVE OIL $.14

Roasted SUNFLOWER SEEDS, $.14,

MAYO (fancy, safflower oil with no canola or soy) $.22

DRY LENTILS $.24

BACON ENDS $.26

ALMOND MEAL $.38

CANNED COCONUT CREAM $.32

Grass fed BUTTER $.36

CREAM $.38

REFRIED BEANS(canned)$.40

SOUR CREAM $.44

SWEET POTATO $.50

WHOLE CHICKEN $.56

COTTAGE CHEESE $.60

EGGS (local) $.70

YOGURT (plain,full fat)$.88

GROUND BEEF grass fed $1.38

Apples $1.40

GREEN BEANS (frozen) $2.00

Chicken Breasts ($5/lb)$2.00

</comment><comment><USER8> I'm not denying that there are relevant problems that should be addressed, but why are all these families having kids, multiple even, if they're not fit to raise them? I'm not saying they deserve it, but is it really all that surprising that one or two low-wage adults aren't able to provide for themselves on top of growing children? I'm sure there are families with no kids also facing difficulties, but damn, people!

Also, I'd like to see the breakdown of these families' budgets. Where is their money going? If they're like most Americans, they're likely pissing money away needlessly.

The cynic in me is showing again.

<comment><USER9> My politically incorrect opinion: the same factors that cause them to be poor influence how many children they have, poor decision making and low impulse control.

That and the fact that having children makes them poor by robbing them of the time to improve themselves and earn a higher salary.

<comment><USER10> And they are also likely to be happier than you are ;) Primarily because of the same factors that you've mentioned.

<comment><USER11> If that's true, which is doubtful, then their problems should become a 2nd priority, since our 1st priorities should be improving the happiness of the least happy.

</comment></comment></comment></comment><comment><USER12> _Of course it is possible to eat well cheaply in America, but it takes resources and know-how that many low-income Americans don't have._

I think that more food education, especially at a young age, could play a big part in addressing this problem and I wish that the article expanded more on this. I don't know if schools currently have any curriculum revolving around cooking, nutrition and reducing food waste but it could go a long way to prepare these children for rising food prices and the abundance of cheap, low- quality food products.

Edit: grammar

</comment><comment><USER13> I saw the chart of "more than half a mile from a supermarket," and I recalled that for as long as I have lived in my current neighborhood (since mid-2001), all my children have known how to walk along with me a mile out and a mile back to shop for groceries and carry them home. I have been doing something more or less like this most of my adult life. Sometimes I would walk for a while before catching a bus home from my grocery shopping, or sometimes share rides with friends who had cars and go on shopping trips together at especially inexpensive discount grocery stores, but whether traveling farther or nearer, I always preferred buying food in grocery stores and preparing it at home to buying fast food. Always. My children have grown up into slim and athletic adults, perhaps because for them eating is something they do after engaging in exercise. Yeah, some places in the United States (and some of those are featured in the article kindly submitted here) are a lot lousier even than the Near North Side of Minneapolis for taking walks outside or for finding any access at all to a grocery store, but for the most part the first thing to change here is the trade-off of how far to travel by what means for what kind of food. That will promote better health, even with very low incomes.

</comment><comment><USER14> We spend less on food than ever before.

[http://www.investopedia.com/financial-edge/1009/50-years- of-...](http://www.investopedia.com/financial-edge/1009/50-years-of-consumer- spending.aspx)

We spend less on food than any other nation.

[http://www.economist.com/blogs/graphicdetail/2013/03/daily-c...](http://www.economist.com/blogs/graphicdetail/2013/03/daily- chart-5)

It's debatable that food deserts are a thing.

[http://www.nytimes.com/2012/04/18/health/research/pairing- of...](http://www.nytimes.com/2012/04/18/health/research/pairing-of-food- deserts-and-obesity-challenged-in-studies.html)

<comment><USER15> Isn't that last article saying that food deserts aren't necessarily correlated with obesity?

<comment><USER14> Correct.

The questionable correlation in the original article is:

Good food is simply not available in low income neighborhoods >people are forced to make make cheaper choices >they become obese and malnourished.

The times article cites studies that call that into question, citing apparent actual availability in those areas and focusing more on people just making poor choices.

I'm no expert, but sheer economics does not seem to be primary influencer causing current outcomes.

<comment><USER15> Okay. I just wanted to point out that your original post makes it sound like "Food deserts don't exist". Not "Food deserts aren't necessarily correlated with obesity"

</comment></comment></comment></comment><comment><USER16> Problems like this make me feel we need two parallel governments and you could subscribe to either.

1\. Govt 1: Nanny state. Will support you if you get poor, but you agree to controls on your life.

2\. Govt 2: Do whatever. Don't come crying if you crash and burn.

<comment><USER17> I find it interesting, that the article seems to view the fact that the family has to supplement their SNAP assistance with visits to a food pantry as a problem, rather than something to be happy about.

Indeed, poverty, hunger and food insecurity are awful, but why is it more attractive for amelioration of these conditions to come from the Federal government, than from non-governmental actors?

<comment><USER18> Seems to me a government mandated program might seem more limitless and be less personal and thus you don't feel like your taking advantage of the kindness of caring people or stopping resources going to those who are possibly even more needy.

On a related note: One of the things I somewhat like about taxes for welfare rather than "rely on the largess of charitable billionaires/private entities" argument is that it helps ensure expenses from charitable acts wouldn't be a drain on a business competing. Thus 'asshole' private entities wouldn't have a concrete market advantage over 'nice' private entities.

</comment></comment></comment><comment><USER19> The U.S. is full of people that can barely make it to the next paycheck, but they'll have an iPhone, a car, cable tv, cigarettes, etc. Unless you are taking public transportation to your 2 jobs without all the consumer goods I've mentioned, then you aren't poor.

</comment><comment><USER20> The other five-sixths of us have too much.

<comment><USER21> Several of the people pictured in the story are overweight. The cruel irony is that if the price support for wheat/corn/soybean processed food was removed these people would get to feel what physical starvation was like.

<comment><USER22> Yeah, because corn, wheat, and soybean are inelastic goods, am I right?

I can't go 3 days without that sweet sweet soybean oil, or I will literally starve to death.

I'd actually draw the supply and demand curve and what would happen to the various suppliers and buyers if the subsidies were removed, but I'm afraid I would get labeled a dirty Randian and branded a heretic.

</comment></comment></comment><comment><USER23> bullshit

</comment><comment><USER24> Are the rest obese?

</comment><comment><USER25> Mrs. Dreier looks to be at least 20kg overweight. She could quite healthily fast for at least 3 months living of of those reserves plus some magnesium supplements. It has been done before with great success:

[http://www.ncbi.nlm.nih.gov/pmc/articles/PMC2495396/pdf/post...](http://www.ncbi.nlm.nih.gov/pmc/articles/PMC2495396/pdf/postmedj00315-0056.pdf)

<comment><USER7> Hmm. Do you want to pay for the medical supervision she'll need for that fast? Healthy food might be cheaper.</comment></comment>


Ask HN: What's fair equity for cofounder without day-to-day responsibilities? - <AUTHOR>

As part of a fun side project my friend as I accidentally invented a product that has become successful in a niche hardware market. My partner, who is in a more fortunate financial situation than myself, was able to work full-time on this from the beginning with little/no pay. I needed my day job so I spent nights/weekends on this. For many many months I was doing 20-30 hrs/week at the startup on top of the day job. He was working at the startup during the day as well as nights/weekends with me so he was definitely working more than me.
We've since rented a building and hired employees. While we're barely sustainable at this point, if I went full-time I would be making 1/3 of what I make now and I would lose all benefits. I truly LOVE my day job and have realized that I'm not passionate about working at the startup. It's successful side tangent in an arena we both know little about. I would also have no work/life balance. I've also realized that I don't work very well in business relationship dynamic that he and I have. He wants to pursue it, I no longer want day-to-day responsibility.
Obviously, a 50/50 split isn't fair any longer. We renegotiated our split based on amount of time spent working on the project-which I thought was a little dubious given the amount of time, money, hundreds of hours of design/engineering work (both our names are on the patent), and the fact that it took us both to start up. Either way, I obliged now own a little less than 10%.
He's now seeking outside investment and asked me to sell all/most of my shares back to him (at a VERY low valuation) because he thinks it's unattractive to potential investors to see a large stakeholder who isn't full-time.
Questions:
1. Does he have a legitimate concern about the large stakeholder issue? I feel like I've already let go of too much.
2. If so, what percentage would be considered "small enough"? I definitely don't want to throw away all my shares.
Thanks! <comment><USER2> You don't intend to work on this startup full-time? I'd say the current deal you have (10% for you, presumably 90% for the full time co-founder) sounds fair to me.

I have advised many founders in how to split equity. Think of it this way: if you had started at 50/50 each with the standard vesting, and you had quit early on (6 months to a year later), your 50% would turn into 6.25% to 12%. Pretty much exactly where you are now.

I don't think you need to re-negotiate. Once your founder raises more money, you'll soon be diluted closer to 5%. Nothing that an outside investor would worry much about, unless they are not seasoned investors.

Don't change anything.

</comment><comment><USER3> He has no legitimate concern. You have already come down to a very fair percentage, IMHO. 10% with no protection is fair, his will to throw you off the company with a very low evaluation is opportunistic.

Serious investors will look at the potential of the company and the potential of their return, the amount of time another shareholder spends is secondary to it.

Good luck!

</comment><comment><USER4> i dont think he has a legitimate concern at all, tell him your stake came from your investment of time, energy and ideas. if he wants to take that he should offer fair compensation or sell his shares. from his logic, why should someone providing capital get any stake? they arent working day to day either.

from an investor point of view, i wouldnt see it as a problem at all.

</comment><comment><USER5> if you care about keeping your equity you need to get a lawyer to look over anything you sign.</comment>