Node.js - A Giant Step Backwards - <AUTHOR> http://fenn.posterous.com/nodejs-a-giant-step-backwards

<comment><USER2> This purist evented I/O fundamentalism has to stop.

While evented I/O is great for a certain class of problems: building network servers that move bits around in memory and across network pipes at both ends of a logic sandwich, it is a totally asinine way to write most logic. I'd rather deal with threading's POTENTIAL shared mutable state bullshit than have to write every single piece of code that interacts with anything outside of my process in async form.

In node, you're only really saved from this if you don't have to talk to any other processes and you can keep all of your state in memory and never have to write it to disk.

Further, threads are still needed to scale out across cores. What the hell do these people plan on doing when CPUs are 32 or 64 core? Don't say fork(), because until there are cross-process heaps for V8 (aka never), that only works for problems that fit well into the message-passing model.

<comment><USER3> redis is pretty badass for talking to other processes without really talking to other processes, and it's the #10 most depended-upon library on npm right now. <http://search.npmjs.org/>

It won't work for every problem, of course.

dnode is a good way to easily talk to other node.js processes without the HTTP overhead. It can talk over HTTP too, with socket.io.

node-http-proxy is useful as a load balancer, and a load balancer can distribute work between cores.

Finally, most of the node.js people I've met, online and offline, are polyglots, and are happy to pick a good tool for a job. But right now node.js has great libraries for realtime apps, the ability to share code on the client and server in a simple way, and good UI DSLs like jade, less, and stylus.

<comment><USER2> Huh? how does any of this keep me from having to write callback spaghetti? If I send a call using redis or dnode or whatever, I have to wait for it, so that means a callback.

I feel you about the polyglot and tend to agree, but I think some people are really trying to force awkward things into node, like people attempting to write big full-stack webapps using it.

<comment><USER3> I didn't mention any of those libraries in my reply to your original comment. To help alleviate callback noise, there's <https://github.com/caolan/kanso> , which Fenn mentions in his blog post's comments, and there are EventEmitters, and there is Function.bind() and Backbone.js-style async, where you have methods that describe what each callback does. (Backbone is usable in Node.js but perhaps not as practical on the server as it is on the client.)

Also callbacks to me are kind of like parenthesis in Lisp. They're annoying but they're for the greater good. :)

<comment><USER4> "deal with it" is a good response. personally, I'd rather write callbacks than deal with threads any day. And there are plenty of approaches to make dealing with callbacks easier (async.js is one of many).

<comment><USER2> Actually, "deal with it" is fucking lame, isn't a response at all, and is a good example of why I use the term "fundamentalism."

Is your problem with threads or shared mutable state? Web applications should be stateless and can be written as long request-response pipelines on-top of a pool of actor threads, with the only shared state existing at either ends of the pipeline, probably hidden by a framework anyways.

<comment><USER4> The "deal with it" is the same for threads - if you're using a system with threads you have to deal with them and it's generally not too fun. Node is what it is. It's callback based. I didn't mean the "deal with it" in a hostile way, more like that's the kind of system node is so deal with it. Is node great for every kind of problem? No. Definitely not. Actors are great too (and they've usually got threads in them, but they are well contained). But for certain kinds of apps node and the careful use of callbacks work out great. I guess I was trying to counter all of the hating on callbacks - they're not so awful when you get used to them.

<comment><USER5> Tamejs makes it a bit easier to deal with. Life doesn't have to suck.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> It seems a bit cruel that he mentions "horror stories" about Twisted; most of the culture shock people complain about with Twisted is exactly the kind of flow-control shenanigans that he describes in Node.js. In fact, Twisted makes those particular examples easier.

To handle branching flow-control like 'if' statements, Twisted gives you the Deferred object[1], which is basically a data structure that represents what your call stack would look like in a synchronous environment. For example, his example would look something like this, with a hypothetical JS port:

        d = asynchronousCache.get("id:3244"); // returns a Deferred
        d.addCallback(function (result) {
    	if (result == null) {
    	    return asynchronousDB.query("SELECT * from something WHERE id = 3244");
    	} else {
    	    return result;
    	}
        });
        d.addCallback(function (result) {
    	// Do various stuff with myThing here
        });

Not quite as elegant as the original synchronous version, but much tidier than banging raw callbacks together - and more _composable_. Deferred also has a .addErrback() method that corresponds to try/catch in synchronous code, so asynchronous error-handling is just as easy.

For the second issue raised, about asynchronous behaviour in loops, Twisted supplies the DeferredList - if you give it a list (an Array, in JS) of Deferreds, it will call your callback function when _all_ of them have either produced a result or raised an exception - and give you the results in the same order as the original list you passed in.

