I'm honestly surprised how simple this code is, now that I started reading it. Julia, you've shown me in one succinct article that the linux kernel isn't a big scary black box of a place, and that maybe I too can hack on it or write modules.
The kernel code also reminds me a lot of the code to Node.js circa 2009/10, which I find a little strange.
If your startup is actually shutting down, then this period you're in is as good as a notice period. I suspect you might find chatting with the Pay With Tab guys interesting, they were in a similar boat and also wrote that article about startup failure: https://medium.com/on-startups/b0722086c0f7
From what I can gather, if the file handle isn't in write mode or is a special file, then we call __mnt_want_write, http://lxr.linux.no/linux+v3.12.6/fs/namespace.c#L305, otherwise we clone the write handle or something.
Yeah, I'm working on updated instructions at the moment. You may get stuck at the step that's "Install a new kernel on the RPi." if your system is i386; Those instructions only work on x86_64, afaik.
I'm keeping a log of what I try to see if I can make things faster / better.
Definitely worth a read, some really good words of wisdom in there, and some that are common sense, but sometimes common sense really does need to be written down.
Hi, I work for Pusher and wrote that article, so I feel the need to respond:
When people ask "Why would I use Pusher instead of running my own realtime services in-house?", they often overlook the other complexities involved in the problem. Eg, scaling, maintaining, ensuring uptime, etc.
Looking at any service (IaaS, PaaS, SaaS) from the outside is an iceberg problem. You can see the public API (REST based API + WebSocket API), and you know what it does for you, however, what you don't see is what lies beneath the water, the other factors and things that have been thought about for you so you don't need to think about them.
The thing that really needs to be thought about is this: by building your own in-house realtime solution, you'll probably face similar problems to those that we have to face building and maintaining Pusher, such issues might include:
1a) How will you communicate with your realtime service? Will it be a REST API (like Pusher) or something else?
1b) How will you maintain the infrastructure required for the persistent connections and consistent distribution of messages throughout your cluster?
1c) How will you handle sudden (unexpected) growth in usage, and do you want to have to worry about that?
1d) Who will ensure that you're up-to-date on the latest websocket specification (we're at draft-07 being released in firefox 6, and draft-09 is currently being edited).
I should note at this stage, that hosting websockets is in no way similar to hosting standard HTTP, there's a lot more to the problem.
By the same logic, you could apply that to any PaaS or SaaS or IaaS product. Do you use Amazon Web Services or another cloud based host, or do you use a non-cloud based host? Thats a place where you're outsourcing the management and maintenance of your infrastructure; that is, unless of course you maintain your own data-centers and install all your own servers?
Having built a websocket server for Node.js, I know the issues involved with maintaining and keeping up to date with the latest protocol specification. Is it cheaper for you to use Socket.io instead of role your own solution, because honestly, something might go terribly wrong within Socket.io. Do you want to spend time maintaining that?
This is all about choices, for some projects, it may make sense to handle everything where you need absolute control over every aspect of your application and infrastructure. However, from experience, I can say that I probably wouldn't want to be having to maintain absolutely everything in my application. If AWS/EC2 goes down, then yes, I should worry, however, I think EC2 is less likely to go down than my own hand-installed network infrastructure.
I'm not going to try to sell you on Pusher, however, just take into full account absolutely everything before you decide to roll your own realtime solution.
Node has actually had quite a few blocking API's, I'm not sure for how long, but there has for quite a while been a fs.*Sync, they're just undocumented, because their usage isn't recommended.
I think the speed you see as a difference may be coming from how you're writing the data, node requires multiple function calls to do the writing of data (unless you use a raw tcp socket), tornado appears to just take it all in one function call, which takes in a string.
Ignore what others say about your interests, put your head down, do a bit of hard work (but mostly play,); get involved in communities (eg, your favourite javascript library's community), get recognised for your work, learn from the masters, but don't ask for answers, ask for tips.
That's all I could say, I'm 16, and currently working along side some very cool people. I've been in it about 3 years.
The kernel code also reminds me a lot of the code to Node.js circa 2009/10, which I find a little strange.