It seems that TBP just taken another step to push judge and jury's confusion during next trials even further.
"Y'know, we're trying to shut down pirates' secret base that... doesn't serve a single file!"
Well, it is a nice solution to make someone's life easier when there are no signs of a cure coming. For example, this font could be set up as a system's default (or even it could be enforced as the 'one and only' typeface) and thus it will make dyslexic's life better. IMO it's a win.
Also you should note, that this font was created by a dyslexic, so I think he knows what he is doing.
I wrote a chat server with Node.js/Socket.io + node-amqp. Message flow was dictated by business goals, and therefore was somewhat odd. Each client had his own queue and a single exchange was created for each room. Message came to N.js over a Websocket, from where it was pushed to a chat room's exchange with a temporary id. Next, message was posted to a Rails powered backend for processing and storing to a database. If Rails responded with success, a real message ID was pushed to the exchange, otherwise a command to kill message by temporary id was sent.
Given all this, I wasn't able to go beyond 2k simultaneous connections. Reasons? Our Rails setup wasn't able to handle that much requests. For the sake of testing I wrote a synthetic tests where Rails requests were mocked. RabbitMQ was running on Thinkpad Edge (quad core [email protected]), node.js client and server was running on dual core pentium@3Ghz.
This configuration gave me 3.5-4.5 thousands of message deliveries per second, both PCs were at the top of capacity.
Such performance looked suspiciously low for me, so I went further. Reading node-amqp shown that it is totally flawed (i.e. it is allocating 130kb buffer for each message sent). Doing some tweaking I managed to increase message delivery rate to almost 15 thousands of messages/second.
Strange part of the outcome is that processing both 4k and 14k messages created almost identical load on RabbitMQ.
Lessons learnt:
1. RabbitMQ is very robust and easy to work with.
2. Do not measure RabbitMQ's performance by LA or CPU consumption. If you feel stuck, try optimizing something.
3. V8 memory allocation/GC suck. My server was constantly crashing due to std::bad_alloc being thrown after next packet buffer allocation.
4. node-amqp suck even more. I am going to work on it somewhen soon.
5. Node.js on it's own is a toy, not a tool. Do not build mission critical systems designated to handle long living connections with it.
Web development complexity mentioned here is just a reflection of a complexity of the outer world. Activities you perform throughout the day require you to make choises which in it's turn requires knowledge gathered during one's life. Yes, you can't be an 'average Joe' to build a web application, but you can't be the same Joe to build a motorcycle or go rafting or found a glass factory without a (impressive amount of) domain specific knowledge.
World is complex. Technologies are. Deal with it.
Another thing that seriously bugs me is the approach to mask completely different goals and processes by imaginary simplicity of overlaying technology stack. Writing a web app and making it scale are totally different goals, choose what are you going to do first. Textual documents storage will differ from video hosting by a couple of orders of magnitude. The more generalization you achieve, the less freedom you'll have.
Bullshit. Try reading something on the topic before writing. Even Wikipedia will do.
DLNA specs groups devices in categories, including servers, renderers, and controllers. Using DMC you can command DMR to play a media from a DMS.
The fact that you've used loosy implementation doesn't mean that the spec itself is a crap.
DLNA is not a silver bullet and has some flaws, but it is thousand times better then AirPlay just because it is more open and does not require specific hardware to accomplish simple tasks. And what is even more important, at the moment huge amount of work is being done worldwide to enrich the list of devices supporting these protocols.
At the moment I am using Minidlna to serve videos and it works like a charm, even with big resolutions. While trying to find a way to deliver stream to the TV from under Mediatomb, it was required to specify some magical header value. Also DLNA players I worked with were extremely picky about the content type you specify. I.e. sending FullHD .ts stream won't work well unless you say it's video/mpeg.
Anyhow, at the moment opensource is only starting to be curious about something other then writing code and compiling it. Too bad they are doing new stuff kind of wrong (see KDE4 and Gnome3, my two major reasons to use Fluxbox).
My Samsung Galaxy S + one of Samsung TV nearby is playing it exactly like that by using much more user friendly protocol stack. Meet UPnP/DLNA. Moreover, right now I am watching a quaterfinal of Heineken Cup by magically streaming video to the TV over the local network. Meet UPnP/DLNA once again.
And there's more! This December I spent a week in Samsung's R&D working with their extension of UPnP that will deliver custom user interfaces for the TVs. They will be like regular javascript enabled web pages with an access to TV's media playing capabilities. No Apple, still.
So I beg you, Apple fans, try to take a broader look before shouting out loud about new killer features 'invented' by Apple.
Fix the language, then fix event processing approach, then spend 10 yeard maturing in the highly concurrent environments and end up being Erlang. w00t.
I got exactly the same lesson in almost similar situation, but from a guy who was not even close to (someone who is close to) a Nobel's prize. He did a sum of a problem from the test using a small constants reference book and his head. Despite the numerous simplifications in the calculation, error of his result was less then 5%.
By any means I'll stand on a point that using pure XMPP from a JS point of view is a total over utilization. XMPP is perfect when you're able to make it fit your needs and (more important) you are able to hide it's extreme complexity from your user.
Zed did an awesome job. If I'll have a chance, I will do my best to deliver this book to my university's CS faculty, where newcomers are still being taugh with Delphi (d'oh).