It is a source of endless frustration to me that despite Twisted having an excellent abstraction for dealing with asynchronous control-flow (one that would be even better with JavaScript's ability to support multi-statement lambda functions), JavaScript frameworks generally continue to struggle along with raw callbacks. Even the frameworks that _do_ support some kind of Deferred or Promise object generally miss some of the finer details. For example, jQuery's Deferred is inferior to Twisted's Deferred: <http://article.gmane.org/gmane.comp.python.twisted/22891>

[1]: [http://twistedmatrix.com/documents/current/core/howto/defer....](http://twistedmatrix.com/documents/current/core/howto/defer.html)

<comment><USER3> Here's a library in JavaSCript that does this. <https://github.com/kriszyp/promised-io>

The differences between your example and the common JavaScript practice for promises (when they're used; most of the time they aren't) are that _then_ is used instead of _addCallback_ and that chaining is available and taken advantage of.

<comment><USER6> What do you mean by 'chaining'? Twisted's Deferreds provide at least a couple of things one might casually describe as 'chaining'.

<comment><USER7> Instead of:

      d.then(func1);
      d.then(func2);

You can use:

      d.then(func1).then(func2);

<comment><USER6> Ah, yes. Twisted's Deferreds _do_ support that kind of chaining, but I didn't use it in my original snippet because I didn't want to have an example of a Deferred where no Deferreds were actually visible. :)

In my own code, I tend not to use chaining because "methods returning self" is not a common idiom in Python (although tools like jQuery have given it currency in the JS world) and because I haven't yet figured out a way of formatting a multi-line method invocation that doesn't look messy.

</comment></comment></comment></comment></comment><comment><USER8> This is a pretty common pattern for any work you have to do asynchronously, pretty much all libraries should be implementing this for you so the first 3 lines should be all you code

       getSomething("id", function(thething) {
           // one true code path
       });

       function getSomething(id, callback) {
         var myThing = synchronousCache.get("id:3244");
         if(myThing) {
             callback(null, myThing);
         } else {
             async(id, callback);
         }
       }

a minor quibble with language style isnt exactly what I would call "A Giant Step Backwards"

<comment><AUTHOR> I heartily agree - I may have overstated my case slightly with the "Giant Step Backwards", it just definitely seemed that way on initial experience.

It also made for a better title than "Confusion, Then Indifference, Slowly Turning Into Understanding & Affinity"

<comment><USER9> It's kind of a dick move to make a inflammatory, flamebait blog post and then later admit you didn't actually know what you were talking about. Maybe you should have actually understood the technology you were working with before making knee-jerk snap judgements.

<comment><USER10> How was your first experience with node.js different than Fenn's?

<comment><USER11> Honestly, if you have ever done anything substantial in JavaScript then asynchronous functions with a callback pattern should not be such an issue.

Perhaps if your background is more on the lines of traditional server-side web development (ie. PHP, Django, Rails) then this is some new territory.

</comment></comment></comment></comment></comment><comment><USER12> In my experience Node.js is more difficult than synchronous code. But it's also, by far, the easiest way to get something running that's massively parallel.

I recently wrote a project that needs to do 100's or 1000's of possibly slow network requests per second. The first try was Ruby threads. That was a disaster (as I should have predicted). I had an entire 8-core server swamped and wasn't getting near the performance I needed.

The next try was node. I got it running and the performance was fantastic. A couple orders of magnitude faster than the Ruby solution and a tenth of the load on the box. But, all those callbacks just didn't sit right. Finding the source of an exception was a pain and control flow was tricky to get right. So, I started porting to other systems to try to find something better. I tried Java (Akka), EventMachine with/without fibers, and a couple others (not Erlang though).

I could never get anything else close to the performance of Node. They all had the same problems I have with Node (mainly that if something breaks, the entire app just hangs and you never know what happened), but they were way more complicated, _harder_ to debug, and slower.

I have a new appreciation for Node now. And now that I'm much more used to it, it's still difficult to do some of the more crazy async things, but I enjoy it a lot more. It's a bit of work, and you have to architect things carefully to avoid getting indented all the way to the 80-char margin on your editor, but you get a lot for that work.

<comment><USER5> > I recently wrote a project that needs to do 100's or 1000's of possibly slow > network requests per second. The first try was Ruby threads. That was a > disaster (as I should have predicted). I had an entire 8-core server swamped > and wasn't getting near the performance I needed.

I don't mean to be offensive, but welcome to at least the 1980s. We've known this doesn't scale for ages. The fact that you even tried it and thought it might be a viable solution just shows your education has failed you. I am highly biased against Node, I think it is a giant step backwards. Every blog post I have read that says the opposite admits they have no experience in anything else so they just default to Node being good. I only hope Node is a fad.

<comment><USER13> > The fact that you even tried it and thought it might be a viable solution > just shows your education has failed you

This holier-than-thou attitude is exactly the thing that prevents more people from becoming educated on these kind of subjects. Knowledge and experience on these kinds of subjects are _not_ trivial and are _not_ easy to obtain! Information about what scales, what does not, and why, are scattered all over the place and difficult to find. It may be very obvious to you after you already know it but it's really not. If, instead of spending so much time on declaring other people as dumb or uneducated, people would spend more time on educating other people, then the world would be much better off.

<comment><USER5> If I told you that the Sun revolved around the earth, would you consider it holier-than-thou to tell me my education has failed me? The knowledge that the original solution (threads in Ruby for handling large numbers of concurrent connections) does not work is not a secret. Even with a peripheral following of Ruby it is well known that this solution would not work, not only is the base Ruby implementation slow but threads have been a known issue in it from day one. The solution is so misaligned with the problem that it is really difficult to validly argue this knowledge is too difficult to find. Yes, scaling to Twitter is another issue, but we're talking about the basics here.

But don't put words in my mouth, I didn't call anyone dumb, I said his education has failed him. This could be himself failing to properly research the problem space, it could be his school for not properly introducing him to the subject, it could be a whole host of things. I never argued he was incapable of learning (clearly he did). And I do spend a lot of time educating people, don't take a singular snapshot of a comment on HN as indication of how my entire life is spent.

<comment><USER13> If 99% of the world doesn't know that the Sun revolved around the earth, and knowledge of that fact is scattered across a handful of monks in obscure monasteries, then yes that would indeed be a holier-than-thou attitude. And that's exactly what's going on with scaling knowledge.

I would even argue that the Ruby threading problems he's experiencing may not necessarily because Ruby threads don't scale, but possibly because he's using them wrong or because he's not using the right version of Ruby. Ruby 1.8 uses select() to schedule I/O between threads so the more threads and the more sockets you have, the slower things become because select() is linear time. The use of select() also results in a hard limit of about 1024 file descriptors per Ruby 1.8 process. Also, context switching in Ruby 1.8 requires copying the stack. Ruby 1.9 is much better in this regard since it uses native threads and no longer uses select() to schedule threads that are blocked on I/O. I'm running a multithreaded, multiprocess Ruby (1.8!) analytics daemon that generates 12 GB of data per day. It flies. VMWare CloudFoundry's router is written in Ruby + EventMachine. That thing has to process tons and tons of requests and they've found Ruby + EventMachine to be fast enough. To simply say "Ruby doesn't scale and is slow" is too simplistic, and ignoring the underlying more complex reasons would result in one bumping against the same problems in a different context. So no, it isn't so obvious from day 1 that using Ruby would be a problem.

<comment><USER5> If you think scaling to a few thousand concurrent connections is some closely guarded monk secret then you are making my point all the stronger: our education is failing. The C10k document was released in 1999. That is 12 years we've known how to handle 10k concurrent connections (bare in mind this is not the exact use case mentioned above). Twisted came out a similar time ago. Libevent dates back to at least 2005. Erlang first appeared in 1986, and Erlang was just abstracting how people were already solving concurrency issues into a language. This stuff is not hidden or elite or privileged information. How is it that your average HNer can spout off reasons why NoSQL is claimed to be superior to an RDBMS for _scalability_ yet doesn't seem to know the fundamental concepts? Our education is indeed failing the current generation of programmers if they don't know the basics for a topic that the internet is flooded with.

Finally, I didn't say "ruby is too slow and doesn't scale", I pointed out that the various issues with doing things fast in Ruby have been known for a long time, even to someone only following Ruby. What I did say was that the basic approach the original commentor chose is known to not scale (which it didn't). This is a fundamentally different approach than the VMWare product you mentioned which has chosen a solution similar to Twisted. This approach is known to scale far superior to the original solution.

<comment><USER13> I've read C10K years ago. I don't consider it a useful educational document. It doesn't go deep enough into the subject and it doesn't describe well enough _why_ things like threading don't work well. I all had to find that out through experience (of writing a web server myself), and even now some things are still blurry. C10K is very old, it doesn't describe recent advances in threading implementations. Why are threads unscalable? Is it because of context switching overhead? Because of the VM addresses required for the thread stacks? Because of frequent CPU cache flushes? C10K doesn't go into those kind of details and it doesn't look like many people know the answer. I suppose I can find out by studying the kernel but frankly I have better things to do with my time, like actually writing software and making a living.

Furthermore C10K is not the complete picture. It describes only connection management, not what you actually do with the connection. The latter plays a non-trivial role in actual scalability.

<comment><USER5> Nobody said C10K is the end-all-be-all on scaling, nor should it be. It is also false that it doesn't present any arguments for why threads don't scale well. According to the change log the latest change was 2011 which added information on nginx, but the last change prior to that was 2006. That version of the document talks about memory limitations on using threads because of the stack size. While not extensive it also includes a quote from Drepper about context switches. It even points to documents that are pro-threading. My point is that it's been around for 12 years and is easily found and read by anyone. It also contains a plethora if links to more information on the subject. To claim that C10K is not a useful educational document is absurd. But C10K is one document, there are numerous ones out there, a google search away, our knowledge of scaling has anything but stagnated in the last 12 years. Your options aren't C10K or read the kernel source for your favorite OS.

If you're going to argue that those with knowledge need to distribute that knowledge better, that's fine. Knowledge can almost always be distributed better, perhaps someone could make a nice centralized website that has better information than highscalability.com. But at the same time you've just told me that a document that is a great introductory resource on scaling connection handling is not a "useful educational document". You may have better things to do with your time than read kernel source, but is your time so precious you can't do some google searches? Perhaps read an industrial white paper or academic paper on the subject of scalability? You can write all the software you want but if you're ignorant of how to overcome scalability problems are you accomplishing much? And if you're doing tests and learning about what scales but keeping it to yourself you are just as culpable of not educating people.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER3> Nice article. Be sure to read the comments, as the author links to a library that makes the second example easy to rewrite in a short and elegant way. <https://github.com/caolan/async#forEach>

Also the first example, the cache hitting and missing, could be rewritten with _async_ , too.

        async.waterfall([
          function(callback) {
            asynchronousCache.get("id:3244", callback);
          },
          function(myThing, callback) {
            if (myThing == null) {
              asynchronousDB.query("SELECT * from something WHERE id = 3244", callback)
            } else {
              callback(myThing)
            }
          },
          function(myThing, callback) {
            // We now have a thing from the DB or cache, do something with result
            // ...
          }
        ]);

<comment><USER14> Excuse me, but that's what you call elegant?

From a readability standpoint I'll take the "old" version any day:

       function getFromDB(foo) {
          var result = asynchronousCache.get("id:3244");
          if ( null == result ) {
             result = asynchronousDB.query("SELECT * from something WHERE id = 3244");
          }
          return result;
       }

</comment></comment><comment><USER15> Just curious, is there a good futures library for Node? If so, you could write code of the form:

        x = db.getFutureResult("x");
        y = db.getFutureResult("y");
        whenFuturesReady([x,y], callback(x, y) {
            useResults(x,y);
        });

This looks reasonably similar to typical synchronous code,

        x = db.getResult("x")
        y = db.getResult("y")
        useResults(x,y)

but it allows db queries to happen simultaneously and doesn't break the node paradigm.

<comment><USER16> It never became production ready, but I found this article an interesting discussion of the problem and a solution to it in Coffeescript:

[http://gfxmonk.net/2010/07/04/defer-taming-asynchronous- java...](http://gfxmonk.net/2010/07/04/defer-taming-asynchronous-javascript- with-coffeescript.html)

</comment></comment><comment><USER17> It's unfortunate that Node doesn't use actor based coroutines. Most of the code readability issues would go away.

<comment><USER14> Count me in.

There's a die-hard core of callback proponents (especially in twisted- and lately in node-land) who claim the pure callback-style is more predictable, robust and testable.

This is not my experience. I've been through that with twisted (heavily), some with EventMachine and some with node.js.

The range of use-cases where I'd benefit from that style was extremely narrow.

For most tasks it would turn into a tedium of keeping track of callbacks and errbacks, littering supposedly linear code-paths with a ridiculous number of branches, and constantly working against test-frameworks that well covered the easy 90% but then fell down on the interesting 10% (i.e. verifying the interaction between _multiple_ requests or callback-paths).

I'm sticking to coroutines where possible now (eventlet/concurrence) and remain baffled over the node-crew's resistance against adding meaningful abstractions to the core.

I like javascript a lot (more so with coffee), but I see little benefit in dealing with the spaghetti when that doesn't even give me transparent multi- process or multi-machine scalability.

And to prevent the obligatory: Yes, I know about Step, dnode and the likes. They remain kludges as long as the default style (i.e. the way all libraries and higher level frameworks are written) is callback-bolognese.

<comment><USER17> The best implementation of concurrency that I've used: [http://www.iolanguage.com/scm/io/docs/IoGuide.html#Concurren...](http://www.iolanguage.com/scm/io/docs/IoGuide.html#Concurrency)

</comment></comment></comment><comment><USER18> It's possible to have the best of both worlds by using node-fibers (<https://github.com/laverdet/node-fibers>) and mixing synchronous and asynchronous styles as appropriate.

I believe that JavaScript could become the dominant language on the server. We just need to have a set of consistent synchronous interfaces across the major server side JavaScript platforms. This would allow for innovation and code reuse higher up the stack.

I'm doing my bit by maintaining Common Node (<https://github.com/olegp/common- node>), which is a synchronous CommonJS compatibility layer for Node.js.

</comment><comment><USER19> I would rather have seen "Async programming or Node.JS is hard to 'get right'" than a "Step backward" - which I don't see it being at all.

</comment><comment><USER5> Nitpick: Node doesn't do anything in parallel, it can't, it does things concurrently.

<comment><USER20> But, um, concurrently means "at the same time," too. Merriam's first definition is actually "running parallel."

Wouldn't it be better to describe it as running serially, using non-blocking asynchronous function calls? Guess that doesn't really roll of the tongue, though.

<comment><USER5> In computer science the two terms are generally distinguished, while you're free to redefine them commonly when people say concurrency they refer to a model of performing things at the same time but may not actually be simultaneous. Parallelism is generally the actual act of it running simultaneously.

<comment><USER20> Fair enough, I was unaware of the common distinction in the CS domain.

</comment></comment></comment></comment><comment><USER21> When you write an async. server in C++, where you can't inline functions, you write functions like OnRead(), OnWrite(), etc. Once you get used to it the whole thing ends up fairly easy to read and understand. Eg.

[https://github.com/scalien/scaliendb/blob/master/src/Framewo...](https://github.com/scalien/scaliendb/blob/master/src/Framework/TCP/TCPConnection.cpp)

I guess the OP is saying inlining [in a language where this is even possible] leads to unreadable code, which sounds about right.

</comment><comment><USER22> Not to nitpick but the linked article's title is "NODE.JS - A GIANT STEP BACKWARDS?". That question mark is important.

</comment><comment><USER23> I would write something like this:

      function handler(yes, no) {
          return function (err, data) {
              if (data) {
                  yes(err, data);
              }
              else {
                  no(err, data);
              }
          }
      }

      function get() {
          function done(err, data) {

              // do something with data

          }
          function db() {
              asynchronousDb.query("SELECT * fomr something where id = 3244", done);
          }
          asynchronousCache.get("id:3244", handler(done, db));
      }

</comment><comment><USER24> Though async event driven programming is somehow confusing in the beginning, there are some idioms that could make your code more comprehensible.

My experience (mostly in perl - EV,AnyEvent, etc.) is that combining evens with finite state machines gives more structured code, with smaller functions that interact in predefined manner.

</comment><comment><USER25> The V8 team is thinking of adding yield/defer support to make programming in Node neater. There's hope yet.

Meanwhile there are other choices that are about as easy, like Python libraries and Google's Go. Too bad they don't have the same zealous community support.

<comment><AUTHOR> Hmmm, interesting! I hadn't heard about that - Do you have a reference URL?

<comment><USER25> <http://youtu.be/seX7jYI96GE?t=52m35s>

Mentions they're working closely with the node team here. And that whole talk is about fixing up JavaScript into a modern language, remove the weird syntax quirks around classes, modules, etc. Say what you mean instead of the weird closure soup.

</comment></comment></comment><comment><USER26> While I am also drawn to NodeJS, I wonder if it wouldn't make more sense to use a language that supports coroutines. Not sure which ones would apply - probably Racket, as they seem to do everything?

</comment><comment><USER27> I liked the post, sans the attention-grabberish title (which made me read the darn thing to begin with, though ;)

</comment><comment><USER28> If you're interested in keeping up to date with the project I describe below, please follow me on twitter @NirvanaCore.

I had many of the same concerns with node.js. Every time I attempted to wrap my head around how I'd write the code I needed to write, it seemed like node was making it more complicated. Since I learned erlang several years ago, and first started thinking about parallel programming a couple decades ago, this seemed backwards to me. Why do event driven programming, when erlang is tried and true and battle tested?

The reason is, there isn't something like node.js for erlang, and so I set out to fix that.

For about a year I've been thinking about design, and for a couple months I've been implementing a new web application platform that I'm calling Nirvana. (Sorry if that sounds pretentious. It's my personal name- I've been storing up over a decades worth of requirements for my "ideal" web framework.)

Nirvana is made up of an embarrassingly small amount of code. It allows you to build web apps and services in coffeescript (or javascript) and have them execute in parallel in erlang, without having to worry too much about the issues of parallel programming.

It makes use of some great open source projects (which do all the heavy lifting): Webmachine, erlang_js and Riak. I plan to ship it with some appropriate server side javascript and coffee script libraries built in.

Some advantages of this approach: (from my perspective)

1) Your code lives in Riak. This means rather than deploying your app to a fleet of servers, you push your changes to a database.

2) All of the I/O actions your code might do are handled in parallel. For instance, to render a page, you might need to pull several records from the database, and then based on them, generate a couple map/reduce queries, and then maybe process the results from the queries, and finally you want to render the results in a template. The record fetches happen in parallel automagically in erlang, as do the map/reduce queries, and components defined for your page (such as client js files, or css files you want to include) are fetched in parallel as well.

3) We've adopted Riak's "No Operations Department" approach to scalability. That is to say, every node of Nirvana is identical, running the same software stack. To add capacity, you simply spin up a new node. All of your applications are immediately ready to be hosted on that node, because they live in the database.

4) Caching is built in, you don't have to worry about it. It is pretty slick- or I think it will be pretty slick-- because Basho did all the heavy lifting already in Riak. We use a Riak in-memory backend, recently accessed data is stored in RAM on one of the nodes. This means each machine you add to your cluster increases the total amount of cache RAM available.

