dhaivatpandya

The exposition is not very clear. What exactly do you mean when you say "No edges will be communicated over the network, only half of the nodes."? I'm puzzled, because a few sentences later, you claim "The only network IO that would be required would be sending each edge value to its respective node in Q."; so the edge values are actually communicated?

From what I've understood, what you're suggesting is that for every node in a layer, you colocate the edge on the same machine?

I don't think it is necessary for Github to provide choice for this sort of thing. It isn't a ground-breaking, massive change to their main product. To me, it seems like an unnecessary choice that would only create confusion and make their product more difficult to navigate and use.

http://sleepyti.me - simple concept, simple implementation, lots of users.

You can provide the ACID guarantees by using something like Redis.

As a concept, I guess this can be called an OS, but at the present moment, it is pretty far from one. Right now it seems like this is basically a work-in-progress replica of BusyBox built on Node.

What do you mean by "UI component API"? Couldn't you use Blaze in order to construct the the UI you need or modify existing components to fit the Meteor reactive model?

See research paper: http://arxiv.org/abs/1403.1211

When I said "paper lens", I meant the idea of embedding the lens into the paper.

That's not necessarily the case. That's assuming that the admissions process is perfect, which I do not think anyone at YC or any university would even propose.

I think this comment exemplifies the "HN negativity syndrome".

Completely disregarding the years of effort poured into developing a paper lens, etc., you simply dump the innovation into the "not very clever" pile?

It is still a "said so" because it is a definition. Even if thought went into the definition, it doesn't make any less of a definition.

If he was living on $600/month, that is a pretty small amount.

I would also suggest a cover redesign. I can't even read the title or the caption.

For research mathematicians, working on a tablet would probably just feel cumbersome; why not use a computer?

If I understand your problem correctly, you can just build on the server, right? That's one of my quibbles with Go; the "write-compile-run" cycle gets annoying. But, for me, the benefits outweigh the harms.

Original writer here. Let me know if you guys have questions, etc. Was about to post this to HN, then noticed it was already here!

This works on a philosophical level of "knowing more about the world", but with regard to just information, fiction doesn't cut it (nor is it meant to). For example, you don't learn more about shipping containers or processor architecture with fiction.

But unless he mentioned that when the decision was made, that should not affect the results.

By that reasoning, helping someone who has fallen on hard times by teaching him/her new skills is counterproductive? That doesn't really make a lot of sense.

The UN is deprecated? Any evidence for that?

I'm not so sure. He seems a bit too enthusiastic to me; slightly artificial.

I'm currently working on a Go project that is meant to sit above the Hadoop FS. Go has been absolutely brilliant to work with. Some of the design decisions make very little sense at first (e.g. no fields in interfaces, no real inheritance, etc.) but as I've used the language more and more, the reasoning behind them becomes clear.

Agreed. Try getting funding for verifying a paper's results. If you can't publish results, it'll be a hard time convincing anyone that your work is worthwhile.

I meant to say that VMs can do a deeper level of process isolation. They also perform complete hardware virtualization, which means you can run a completely different OS inside the VM. However, in terms of performance, VMs are not necessarily faster than containers at all tasks.

I recently wrote an article that covers some of this ground: http://www.sitepoint.com/docker-for-rubyists/

The basic idea behind Docker is that you don't have to create another operating system in order to just separate your processes from each other. This leads to containers being much more lightweight than virtual machines but also significantly less powerful (i.e. powerful as in ability to do something, not in terms of performance) in some areas.

I wish you didn't have so much text on the front page. After reading the first two lines, I just skipped through the rest.

What do you guys do differently from agencies? What's special? I can't tell that from your page unless I read the entire block of text, which, frankly, 0.1% of hits will do (maybe).

I don't like this at all; you're basically screwing Heroku out of what they should be paid for providing a good service.

Secondly, you could set up a DigitalOcean server ($5/month) in about 10 minutes with Rails and this wouldn't be a problem.

http://www.nimblenot.es/ - Markdown notes organization. Ruby on Rails. I just don't have the time to market it and get it to users at this point, but, I definitely think it has lots of potential as a way to organize Markdown documents.

SEEKING WORK/REMOTE

I do mostly backend work as well as Javascript/jQuery.

Work with: Ruby/Rails, Python, C, Javascript

Portfolio: http://www.dpandya.com/ (must put in the "www" - having troubles w/ domain registrar)

I've won several awards for CS research and engineering - from ACM, Intel, CERN, etc.

Email: dhaivatpandya@gmail.com

I wish there was something like this for rails - well written, concise and keeps the newbies away from things that'll hurt them. In particular, some major pain points:

1. Use rbenv or rvm. Half the problems I notice with beginners stem from installing rails with apt-get or something.

2. Your controller is meant to be simple glue between model and view - if you're putting tons of code in there, you're doing it wrong.

3. Unit test. A lot. This is especially good for beginners because you often make little errors when you're starting out.

4. Unit testing isn't enough. Functional testing is important too.

5. Learn about your hosting provider. Specific to Heroku, if you're on the free plan, every dyno spin-up takes absolutely forever if you don't have a steady stream of visitors.

I don't think this a new problem, its just one that has been hidden exceptionally well in "recent" times.

The obvious example is The Jungle by Sinclair which was essentially publicity of precisely these problems, except in the beginnings of the 20th century. I highly doubt that the situation has been drastically improved, but, really hidden much more thoroughly from the public view.