5) There's a rudimentary sessions system built in, and built in authentication and user accounts seem eminently doable, though not at first release. Also templating, though use any js you want if you don't like the default.

So, say, you're writing a blog. You write a couple handlers, one for reading an article, one for getting a list of articles and one for writing an article. You tie them to /, /blog/article-id, and /post. For each of these handlers, any session information is present in the context of your code.

To get the list of articles, you just run the query, format the results as you like with your template preference and emit the html. If it is a common query, you just set a "freshness" on it, and it will be cached for that long. (EG: IF you post new articles once a week, you could set the freshness to an hour and it would pull results from the cache, only doing the actual query once an hour.)

To display a particular article, run a query for the article id from the URL (which is extracted for you) and, again this can be cached. For posting, you can check the session to see if the person is authorized, or the header (using cookies) and push the text into a new record, or update an existing record. Basically this is like most other frameworks, only your queries are handled in parallel.

The goal is to allow rapid development of apps, easy code re-use, and easy, built-in scalability, without having to think much about scalability, or have an ops department.

This is the very first time I've publicly talked about the project. I think that I'm doing something genuinely new, and genuinely worth doing, but its possible I've overlooked something important, or otherwise embarrassed myself. I don't mean to hijack this thread, but felt that I needed to out my project sometime. A real announcement will come when I ship.

If you're interested in keeping up to date with the project I describe above, please follow me on twitter @NirvanaCore.

EDIT TO ADD: \-- This uses Riak as the database with data persisted to disk in BitCask. The Caching is done by a parallel backend in Riak (Riak supports multiple simultaneous backends) which lives in RAM. So, the RAM works as a cache but the data is persisted to disk.

<comment><USER29> > The reason is, there isn't something like node.js for erlang, and so I set > out to fix that.

That is not true, see: <https://github.com/hookio/hook.io>, been in development in Node.js for over two years.

<comment><USER5> I really don't see how hook is anything like Erlang. It just seems like a thin message queue on top of node.

</comment></comment></comment><comment><USER30> I think it's a job for the jquery team, a node.js for the rest of us. Once they get jquery mobile out the door it would seem to be the most obvious next project.

<comment><USER31> node.js is node.js for the rest of us :) jQuery smooths out browser inconsistencies and replaces an overly verbose API (DOM). node.js has neither of these issues.</comment></comment>


Ask HN: How do you produce product demo videos? - <AUTHOR> I would like to show a product demo video (screen capture) on my homepage. Seems like this is a common requirement. Can anyone share some advice from their experiences?
What software do you use to produce the videos? Any free solutions? What resolutions worked well for capturing text in a browser? Streaming or progressive download? Any other hints? <comment><USER2> +1 for CamTasia (Windows) and ScreenFlow (Mac), also RecordMyDesktop (Linux). CamStudio (free Win) ok. Online solutions (screencastomatic, screentoaster, jing) also good. I'm a professional screencaster (<http://procasts.co.uk>) - if you want to crib examples, see my Examples page, they all reflect live use of screencasts that make users happier, convert more visitors, reduce support costs etc. Definitely get a good mic - I prefer pro audio equipment but you'll go a long way with a decent USB mic (not 3.5mm jacks, they get electrical noise from the motherboard). If you can't do good audio yourself then see something like voices.com for outsourcing but melding the video+audio can be problematic. You _do_ need good audio, as others have said the easiest way to kill your presentation is muffled, noisy, volume-changing hard-to-understand audio. Expect 1 day to do a first reasonable video of a few minutes, several days if you want a perfect cut with great audio, a bit more if you want to add effects (captions, fades, highlights, scrolls). Look at ShowMeDo for 800+ examples of screencasts made by many users on different OSs with different tools. Jolt Magazine has three useful articles: [http://joltmagazine.com/2008/10/08/lets-make-a-screencast- th...](http://joltmagazine.com/2008/10/08/lets-make-a-screencast-the-final- cut/) [http://joltmagazine.com/2008/09/23/lets-make-a-screencast- pa...](http://joltmagazine.com/2008/09/23/lets-make-a-screencast-part-one/) [http://joltmagazine.com/2008/09/17/screencasting-an- expert-r...](http://joltmagazine.com/2008/09/17/screencasting-an-expert- reveals-the-dark-art/) See LongTail video player (<http://www.longtailvideo.com/players/jw-flv-player/>) to embed flv/mp4 result, they have great plugins, it works with thickbox/lightbox, stats tracking possible, lots of features, I use it for all my work.

<comment><USER3> That was a really great reply, thank you

</comment></comment><comment><USER4> Aside from all the technology, it's crucial to get a solid, professional voice-over that tells a clear story about your product. My personal experience has been that even the best video production can be quickly tarnished by a voice-over that is casual, meandering, or inconsistent. For our demo video, we first sketched out what points we wanted to make in the video, wrote a draft script, then recorded nearly an hour of screen footage. My colleague then spent a couple of days locked in a room with iMovie and a microphone. We ended up with a five minute video that I think really captured what we were trying to do with our product. We used ffmpeg for conversion to mp4+h264 (and a fallback to flv), and the very respectable JW flash video player. I think Snapz Pro X was used for video capture.

<comment><USER5> Seconding this. Use x264 (or an application that uses it, like ffmpeg) and make yourself an mp4 video that plays in Flash. Having low quality for a product demonstration video simply isn't tolerable--and yet it's amazing how much people tolerate awful quality internet video despite the fact that one doesn't actually need a lot of bandwidth to achieve reasonable quality. JW Player is of course a great tool, and takes literally 30 seconds to set up.

My standard toolchain is ( x264 -> rawvideo + faac or NeroAACEnc -> aac audio ) -> mp4box -> mp4 file. For those who are commandline-phobic, there are many GUIs to streamline the process; for example, MeGUI can produce Flash- compatible H.264 video files with x264.

Make sure you're using the latest versions of the encoders as well, especially if you're trying to get away with a much more fancy video than the one in the parent--it's better quality and compression for free.

Also remember that Flash supports H.264 all the way up to High Profile, so there's no reason not to use all the features.

(aside: above video uses a ~2007 version of the encoder, according to my detection tool)

<comment><USER6> See my comments on using .f4v instead of .mp4 here: <http://news.ycombinator.com/item?id=443542>

NB: This comment was made after this thread went dormant. This cross-post is for the benefit of anyone browsing the archives..

</comment></comment></comment><comment><USER7> We use Screenflow. Mac-only, but quite awesome: <http://www.telestream.net/screen-flow/overview.htm>

Has a/b editing, records lots of things as separate tracks and has a special- purpose video editing interface just for screencasts.

Editing interface is a little quirky to get used to but the results are great.

<comment><USER8> Seconded. Definitely the best option if using a Mac. Make sure you get a decent mic: since you'll still be grabbing your voice from the old-fashioned analog world.

<comment><USER9> Care to recommend a good USB mic?

<comment><USER10> Snowball: [http://namm.harmony- central.com/WNAMM05/Content/Blue/PR/Snow...](http://namm.harmony- central.com/WNAMM05/Content/Blue/PR/Snowball.html)

and Snowflake: <http://www.bluemic.com/products/snowflake>

I own the former. Kinda wished I owned the latter.

</comment></comment></comment></comment><comment><USER11> Jing (jingproject.com) is the only free solution I know of. Wasn't exactly what we wanted, so we used Screenflow, which is $99 and Mac only as has been mentioned. It's very easy to use and the editing options are great.

Once you have the video, there's obviously still the decision of how to get it onto your site. After trying a couple different methods, I settled on YouTube. My primary objection to this originally was the video quality, however there is a way to force embedded video to play in either "High Quality" which I found acceptable, or in HD, which is great (and what we ended up using). To do this, you append "&ap=%2526fmt%3D22" for HD or "&ap=%2526fmt%3D18" for high quality onto the back of both links in the YouTube embed code. (more here: [http://www.mydigitallife.info/2008/11/20/how-to-embed-and- pl...](http://www.mydigitallife.info/2008/11/20/how-to-embed-and-play-720p-hd- high-definition-youtube-videos-fmt22-code-hack/)).

Lastly, we used lightwindow to diplay the video (<http://www.stickmanlabs.com/lightwindow/>). Just drop some js and css files into your site and follow the following example code (in the case of HD). Mess with the width and height as appropriate.

<a class="lightwindow page-options" title="My Demo" params="lightwindow_width=640,lightwindow_height=385, href="[http://www.youtube.com/v/vifE3sBge8k&hl=en&fs=1&...](http://www.youtube.com/v/vifE3sBge8k&hl=en&fs=1&rel=0&ap=%2526fmt%3D22);

</comment><comment><USER12> If you find the other recommendations here a bit more than you were looking for, have a look at Wink:

<http://www.debugmode.com/wink/>

<comment><USER13> Wink is quite cool, and I especially like how easy it is to edit, cut-n-paste, and work with the images.

</comment></comment><comment><USER14> I'm a freelance developer, but a couple of months ago, one of my customers asked me to make some screencasts of the product we're building.

I tried Camtasia and Adobe Captivate on Windows. Camtasia has been best to work with, although it has a couple of pretty horrendous bugs that require nonobvious workarounds that took me a while to learn. On the bright side, it has a great set of online video tutorials (duh) and it's easy to do transition effects and record from Powerpoint.

The other commenters are right -- the hardest thing to do well is the voice- over. You need a good mic -- USB digital mics are probably best, but I've gotten by OK with a good headset. You also want a quiet place -- digital "noise removal" post-processing makes me sound like the Predator. One day when I was at a shared office, I spent the morning standing in the bathroom, recording audio to my laptop.

It's also vital, of course, to have an engaging script and a product that's interesting to watch. Writing and filming the screencast will force you to concentrate on these things from the perspective of a new user, and you should take that opportunity to ferret out any needless distractions.

</comment><comment><USER15> For best results you need not relay on just software solutions. Think about visual composition first. I can't give you any useful url, but start here [ [http://faculty.cua.edu/johnsong/hitchcock/pages/montage/mont...](http://faculty.cua.edu/johnsong/hitchcock/pages/montage/montage-1.html) ] and you can google more.

</comment><comment><USER16> CamStudio is an open-source capture program for Windows that records to .avi, with the option to convert to .swf. <http://camstudio.org/>

(See also: <http://news.ycombinator.com/item?id=133349>)

</comment><comment><USER17> We're producing some for our online image sales app and websites. You can see a few recent ones here:

<http://www.nextproof.com/holidays/>

I use ScreenFlow and it's incredible. Very easy to record and create zooms/transitions.

For technical ones, I record the audio myself. I have an AKG 3000 studio microphone that goes into an ART TubeMP pre-amp. The pre-amp then goes to my MacBook Pro. I've found that it's better to record the audio _after_ the video.

We were also lucky to find a great voice-over person on Craigslist. Usually, we just send him the video file and a rough script with a few time markers for guidance. He does a GREAT job and is not very expensive (especially compared to how many takes I require). I would definitely recommend going this route if you can.

</comment><comment><USER18> I was recommended the following service <http://www.screentoaster.com/> Didn't try it personally yet, but let me know what you think of it if you end up using it.

</comment><comment><USER19> I use Camtasia (<http://www.techsmith.com/camtasia.asp>). It costs $299. It is hands down the best. It has a technology called SmartFocus which zooms in to where the mouse cursor is. This is very useful with youtube's limited real estate. Definitely put your product demo on youtube. You get exposure from markets that you may be unaware of. You can see where I've used SmartFocus here:

<http://www.youtube.com/watch?v=cL9qS6bAMPU>

</comment><comment><USER20> Are you looking for screencasts or videos of desktop apps of sort? I am not sure what people use for screencast softwares, but the Railscasts guys seem to be creating some neat looking ones. You might want to ask them. I know the LearningRails.com guys personally, and they do a great screencast too. There is a free HYperCam for Windows, but result is not all that impressive. Adobe has something called Captivate, which will let you create some FLV/F4Vs I believe.

<comment><AUTHOR> Hi, I'd like to do a screencast, played back through a Flash player. The Railscasts are neat but they're not embedded in the browser. From your email, it sounds like Captivate might do the job although I'd have to pay for it. Any advice on progressive download versus streaming for playback?

Thanks!

<comment><USER20> Sorry for late reply - (I would love if HN sends me an email everytime someone replies to one of my threads). Flash video streaming is a big deal. Not many are doing it. Most of them (including Youtube) are doing progresive download. Once again Adobe has Adobe media server, which lets you stream flash video content.

</comment></comment></comment><comment><USER21> I'd actually recommend Captivate from Adobe (it was a Marcomedia product). The reason being is it's awesome for mastering videos. It seems to run acceptably in VMWare fusion too.

I've used iShowU to capture video on my Mac but then mastered it into Flash files. You can add pauses, description, etc.

Screenflow also seems really bad ass from my limited experience with it if you are happy with doing 100% Mac demos.

</comment><comment><USER22> I use XVidCap, edited with KDENlive, then uploaded to youtube and embedded that. All free (using ubuntu)

<comment><AUTHOR> Thanks - I think the only problem is the resolution on YouTube is not very good. I followed the link through your profile to your YouTube video and although it's nice, for my purposes I'd like the text to be clearer on the video.

<comment><USER23> There's a post here with some hints on getting high quality up on YouTube: [http://nerdwithnolife.blogspot.com/2008/09/how-to-get- high-q...](http://nerdwithnolife.blogspot.com/2008/09/how-to-get-high-quality- link-on-youtube.html)

</comment></comment></comment><comment><USER24> There's a great screencast about how to screencast over at peepcode.com ($9)

</comment><comment><USER25> Blue SnowBall (usb mic) + Audacity + Camtasia.

Start with the written dialogue, record it meticulously then do the visual.

The Blue Snowball referral came from Scott Chacon at GitCasts. Great piece of equipment. Thanks Scott.

</comment><comment><USER26> SnapsProX is pretty good.

<comment><USER27> We use Snaps also. I'd definitely recommend it.

</comment></comment><comment><USER28> I'm a big Camtasia fan. Like the interface and the capabilities.

It's not cheap, but I think you can get it as 30-day trialware. Not sure.

</comment><comment><USER29> Email Demogirl.com. She will do the job for you (assuming she likes your application) and get you a few beta users.

<comment><AUTHOR> Interesting. I really like the way her videos zoom in and out on the browser to focus on the important area. Even though the video size is quite small, it works because of the zooming. I think I'll email her and also ask what software she uses!

</comment></comment><comment><USER30> Camstudio is great and completely free. <http://camstudio.org/>

</comment><comment><AUTHOR> Thanks everyone for the excellent replies. I'll evaluate software in the next few days.</comment>


My summer at an Indian call center - <AUTHOR> http://motherjones.com/politics/2011/05/indian-call-center-americanization

<comment><USER2> Old article. The old discussion is here: <http://news.ycombinator.com/item?id=2738462></comment>


What Can We Learn from Ashley Madison? - <AUTHOR> http://www.onthemedia.org/story/what-can-we-learn-ashley-madison/transcript/

<comment><USER2> Or rather: [https://youtu.be/46h7oP9eiBk?t=149](https://youtu.be/46h7oP9eiBk?t=149)

</comment><comment><AUTHOR> This is a piece by _On the Media 's_ Brooke Gladstone from _before_ the AM database leak, June 24, intervewing Paul Ford (of "What is Code" fame).

There's audio if you prefer here: [http://www.onthemedia.org/story/what-can- we-learn-ashley-mad...](http://www.onthemedia.org/story/what-can-we-learn- ashley-madison/)

It's an intelligent piece and hits on many of the themes revealed since:

 _Brooke Gladstone: You wrote that at it 's heart, this problem with protecting our data stems from, essentially, a conflict between the centralized and decentralized Internet, and that we've always been at one end or the other, swinging like a pendulum_

...

 _Paul Ford: See, I read this book in 2002 called Translucent Databases by a guy named Peter Wayner. It 's a short book and it just describes an approach to obscuring data inside of a data base so that it's still useful in some ways. You might know the zip code but not know the street address and so on. The user of the website, they might have full access to it. They can update their name, they can change their address, whatever. They can make decisions about how they want that information to be used as well, but what it really does is scramble the eggs. It's an approach to just hiding and obscuring as much by default as possible, adding lots of garbage and then hashing that all together into a big mess._

 _B: So this idea has been around for a while but these big centralized sites have not picked up on it, I assume because it runs counter to their desire to market the information they 've assembled or to market to their customers._

...

 _PF: ...I 'm starting to wonder (if) maybe the best thing to do is erase my own history, just get rid of it. Maybe that's the only way out for us right now, just to start to travel a little bit lighter, throw stuff away, have less digital footprint._

The key theme I'd like to add is this: _Data is Liability_.

Again and again, that's the message from data disclosures.

An exceptionally peculiar aspect of digital data is that, while it may remain in the boxes and cages provided for it, it's got a notable tendency to find itself liberated. Often without warning, and not detected for days, weeks, months, or longer, afterward (as in this case). In the real world we've got friction, especially associated with data processing and transfer. In digital form, far less so. Sometimes friction is good.

See:

Steve Bellovin's "If it Doesn't Exist, it Can't be Abused" [https://www.cs.columbia.edu/~smb/blog/2014-11/2014-11-11.htm...](https://www.cs.columbia.edu/~smb/blog/2014-11/2014-11-11.html) (h/t Don Marti [http://zgp.org](http://zgp.org))

"Personal data is as hot as nuclear waste" [http://www.theguardian.com/technology/2008/jan/15/data.secur...](http://www.theguardian.com/technology/2008/jan/15/data.security)

Maciej Cegłowski's "The Internet With a Human Face" [http://idlewords.com/bt14.htm](http://idlewords.com/bt14.htm)</comment>


Apple Accidentally Unpatches Vulnerability, Leading to New iOS 12.4 Jailbreak - <AUTHOR> https://www.macrumors.com/2019/08/19/ios-12-4-vulnerability-leads-to-jailbreak/ <comment><USER2> It's unfortunate how Apple and Google approach device ownership, and their attitude towards the concept of general computing is concerning.

We do not control our own devices, we cannot stop certain processes on them, and we do not know where our personal data is sent.

We either have to flash ROMs from questionable sources and apply temporary exploits to get some kind of resemblance of control of our own devices, or we have to spend years to learn the skills to unlock these systems ourselves.

<comment><USER3> I think Apple's approach is the only reasonable one for the general population. The technological complexity of any smartphone is far beyond comprehension for most people. I write iOS software for a living, and even with complete access to the source code, I couldn't reasonably evaluate my iPhone's software - let alone the hardware.

The idea that ROMs from questionable sources make your device safer sounds very strange to me.

Basically every electronic device has countless security issues. Some of them are found of which some are published of which most are eventually fixed (by rather large teams of professionals). In that regard, Apple could and should do better.

But the burden of making such a complex device secure simply can't be put on the end user.

While I would welcome deeper access for technically inclined people, I'm not sure that option can really be given by Apple/Google without the risk of becoming a disadvantage for many users.

<comment><USER2> I think locking down a system by default, but offering a way to gain elevated priviledges, while educating and properly warning users before certain actions is better than taking away everyone's control over their own devices, and therefore restricting their freedom.

<comment><USER4> The problem with that approach is $popular_social_media app comes along and coaxes users to relax said privileges "because reasons" and before long there's a signigficant proportion of users who altered the security model of their device without understanding what is going on.

<comment><USER5> If people do that, that's on them. So long as the device appropriately warns people, I fail to see how it's the companies problem to baby people who don't know what they're doing. It's their device, if they want to break out, let them.

It's like saying "Why should we have knives? It's only a matter of time until $popular_social_media comes along and tells people to cut off their index fingers and before long there's a significant proportion of users who can't point anymore".

<comment><USER6> A lot of tools have safety measures which can't be circumvented by their users (e.g., you have to use both hands to start thems). The reason being that some dangers are easily underestimated, even by experienced users. Manufacturers do indeed much better about the inherent risks of their products than users.

If a knive could be built which allows to cut food, and protects you from cutting off your index finger, wouldn't that be great?

<comment><USER7> Are you really comparing an object which holds a threat of blood loss, loss of organs and possible death as requiring similar safeguards as a phone?

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> I've never understood why iOS isn't more like macOS. There aren't really any technical reasons why this couldn't be.

It's common for the security argument to be used to justify Apple's practices, but Mac users have been perfectly fine installing third party apps such as Transmit, Adobe Photoshop, or even Google Chrome from outside of Apple's walled garden. I've been using macOS since 2007 and I've never had a virus or any security problem, nor anyone else I know using a Mac. From my dev colleagues to my 70 year old mother in law or my 15 year old nephew.

It seems to me the only real arguments for Apple's walled garden are economical.

<comment><USER9> Market share is an appreciable concern here. Macs haven't been more than 20% of the market for a _long_ time. iPhones are a much larger market share, especially among affluent users. I don't think we'd see any widespread viruses, but there would certainly be a ton of people losing their financial info from their own irresponsibility.

<comment><USER8> So your argument is that because there are more users it needs to be more secure?

<comment><USER9> My argument is primarily that if somebody is looking to infect users, are they going to target the 86%, or the 13%? Macs have benefited for years by largely not being targeted by the majority of malware developers. If mobile devices open the walled garden, you get something similar to android's malware issues _at best_.

<comment><USER8> iOS does not have a 86% market share. Not even close. Globally it's closer to 15%. In the US it's closer to 55%.

If you argue that the 86% is the case on certain demographics, then the same can be argued about macOS.

<comment><USER9> The demographic argument is what I'm going with. MacOS is 18%, compared to Windows at 74% [1]. When comparing the mobile statistics, they're bouncing around 50%. The iOS pool would be a _much_ larger pool to attack than MacOS, and for little financial benefit for Apple.

My prediction: If Apple opened the garden, even for a 'developer only' mode, I would imagine unregulated app stores would go up overnight, with wikihow articles on how to enable and install them, followed by a large amount of the technically illiterate (speaking from experience) trying to get free games, or 'add new emojis'. Users can't be trusted, and if consumer desktop operating systems were designed today, they wouldn't have the freedom they currently have.

[1]: [https://gs.statcounter.com/os-market-share/desktop/united- st...](https://gs.statcounter.com/os-market-share/desktop/united-states-of- america) (Not entirely sure on the accuracy/gathering of this data, but it had the easy filtering and seems to line up with both of our data points)

<comment><USER8> > _followed by a large amount of the technically illiterate (speaking from > experience) trying to get free games, or 'add new emojis'_

I agree some people would do it... but I doubt it would be such a large number. Do you have any data about this?

Users can already do that in Windows, macOS, and Android. From my anecdotal experience very few do it.

<comment><USER9> > I agree some people would do it... but I doubt it would be such a large > number. Do you have any data about this?

No, nothing more than anecdotal. But I'd argue 'some people' when you're operating on the scale of the hundreds of millions-billions that Apple operates at, would still be hundreds of thousands of support requests from users who have inadvertently made their phone unusable (using some jailbreak tweaks as a reference) to extremely annoying (referencing many android apps that abuse push notifications for advertising).

> Users can already do that in Windows, macOS, and Android. From my anecdotal > experience very few do it.

I used to work IT for a school system, and I had an entirely different experience. Teachers would occasionally ask for help with their personal laptops (without our AD) and they were near universally a minefield of toolbars and adware. There's obviously some self-selection in there, but if the 5% of teachers couldn't handle a computer responsibly, that would be a big problem for Apple if they added more ways for users to screw themselves.

Of course, all this is anecdotal, so I'm not expecting this conversation to really convert either of us.

<comment><USER8> I work in edtech and I can only agree that teachers are some of the more tech illiterate users I've ever seen. :)

But yeah, without any solid data we will both stick to our anecdotal experiences.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> The saddest thing about this is the article presents jailbreaking as an entirely negative thing, while the comments offer a more balanced opinion.

<comment><USER11> For most end-users it is. It allows any compromise of the device to elevate to root privileges.

</comment></comment><comment><USER12> I'm just thankful for a working jailbreak on the latest version with no "Please update your iOS beta version" popup. It's like a dream come true.

<comment><USER13> Absolutely incredible to have a jailbreak on the latest signed version of iOS.

</comment></comment><comment><USER14> No regression tests? ಠ_ಠ

<comment><USER15> It looks like a bad merge in which if there was a test it would've not been merged either.

<comment><USER16> (again). Goto fail comes to mind.

</comment></comment></comment><comment><USER17> >A third security researcher, Stefan Esser said that people should be careful what apps they download from the App Store right now. "Any such app could have a copy of the jailbreak in it," he wrote on Twitter.

Seems a bit overblown when there's a review process in place. I'm sure it's not infallible, but still..

<comment><USER18> Yes, to some extent people should be worried about apps potentially containing exploits, but then again they should be more worried about 0-days than a known vulnerability.

<comment><USER19> > A zero-day (also known as 0-day) vulnerability is a computer-software > vulnerability that is unknown to, or unaddressed by, those who should be > interested in mitigating the vulnerability (including the vendor of the > target software)[0]

Why should a publicly known unpatched vulnerability be a lesser concern than something that you don't know exists?

[0][https://en.wikipedia.org/wiki/Zero- day_(computing)](https://en.wikipedia.org/wiki/Zero-day_\(computing\))

</comment></comment></comment><comment><USER20> Please excuse the tinfoil hat - is there any chance that this vulnerability was reintroduced at the request of the Chinese government to allow easier access to Hong Kong protesters devices?

<comment><USER21> No need for a tinfoil hat or this specific vulnerability.

Any number of backdoors can be introduced with any update for any operating system or app. Generally governments around the world want backdoors and information from companies and companies generally comply.

<comment><USER22> Last time this happened to Apple they fought it tooth-and-nail and at least from what the public knows they were victorious and did not have to add a backdoor.

</comment></comment></comment><comment><USER23> I got a _lot_ of flak here recently for suggesting that maybe security researchers shouldn't be publishing PoCs or deep vulnerability details literally 1 week after the vendor issues a patch.

Here's to hoping that, now that this happened, someone will give this idea another consideration...

(P.S. for those wondering: apparently this is CVE-2019-8605: [https://bugs.chromium.org/p/project- zero/issues/detail?id=18...](https://bugs.chromium.org/p/project- zero/issues/detail?id=1806))

<comment><USER24> But it's been 3 months since the vendor first issued a patch!

<comment><USER23> I mean, I'm not suggesting 1 week should've been 1 month or even 3 months. Those are too short to me too.

But regardless, that's already 3 months people had to design, write, test, and perfect an exploit for it...

<comment><USER25> The exploit was patched in iOS 12.3, not known since 12.3. Apple probably knew for longer, fixed it in 12.3 and reverted the patch (somehow) in 12.4.

If you want to make your point, this is one of the worst examples you can take as it is an old exploit, which has been patched and now works again. The code should be in the public after the patch anyway if a researcher found it.

<comment><USER23> > The exploit was patched in iOS 12.3, not known since 12.3. Apple probably > knew for longer, fixed it in 12.3 and reverted the patch (somehow) in 12.4.

Huh? Am I misreading the timeline? iOS 12.3 was released May 13, and I see the view restriction removed (Label:-Restrict-View-Commit) on May 20... which is almost _exactly_ 3 months ago: [https://bugs.chromium.org/p/project- zero/issues/detail?id=18...](https://bugs.chromium.org/p/project- zero/issues/detail?id=1806#c8) [https://support.apple.com/en- us/HT210118](https://support.apple.com/en-us/HT210118)</comment></comment></comment></comment></comment>


Narrowing Down Clinton's Choices for Supreme Court Nominee - <AUTHOR> https://empiricalscotus.com/2016/10/25/clintonsscotuschoices/ <comment><USER2> Please let it be Obama. I want that guy to stick around a bit longer.</comment>


The Future of Content Management - <AUTHOR> http://asserttrue.blogspot.com/2009/08/future-of-content-management.html

<comment><USER2> Actually, I beg to differ with the author. The problem I've come across with a lot of CMSes is that they have tried to make content so abstract as to make it cumbersome to do anything with it. The only thing that really exists with content is its concrete representation at any given point in time, whether it's HTML, a database table row, or an audio recording. You can't store abstract ideas, but that's precisely what CMSes are trying to do. All the content is broken down into primitive types. Structure and sequence are removed as much as possible. Then more complex content is assembled from these smaller pieces. The problem is, this seems like the right approach but it quickly breaks down.

For instance, I've dealt with CMSes that have tried to remove HTML from their core content only to be forced to store HTML strings in their data stores and use an editor like FCKEdit or TinyMCE in later versions of the product. The problem has never been the extra structure and sequence that HTML lends to the content. The problem has always been that it has been cumbersome to transform this structure and sequence. When someone wants to change their website so an article written on one HTML page is now spread across 5 pages, it shouldn't require them to have to jump through hoops to accomplish this. Or if somebody wants to convert a written article into a spoken recording, a CMS should be able to handle this.

It's alright to store content in its final publishable state of HTML, so long as you make it easy to transform that content into different representations. How you store the intermediary data does not matter. It's the transformations between final content states that are the key. But today's CMSes make it so difficult to transform content. Think about it. How straightforward is it to move a website from one CMS to another let alone from say, a website to a printed book? I honestly think the future of CMSes lies in something that looks a lot like Yahoo Pipes rather than some centralized repository enterprise battleship clunker (can you tell I've had to deal with some crappy CMSes)?

</comment><comment><USER3> How long until someone posts that the "future of CMS" is actually a centralized index, with the data existing wherever it makes sense? Kind of a personal card catalog.

FWIW, that's exactly what I'm working on.

<comment><USER4> Please keep us posted. I've had informal discussions with a mate about just that idea; I'd love to see what you come up with.

<comment><USER3> I'll answer your question and then engage in some shameless self-promotion. I wrote about it after posting my comment. Here's the chunk which answers your question:

Where am I now?

Heh. I mentioned that looking for duplicate files is harder than I thought it would be. I'm actually on my third try. The first one was when I thought "I can do this with a script", the second was with .NET, where I aimed bigger, but found not nearly big enough.

So, I've just completed the work on the file crawler, and the next bit is submitting the crawl results to the index. I've done this part before, and I don't expect it to be particularly hard, but I have to find the time for it. After that, something resembling a UI (I am trying to solve a problem), then put the whole thing out there with a big fat "alpha" disclaimer (probably Apache license, since I'm using so much of their stuff).

And that's what I'm doing, and where I'm at.

Hope this helps.

<http://itgoon.blogspot.com/2009/08/wheres-that-file.html>

<comment><USER5> Along the lines of what you're working on, I think what you really want is a form of network browser capable of locating files stored redundantly across a completely decentralized network.

Done correctly, this would make notions like "backups" completely obsolete, and "my files" would exist on any computer that allowed me to log in to the appropriate service.

Fast, decentralized, redundant network systems are a beast to engineer though, but it's do-able.

Bonus points if you figure out how to let users store private data on such a network, and keep it private, while also allowing them to share specific files with specific individuals or groups of individuals.

Pull that off, and you'll have the holy grail of data storage.

I've only got some rough notes on this; I don't think I'd start trying to actually implement it for another two years yet.

Beat me to it! I'd rather take a vacation. :-)

</comment></comment></comment></comment><comment><USER6> I've tried to solve this on my own and, while it seems simple, it's hugely complex. What I want is just a black box that I can stuff data into and have it be semantically tagged.</comment>


Show HN: The Gentlemen's Alarm - <AUTHOR> http://www.gentlemensalarm.com/

<comment><USER2> This seems pretty damn sexist. Even though the concept may be sound, the positioning undermines any argument the creators might have.

What if I'm a man who wants to wake up to a man's voice? What if I'm a woman who wants to wake up to a woman's voice?

<comment><AUTHOR> Those options exist already</comment></comment>