rr: lightweight recording and deterministic debugging - <AUTHOR> http://rr-project.org/ <comment><USER2> I can't have enough thanks to Mozilla for funding the development of this. This tool works wonderfully and is a time saver when debugging hard to reproduce issue or issue that happens only in the Nth iteration of a method call.

In RR, you just have to reproduce the problem, then put a breakpoint back in time to when the state was good then reverse continue back there. It creates a very narrow window of debugging instead of hours of head scratching.

I wrote many GDB frontend extension for my personal use (they may or may not work for others and may by broken in python3, I am not a python dev). This one is very useful with RR. It allows to log "print" on auto-generated breakpoints then print them into a spreadsheet. [https://gist.github.com/Elv13/92b98579e62f086cd9c12f44e510ca...](https://gist.github.com/Elv13/92b98579e62f086cd9c12f44e510cad0)

It's very useful with RR because you can modify the columns `print` as many time as you like and ask rr to regenerate it without executing again.

<comment><USER3> FWIW Mozilla funded it until 2016 but since then Kyle Huey and I have been maintaining it out of our own pockets while we work on our startup.

<comment><USER2> And thanks for keeping working on it ;)

After having this problem in GNU "high priority" list for a decade, it's nice to see this thing exist. My comment was more about the initial "make it happen" part. To me, `rr` seems like a really non trivial project to get going in the first place. Not a lot of orgs would have taken a risk with this.

<comment><USER3> We deliberately chose a design that could be implemented with a very small team. In fact there has never been more than about one person working full time on rr, usually less. That's one reason we bet on not using code instrumentation, for example.

But yes, Mozilla deserves major credit for supporting us building this crazy thing --- and of course, releasing it.

</comment></comment></comment></comment><comment><USER4> For anyone that isn't aware, this is a brilliant tool. I just wish it supported ARM hardware (as far as I remember there are some interrupts that clobber state, so this can't be used. Please fill in the details if anyone remembers).

<comment><USER5> The upstream issue with discussion about Arm support is [https://github.com/mozilla/rr/issues/1373](https://github.com/mozilla/rr/issues/1373) \-- the underlying problem is that rr's design assumes that if you execute N instructions you'll always deterministically end up in the same place. In architectures which implement atomics via a load-linked/store-conditional loop (including Alpha, Arm, MIPS, PPC,...) this isn't true, because differences at the OS level (eg timing of other interrupts or process scheduling) could cause an ll/sc loop to loop round more often. It's not clear how this could be addressed, because it's pretty deeply baked into rr's design.

<comment><USER3> CPU support for trapping on a failed LL/SC would suffice.

<comment><USER5> Do you have a sketch of how that would work? It seems plausible but I haven't thought through the details. Issue 1373 suggests a perf counter of failed-SC events and looking at "branches taken - failed_SC", which I'm definitely sceptical would be reliable.

<comment><USER3> Sure, I just added it here: [https://github.com/mozilla/rr/issues/1373#issuecomment-43627...](https://github.com/mozilla/rr/issues/1373#issuecomment-436270586)

</comment></comment></comment></comment></comment><comment><USER6> Discussed in 2014: [https://news.ycombinator.com/item?id=8817954](https://news.ycombinator.com/item?id=8817954)

</comment><comment><USER7> This is a great help, I'm using it most of the time. After I got used to it, plain gdb feels incomplete (mostly because rr allows you to reverse-step and reverse-continue even with watch/breakpoints).

</comment><comment><USER8> Is this language agnostic, supporting all GDB's languages, or is there a specific set of languages that it supports?

(GDB supports eg Ada, Fortran and Rust)

edit: I had a look: the web page says "C/C++", there is some evidence on the bug tracker of people using it with Rust. So my own quick peek was inconclusive.

<comment><USER9> Indeed, rr has worked with Rust since at least 2015 ( [http://huonw.github.io/blog/2015/10/rreverse- debugging/](http://huonw.github.io/blog/2015/10/rreverse-debugging/) ), and I see the author of rr around the Rust community enough (I believe he works at Mozilla?) that I doubt this has regressed in the meantime.

<comment><USER10> roc left Mozilla back in 2016. [https://robert.ocallahan.org/2016/03/leaving- mozilla.html](https://robert.ocallahan.org/2016/03/leaving-mozilla.html)

</comment></comment></comment><comment><USER11> I've got an option "\--rr" on my tests that launches the program under rr. So I can debug a failed test in all directions.

</comment><comment><USER12> Can anyone explain how these tools work? How are they recording program execution? Don't they need to keep track of every register, memory address and such? Seems rather complicated.

<comment><USER3> The basic idea is that since CPUs are deterministic, if you report and replay all _inputs_ to a process you don't have to record what goes on inside the process such as registers and memory.

</comment></comment><comment><USER13> Does anyone know if this also supports LLDB? Or is it strictly tied to gdb? I happen to slightly prefer LLDB these days (mainly because its `list` instruction is much much saner)

<comment><USER14> rr is a gdb protocol server. By default, rr also executes gdb client and automatically connects to server, but you can use -s PORT option to run rr in server only mode.

As I understand, after rr is running in server only mode, you can connect to it on gdb with "target remote :PORT", or on LLDB with "gdb-remote :PORT". I haven't tested this, but it should work as long as LLDB implements gdb protocol in a compatible manner.

</comment></comment><comment><USER15> It reminds me of the ReVirt [1] paper read in an advanced OS class (actually mentioned in the slides). I didn't watch the complete talk. Wondering how much is it different from ReVirt and other record debugging tools.

[1] [https://www.usenix.org/legacy/events/osdi02/tech/full_papers...](https://www.usenix.org/legacy/events/osdi02/tech/full_papers/dunlap/dunlap.pdf)

<comment><USER16> ReVirt logs non-deterministic inputs at the hypervisor level. RR will be recording these inputs at the Kernel level. So this makes the inability to replay the OS execution the biggest difference.

<comment><USER17> Interestingly, hypervisor-level logging of this stuff is both harder (because it has the constraints of kernel-level code) and simpler (because the non- deterministic behaviours are fewer and better-documented at the hardware level than the Linux API level!)

I think it's very likely that, overall, recording a single process is substantially more complex to implement than recording a whole VM. (With significant caveats - recording a whole VM with good performance is going to be _hard_ and making it really useful probably is a whole load of extra code)

</comment></comment></comment><comment><USER18> The site is almost unreadable on mobile. Font too thin, doesn't scale and most importantly, the contrast is way too low.

</comment><comment><USER19> In theory (!), Goland recently added support for reverse debugging of Go code via rr:

[https://youtrack.jetbrains.com/issue/GO-3831](https://youtrack.jetbrains.com/issue/GO-3831)

Haven't tried it out yet myself, but I'd expect it to be at least functional. :)

</comment><comment><USER20> How does that compare to undo.io ?

<comment><USER21> Undo has some features rr doesn't have. It supports shared memory operations. It works in virtual machines and "in cloud". It imposes less strict requirements on kernel or CPU features, for example, it works on AMD. Fundamentally, what differs UndoDB and Undo Live Recorder from rr is the architecture based on machine code instrumentation.

<comment><USER17> Actually, I _think_ rr supports shared memory operations under some circumstances... (I'd love to have my beliefs confirmed / corrected by somebody more knowledgeable)

My understanding is that rr has some handling for read-only shared memory and for arbitrary sharing within a tree of recorded processes.

Undo's shared memory is different because it doesn't need the other process to be recorded, so you can do read/write sharing with arbitrary processes or devices.

(disclaimer: current Undo engineer)

<comment><USER3> You're correct.

</comment></comment></comment></comment><comment><USER22> There is also a low level tool, disassembler and debugger, radare2 [1]. It also allows to record the session in both debug and emulation sessions and replay it[2].

[1] [https://github.com/radare/radare2](https://github.com/radare/radare2)

[2] [https://radare.gitbooks.io/radare2book/content/debugger/revd...](https://radare.gitbooks.io/radare2book/content/debugger/revdebug.html)

<comment><USER3> radare2 lets you take snapshots of memory and registers and restore them, but it doesn't let you, say, record the entire execution of multi-process Firefox from startup to shutdown and later replay that perfectly. It's not capturing the effects of the environment that you need to make that work.

</comment></comment><comment><USER23> A very useful tool that has saved me a lot of trouble. Sadly I can't use it anymore since I switched to a Ryzen CPU.

<comment><AUTHOR> What makes it unusable on Ryzen?

<comment><USER3> Ryzen's performance counters aren't quite accurate enough for rr to use. [https://github.com/mozilla/rr/issues/2034](https://github.com/mozilla/rr/issues/2034)

I hope that AMD will fix this one day.

</comment></comment></comment><comment><USER24> Last time when I checked, rr did not support multi-threaded application well. Has that changed now?

<comment><USER3> rr supports multithreaded applications, but only uses a single core. So parallel applications slow down.

<comment><USER25> Being slower is not, I think, the major downside. It is that an entire class of errors - race conditions - are basically outside of the scope of the tool. Which is understandable! Race conditions are hard, and when I read about the tool, my first thought was "How are they handling race conditions?" and it turns out, essentially, they're not. But race conditions are also the hardest part about debugging multithreaded applications.

I'm not sure if the tool ensures deterministic scheduling of threads on the single core, but I doubt that it does. If it does not, then playbacks will not be deterministic on playback, which means you could encounter different race condition outcomes on playback. If it does, then while you may have deterministic playback, the tool is unlikely to help with the class of race conditions that require simultaneous execution.

To be clear: I'm not criticizing the tool or the work of the people. If I were to design such a tool, I would probably start with a single core as well. It seems like a valuable tool and great progress for software debugging. But I do think race conditions in multithreaded programs are a current limitation.

edit: The technical report says that they deterministically schedule threads ([https://arxiv.org/pdf/1705.05937.pdf](https://arxiv.org/pdf/1705.05937.pdf)):

 _" RR preemptively schedules these threads, so context switch timing is nondeterminism that must be recorded. Data race bugs can still be observed if a context switch occurs at the right point in the execution (though bugs due to weak memory models cannot be observed)."_

The "weak memory model" part means it won't help with, say, debugging lock- free algorithms where you screw up the semantics.

<comment><USER3> You should read [https://arxiv.org/abs/1705.05937](https://arxiv.org/abs/1705.05937) so you don't need to speculate. rr absolutely does guarantee that threads are scheduled the same way during replay as during recording, otherwise it wouldn't work at all on applications like Firefox which use a lot of threads.

Also, rr definitely is very useful for debugging race conditions. For example Mozilla developers have debugged lots of race conditions using it. One thing that really helps is rr's "chaos mode", which randomizes thread scheduling in an intelligent way to discover possible races. See [https://robert.ocallahan.org/2016/02/introducing-rr-chaos- mo...](https://robert.ocallahan.org/2016/02/introducing-rr-chaos-mode.html) and [https://robert.ocallahan.org/2016/02/deeper-into- chaos.html](https://robert.ocallahan.org/2016/02/deeper-into-chaos.html) and [https://robert.ocallahan.org/2018/05/rr-chaos-mode- improveme...](https://robert.ocallahan.org/2018/05/rr-chaos-mode- improvements.html).

<comment><USER25> Very cool stuff! And yes, I took a look at the paper, as I noted in my edit. But I think there's still two classes of race conditions outside of its scope: ones that require simultaneous execution (where you can get surprising interleavings) and lock-free algorithms where correct use of the memory model is paramount. In my personal experience, these are the hardest problems to debug.

<comment><USER26> Even those are probably not 100% outside of its scope. I forget the details of chaos mode, but that kind of induced thread-switching can cause just the kind of interleaving you seem to be talking about.

What rr cannot capture is a very small subclass of race conditions involving things like cache line misses - I think that's what you're alluding to by "correct use of the memory model is paramount" but it's a subclass even of those. Yes, those are hugely difficult to diagnose and it would be fantastic if tools like rr or UndoDB could capture them. But there's a vast swathe of also very difficult race conditions that this recording tech can and does help with today.</comment></comment></comment></comment></comment></comment>


Lua: the world's most infuriating language? - <AUTHOR> http://www.slideshare.net/jgrahamc/lua-the-worlds-most-infuriating-language <comment><USER2> ... that is the _strangest_ collection of complaints I've ever seen about Lua. He obsesses over minor syntactic quibbles like the lack of a += operator and the ~= and "not" instead of C's inexplicable exclamation marks (how does this man stand SQL?) but he doesn't dwell on Lua's bigger flaws.

I mean, 1-based arrays, weird scoping and the pairs/ipairs thing seems far more serious than the lack of a proper conditional operator (how long did Python go before it got a conditional operator?)

Lua is everything it was meant to be - a lightweight, user-friendly, safe language that runs nice and fast in spite of being very hashtable-oriented. There's a good reason it's heavily used as a scripting language for game engines and other platforms that need to let users run code provided by other users - a more "batteries-included" language would have users wiping each other's filesystems.

<comment><USER3> 1 based indices are fine most of the time, they are mostly like 0 based yet start at 1 :) When it does become a problem is when you are reading and using binary formats and offsets, where I seem to always get off by one errors. A ternary function, iff, is soo simple to implement Lua. Scoping is just something you have to understand as with tables there is no problem with them besides a beginners understanding of them.

What you consider a minor gripe, compound assignment operator, I personally think is a flaw in the language same goes for bitwise functions instead of operators. Here is an example I posted earlier on twitter.

object = object + other

"object" and "other" here are full userdata and the code is going to malloc a new userdata and also create a new object in C/C++; which is straight away going to over write the original instance. Huh? why? += makes so much sense.

Each to there own, I can fix my issues using patches but it would be nice if I did not have to.

<comment><USER4> Might I ask, how would you implement a ternary function that should retain the lazy evaluation quality of the syntactic ternary operator?

</comment></comment></comment><comment><USER5> So why is Lua so much faster than Python? I tried searching about this but primarily people discuss historical context. I'm curious about real language features and whys.

<comment><USER6> Mike Pall is behind Luajit.. Get him or Lars Bak to work in a jit compiler and you language will be fast as it can be..

Of course, bad designed language in terms of performance will suffer more to get into the state-of-the-art

<comment><USER7> Mike Pall has noted design decisions of Python which make it much harder to optimize than Lua in the past: [http://lua- users.org/lists/lua-l/2004-11/msg00083.html](http://lua- users.org/lists/lua-l/2004-11/msg00083.html)

<comment><USER5> Thank you, that's the kind of stuff I was looking for.

</comment></comment></comment></comment><comment><USER8> I've heard almost all of the complaints before and had a few of them myself. But before tearing this guy a new one for rattling off a list of trivial- sounding complaints, be aware that the second half of the presentation extols the virtues of Lua and advises you to "get past the initial irritation."

</comment><comment><USER9> I felt the same way, but I used MoonScript for a simple hack project and it removed a lot of the Lua annoyances. ([http://moonscript.org/](http://moonscript.org/))

</comment><comment><USER10> The video is here, although the sound quality is not great, sorry [http://www.youtube.com/watch?v=_pOkOAq5jfM](http://www.youtube.com/watch?v=_pOkOAq5jfM)

</comment><comment><USER11> Well played. Title intentionally plays off the "question mark in title means answer is no" meme.

</comment><comment><USER12> I think of it as the C of scripting languages. You have to roll a lot of your own stuff.

<comment><USER13> I think that a better analogy is the Scheme of script languages.

<comment><USER14> I always felt that Scheme was the Scheme of scripting languages. Or is Scheme rather the Lisp of scripting languages?

<comment><USER15> One of my favorite Scheme reads was an e-mail discussion on whether it was possible to add OOP to a functional programming language, and then the author goes on to do so in a trivial amount of code. A cursory search doesn't turn up the exchange I had in mind though, or I would link it.

</comment></comment></comment></comment><comment><USER16> It's weird that I see many people complaining about tables because of pairs/ipairs or trivial stuff like that, which are more nuisances than anything. The flexibility of tables/metatables make them a very powerful data structure (not unlike javascript's prototype). I've been playing a bit with it for game development and you can build some very powerful stuff just using tables.

Maybe instead of trying to use lua as another language, you should totally embrace "the lua way" and then you'll understand why their tables/metatables is the way it is.

</comment><comment><USER17> If you can't get past the initial complaints, try squirrel.

[http://www.squirrel-lang.org/](http://www.squirrel-lang.org/)

It's basically Lua, with his complaints fixed.

</comment><comment><USER18> I have to save I've loved using lua recently, in my console mail-client. Being able to apply operations to messages, and do interesting things is great:

[http://lumail.org/examples/](http://lumail.org/examples/)

Sure there are warts, such as the lack of "+=" or "++", but once you get into the right state of mind it is a pleasure to work with.

</comment><comment><USER19> You get past most of these syntax nitpicks after a while. I wrote plenty of Lua at my previous job, but every once in while would still forget about globals by default. I really would love to know why they went ahead with that design decision, when most languages take a far more conservative approach to variable scoping.

<comment><USER11> Store the environment in "global" table. Make a new environment. Point the __index of the new environment at the global table. Make __newindex of the new environment a function that throws an error.

Congradulations, you have metaprogrammed lua to only set globals explicitly. Good job!

</comment></comment><comment><USER20> Learning Lua reminded me a lot of Javascript. They're both weird languages with a very similar object model, and they're both very practical once you get past the initial hurdles. They both have some issues, but they also have plenty of redeeming features.

</comment><comment><USER21> I wonder if he knows that he can write a loader to fix all this stuff.</comment>


How NPR's new website stores html markup separated from content in the database. - <AUTHOR> http://blog.programmableweb.com/2009/11/11/content-portability-building-an-api-is-not-enough/

<comment><USER2> I'm really hesitating to comment. It's way too easy for us types to miss really good ideas due to our preconceptions. But it's hard for me to look past the fact that this looks like a really bad abstraction over the top of the structure document abstraction that was designed specifically to suit NPR's purpose.

For example, they show the <em> tag being stored by position in the database separately from the content itself, seemingly unaware of the significance that <em> is a _semantic_ tag. It means _emphasis_. If the iPod doesn't like <em> for emphasis, well then that's why it's a _semantic_ tag. You can remove semantic tags or replace them with alternative markup or binary formats as needed because they have meaning designed for parsing and formatting.

It's all well and good to hate on XML for inappropriate uses. But, critical point here, documents are _what XML is for!_ And there is a shocking wealth of libraries in just about every language available today that will handle document markup just fine.

It seems to me to be a quintessential reinvention of the wheel, and the XML hating has just gone on too far at this point.

<comment><USER3> It's a lot cheaper to insert your markup by position than to parse the XML on every read. Of course, caching would mitigate much of that, but still I admire the design.

<comment><USER4> You wouldn't even have to parse the XML -- just anoint one form the canonical internal representation and then have filters which turn the internal representation into other formats.

For example, if you store all documents in a restricted version of HTML, then you can generate a text-only version by replacing all <em> and </em> with star, etc. This is much cheaper than actually parsing XML (no need to build up a data structure representation of the document, just assume it is mostly right already and apply textual transformations).

Then, once you have the plaintext version, cache it. Journalism sites are going to have an _absurd_ number of reads to writes. (One guy writes the article, one guy edits it, 50,000 people see it within a minute of it being posted.) Caching is cheap and easy. Caching is robust against the article changing, too -- you purge the cache (or potentially just let it expire) and bam your new article is mostly right, whereas tracking the offset of <em>s seems to intuitively have a lot of possible failure modes to me. (For example, the first time one of your reporters tries to add a bit of local color with Japanese text in an article, I'll bet dollars to donuts that every tag after the Japanese breaks and the surrounding content gets corrupted.)

</comment></comment></comment><comment><USER5> That just seems really fragile to me. Yank one space off the front of any article and the entire thing is jacked. I'm just not convinced that it's all that terrible to parse the markup on the way out if you need it transformed, while enforcing strict rules on what (valid) markup can go in.

<comment><USER3> Either way, you would have to parse it into something equivalent to what they are storing in the database so you you could handle the various target formats individually.

As long as you tightly control writes to the database, I don't see the problem. And, you don't have the overhead of parsing on every read. For an environment where reads will be a few orders of magnitude greater than writes, it does make some sense.

<comment><USER6> It seems incredible that they can't sacrifice some speed to parse on every read, and yet are also unwilling to sacrifice some disk space to cache several fully parsed versions.

Considering how quickly CPU and disk performance change, this type of tightrope-balanced optimization seems crazy. Or maybe they're way smarter than me.

</comment></comment></comment><comment><USER7> This is clearly working for them. What is interesting about this is that it puts a vote on the SGML idea that content and presentation are nicely separated and identified by the tags. But this has always faintly concerned me, as to whether this really will work.

As an example madair in an earlier comment notes that _em_ is intended to be a _semantic_ tag. But do the semantics of this particular tag ever mean anything outside of "show this text as emphasized"?

I am wondering if whatever semantic markup we do is still all about presentation, and takes a fairly arbitrary abstraction of what the text is to _mean_.

<comment><USER2> It's a twist, but if we say that an iPod _cannot_ emphasize text, then we can instruct the system to ignore <em> tags. Because the semantics of <em> are clearly defined, a judgment call is available to us to feel confident that we can ignore the tag completely under the circumstances. So we utilize the tag itself still by instructing the system to swallow it.

<comment><USER7> See, this is what I find a bit unclear. The concept is that presentation is distinct from content. But if we say that the _semantics_ of the em tag are to effect the presentation, they seem to be not be separated anymore, right?

<comment><USER2> At a certain point the semantics of the content get translated into an output format. In a browser it's italic. In an iPod it's ignored.

The semantic tags are the means, but output presentation is still the end, and there's certainly no reason to expect that all devices can take the original semantic markup and use CSS or some other mechanism to present it. And because of the semantic meaning we can make the em disappear with confidence.</comment></comment></comment></comment>


Why Startups Fail: An Analysis of Post-Mortems (2011) - <AUTHOR> http://foundersblock.com/anecdotes/why-startups-fail-an-analysis-of-failure-post-mortems/

<comment><USER2> This could be more accurately titled, "why entrepreneurs thought they failed." Personally, I'm not sure failed entrepreneurs are qualified to make that diagnosis.

<comment><USER3> Seems unnecessarily cynical. For many categories of mistakes, it is not hard to see the mistake in hindsight.

<comment><USER4> specifically relationships between founders and investors would only be known from the parties themselves.

an objective third party analysis miss personal problems between founders 1 and 2

</comment></comment></comment><comment><USER5> Quote: _#2 – Built a Solution Without A Problem (i.e. No "Market Need")

Choosing to tackle problems that are interesting to solve rather than those that serve a market need was often cited as a reason for failure. Sure, you can build an app and see if it will stick, but knowing there is a market need upfront is a good thing. "Companies should tackle market problems not technical problems_

I am trying to figure out how to think more clearly about this type thing and write about it. I am sorry to see so little discussion here on HN for this submission.

<comment><USER6> Since the beginning of hacker news this has been one of the most discussed topics here. Paul Graham's essays are a good place to start.

<comment><USER5> I am aware of his essays. I am trying to think and talk about something specific, let's call it Memology for the moment. I am not talking about start- ups per se but more about he architecture of ideas and how we separate the wheat from the chafe. I have explored that in terms of human psychology for myself. I would like to explore it for the business space. I hope it will be of interest to other people at some point.

Thanks.

</comment></comment></comment><comment><USER7> Original discussion: [https://news.ycombinator.com/item?id=7244605](https://news.ycombinator.com/item?id=7244605) (incidentally, submitted by the same person)

<comment><AUTHOR> Yes. Having come across it I submitted that, and then someone pointed out the original source, so I submitted that instead (here). Now that original submission is dead.

For completeness, the one comment on that first submission was by compare[0] saying:

        The list sounds more predictive
        than descriptive.

[0] [https://news.ycombinator.com/user?id=compare](https://news.ycombinator.com/user?id=compare)

<comment><USER8> _Having come across it I submitted that, and then someone pointed out the original source, so I submitted that instead_

Why?

<comment><AUTHOR> Not sure I understand your question. The guidelines[0] say:

        Please submit the original source. If a blog post
        reports on something they found on another site,
        submit the latter.

Having realized that what I'd submitted wasn't the original source I attempted to correct that oversight. Just seemed the right thing to do.

[0] [http://ycombinator.com/newsguidelines.html](http://ycombinator.com/newsguidelines.html)

<comment><USER8> Personally, I don't really care about the guidelines all the time. If you take that overly literally, then nobody could submit anything that referred to something else via a link. I get the need to eliminate outright "blogspam" but not everything that comments on "something else" is blogspam.

If somebody reports on something and adds useful commentary, insight, whatever, I don't see the point in insisting on some arbitrary standard of "only link to most upstream source". It's not like people aren't capable of following links.

</comment></comment></comment></comment></comment><comment><USER9> Copy of post. Original here -

[http://www.chubbybrain.com/blog/top-reasons-startups-fail- an...](http://www.chubbybrain.com/blog/top-reasons-startups-fail-analyzing- startup-failure-post-mortem/)

</comment><comment><USER10> What about not being able to raise that first round?</comment>


Show HN: Serverless OAuth on a Github page - <AUTHOR> http://oauth-io.github.io/oauth-js/index.html

<comment><USER2> It's not exactly serverless. You're just using their server instead of your own. To make this work you have to give oauth.io your private keys. That said, I love the simplicity of this implementation. OAuth is still way too hard to implement by hand.

<comment><USER3> I think they mean serverless here more about the user experience because the user doesn't have to install a server to make it possible.

Because there is here as you mentionned Oauth.io server, but also Github server and lots of other servers for fonts/librairies etc...

Nothing is technically "serverless" on the web ;)

</comment></comment><comment><USER4> This is misleading. There is 2 types of OAuth2 "flow", sometimes called server-flow and client-flow. Server-flow is the mechanism where a callback is registered with the auth server, but all comms and the initial auth have to go through some other server, which is just being setup for you in this case.

Client-flow is the far more interesting flow, for me, anyway. There the browser client gets the token directly from the auth server, that really is serverless. The key advantages of client-flow are you don't need the immediate server (less cost for you) and you don't have to see the data if you're using a third-party storage (better security and privacy).

You do need to be careful with security issues around the auth token itself, in server-flow you store the token on the server and have the session bind you to that token. Stealing a session is harder than stealing a token.

I know of two implementations to date:

Google's Official JavaScript Client library [0]

Dropbox's Unofficial JavaScript library [1]

[0] [https://code.google.com/p/google-api-javascript- client/](https://code.google.com/p/google-api-javascript-client/)

[1][https://github.com/dropbox/dropbox-js](https://github.com/dropbox/dropbox- js)

</comment><comment><USER5> Can I use this to fix my python-gist script which needs a GitHub OAuth token but is not really supported because it's a console app?

[https://github.com/voltagex/python-gist](https://github.com/voltagex/python- gist)

Edit: Yes, I can. Until I get 100 users of the script, then I'd have to shut it down.

</comment><comment><USER6> this looks amazing, if only it would support gmail and yahoo as those are the two big use cases for me :) Couldn't find the "provider wishlist page" that you mention on the FAQ page. Overall, great job making this dead simple. Will definitely be using it in side projects!

</comment><comment><USER7> It should handle the case where the authorisation is denied, as currently the oauth.io server spits out an unfriendly

      Invalid format

</comment><comment><USER8> Definitely using this - super helpful for quick prototypes, thanks.</comment>


IT Companies in my town in South Eastern Europe (Nis, Serbia) - <AUTHOR> http://www.expertaya.com/2011/09/25/it-companies-in-my-town-nis-serbia-eastern-europe/

<comment><USER2> I had no idea IT sector is developed that much in Serbia. Thanks for posting.

<comment><AUTHOR> Thanks for reading. Actually, it's the only sector that is alive here and I really hope it'll be even better in the future. Good thing is that Nis has a decent airport close to the center (3km) and that means you're ~2 hours away from most places in Europe.</comment></comment>


Show HN: Using computer vision to detect birds in parks - <AUTHOR> http://code.flickr.net/2014/10/20/introducing-flickr-park-or-bird/

<comment><USER2> xkcd is a pretty great programming language. You draw the feature that you want, and then the internets implements it somewhere, somehow.

<comment><USER3> But the difference is only one person can use it.

<comment><USER4> My professors used to joke about the "Grad Student" programming language all the time.

</comment></comment></comment><comment><USER5> Speaking of CV + birds, I knew the guys behind a small company called Ornicept.

Basically, wind turbines kill birds. To protect birds, you have to collect data on birds in the area. The standard way of doing this was literally putting a guy in a lawn chair for a few hours each day counting birds, and then extrapolate the numbers.

They put some cameras in the field and run CV on the footage to count the birds instead. Cameras are cheaper than people in lawn chairs, apparently. I don't know if they still do this, but it was their initial product.

</comment><comment><USER6> Almost :) [http://imgur.com/gDWXo08](http://imgur.com/gDWXo08)

</comment><comment><USER7> Looks like it does quite well (on good images with closeup of a single bird).

Some fails:

[http://i1-news.softpedia- static.com/images/news2/Washington-...](http://i1-news.softpedia- static.com/images/news2/Washington-Woman-Sues-Duck-Owner-for-275K-200K-After- the-Bird-Attacked-Her-439085-2.jpg)

[http://fc04.deviantart.net/fs71/i/2012/181/1/e/eyes_on_a_bir...](http://fc04.deviantart.net/fs71/i/2012/181/1/e/eyes_on_a_bird_by_mikatrta-d55fdtd.jpg)

A couple that barely made it:

[http://www.jlvaillant.com/Animals/Birds/Egrets- Herons/i-CDVT...](http://www.jlvaillant.com/Animals/Birds/Egrets- Herons/i-CDVTkQm/5/L/Bird-000132%20-%20Version%203-L.jpg)

[http://www.nps.gov/calo/naturescience/images/IMG_1399_edited...](http://www.nps.gov/calo/naturescience/images/IMG_1399_edited2.JPG)

On the whole, its very impressive though!

</comment><comment><USER8> [http://i.imgur.com/Svn2bZ4.jpg](http://i.imgur.com/Svn2bZ4.jpg)

Also, Matt Zeiler runs an image recognition startup which the image above was generated from. Check them out at [http://clarifai.com/](http://clarifai.com/)

</comment><comment><USER9> [http://bioexpedition.com/wp- content/uploads/2012/04/Peacock_...](http://bioexpedition.com/wp- content/uploads/2012/04/Peacock_With_Fanned_Tail_600.jpg) wrong

[http://totallygreencrafts.com/wp- content/uploads/2012/11/bac...](http://totallygreencrafts.com/wp- content/uploads/2012/11/backyard-bird-feeder-spring-craft- photo-420-FF0507EFDA01.jpg) returns ???

even [http://howtomakeapapercrane.net/u/paper-origami- crane.jpg](http://howtomakeapapercrane.net/u/paper-origami-crane.jpg) fails!!! OK OK maybe the "NO" is correct this time

<comment><USER10> Heh.. the peacock does a fine job protecting itself... even from computers.

</comment></comment><comment><USER11> Nice. They use deep convolutional neural nets, which is the key algorithm that dominated the ILSVRC 2014. This computer vision contest included, among other challenges, recognizing different bird (and dog and cat and spider and.... ) breeds. There is a blog post about ILSVRC that even uses the same xkcd comic ;) [http://blog.a9t9.com/2014/10/amazing-progress-of-computer- vi...](http://blog.a9t9.com/2014/10/amazing-progress-of-computer-vision.html)

</comment><comment><USER12> I put a picture of some chicken breasts and it didn't recognize it, is it a feature?

Joke aside, incredible work here. Did you do everything from scratch or used some library to get faster results?

</comment><comment><USER13> I'm seeing a lot of pictures of flowers and bees in the bird pictures. I'm guessing this is due to the way the training is done, anyone from Flickr who can comment on that?

<comment><USER14> Some pretty clear bird photos aren't working either; I guess it has to be a close up, which kind of ruins the usefulness for me. [http://rideintobirdland.com/wp- content/uploads/2012/04/Littl...](http://rideintobirdland.com/wp- content/uploads/2012/04/LittleBlueHeron_10.jpg)

<comment><USER15> Also, the _exact_ question you're trying to answer makes a difference. If the question is, "Is this a picture of a bird?" where "of a bird" means that the primary focus of the picture is a single bird, then your picture _should_ return "No". That's different than, "Are there one or more birds in this picture?"

I'm not sure which question Flickr's team actually seeks to answer here.

</comment></comment></comment><comment><USER16> It's cool that a team of deep learning researchers can pull this off quickly. Anyone know of an "image2vec" (word2vec for images) that would empower others to try out similar things? (unfortunately it would need a better name, because "vectorize" means something different for images.)

<comment><USER17> Caffe (and other frameworks) provide exactly this. It's basically:

1) To setup, load a pre-trained AlexNet/Overfeat/other architecture model (e.g. trained on ILSVRC2012)

2) To get a vector from an image, run a forward pass on the images, and extract the activations at a given layer (e.g. fc7) as the output vector.

[http://caffe.berkeleyvision.org/gathered/examples/feature_ex...](http://caffe.berkeleyvision.org/gathered/examples/feature_extraction.html) is a step-by-step walkthrough.

There's a lot of mystique around deep learning and these kind of problems, but it's not _that_ difficult to use these tools.

</comment></comment><comment><USER18> Does not recognize Big Bird. I proclaim this to be a failure.

<comment><USER19> Ha. I tried Big Bird too. Under "For Bird?", it said "It certainly wants to be."

</comment></comment><comment><USER20> Is this something that could be accomplished with the help of CCV?

[https://github.com/liuliu/ccv](https://github.com/liuliu/ccv)

</comment><comment><USER21> Totally not what I was expecting!

What would be very cool would be some kind of trigger app where you leave your phone in a tree for an hour, and it takes pictures of all the birds that come within range.

Detecting whether a given image has a bird in it, while certainly difficult and "interesting" from a CS point of view, is not very interesting from a user perspective? (Photographers can always tag their images when they submit them).

<comment><USER22> The advantage of doing it from a user perspective is that people in practice don't tag their images, but others want to find e.g. CC licensed pictures of blue jays in flight.

</comment></comment><comment><USER23> XKCD requests Park or Park with Bird.

Flickr built service as requested. Web page titled Park or Bird but works as Park or Park with Bird. Who named this thing?

Cool project regardless.

</comment><comment><USER24> Does not work on tablet :(

</comment><comment><USER25> looks like either a typo or a missed edit of a previous figure: [http://imgur.com/FUQru1m](http://imgur.com/FUQru1m)

</comment><comment><USER26> [http://xkcd.com/1425/](http://xkcd.com/1425/)

</comment><comment><USER27> >"Hey, yeah! I went to Rocky Mountain once!" //

Hate this jokey style of response. Is it stating that the image is from Rocky Mountain; Perhaps it's just a random comment-bot statement about national parks? Bleurgh.

Yes, I'm sure there's a demographic that enjoys inane comments written as if the presentation layer was conscious.</comment>


Ask HN: Would you pay for audio recordings of popular Medium posts? - <AUTHOR> Seeing if there is demand as it would most likely be expensive to get voice actors. <comment><USER2> There's [http://play.ht](http://play.ht) that does this..

<comment><AUTHOR> Didn't know about this. Text to speech is pretty bad though. Couldn't get through the first minute.

</comment></comment><comment><USER3> Speech synthesis not good enough?</comment>


Every online form/survey should have an option to choose "decline to answer" - <AUTHOR> Whenever some survey or website asks me why I chose to unsubscribe or anything, my first reaction is "I don't have to tell you anything". IMHO, this should be an industry standard to let people decline to answer questions (like pleading to the fifth but for online behavior) <comment><USER2> Can't remember the last time a "Why" question for email unsubscription _wasn 't_ optional.

</comment><comment><USER3> On many surveys I get frustrated. Often none of their options is correct. As well as the question often does not make any sense.

<comment><USER4> Yes, that is a valid concern too; I find the same thing that some of the questions aren't very good and I wanted to specify a different answer than is listed. Also I agree that sometimes I do not want to answer a question.

In the case of unsubscribing, you should not have to answer any questions at all (except, do you want to unsubscribe); it should be optional. For other surveys it can be different, though; sometimes they need some answers in order for the survey to work.

I started writing a program for doing surveys, but of course that won't prevent people from making up bad questions. It will, however, avoid many other problems that I have seen, and other things that have annoyed me about these surveys. It also allows the same survey to be converted into multiple formats.</comment></comment>


Ask HN: Has your work ever been plagiarized? - <AUTHOR>

I recently had an experience where one of my web projects was copied - not an exact copy but clearly "inspired" by me. My initial reaction was to find some way to call the developer out and/or send an angry email, but in the end I've decided to ignore it and carry on.  Wondering if anyone here had similar experiences and how they dealt with them.  Keep in mind this isn't a huge project, but I've put enough time into it that being ripped-off is painful. Any advice would be greatly appreciated. <comment><USER2> Not my work, but I posted something on a dial up ISP's forum years ago, and a reader there posted it to alt.humor.best-of-usenet. I did a search a few years later, and found it word for word posted on some advocacy site in Washington DC, attributed to a woman who was not me.

I emailed the group, made my case with proof, and said I'd be flattered if they kept it up with proper attribution. I don't recall hearing back, but they took it down pretty quick. I imagine the "author" was a little embarrassed.

I just searched best-of-usenet, but now it's Google, you know, so I wasn't surprised not to find it. I did find it out on the wider web, so, for historical accuracy, it survives here:

[http://www.mail-archive.com/law- email@example.com/msg00390.h...](http://www.mail-archive.com/law- firstname.lastname@example.com/msg00390.html)

(scroll down to You Always Remember Your First)

</comment><comment><USER3> Yes, I once released a P2P product developed solely by me into GPL license. Shortly after that I noticed another guy started another project copying exactly all the source files, and he put a copyright with his name in every single file even when there's no change in the file. Now I was ok if he wanted to fork the project but damn it don't claim credit for work you didn't do. I contacted him to ask him to remove his copyright and he said he's forking the project and there's nothing I can do. I contacted Free Software Foundation and they said there's nothing I can do. That's the way GPL works. I swore then I would never release another GPL project again.

<comment><AUTHOR> Has the derivative project progressed at all? I'm assuming it was copyrighted for the purpose of making money off of your work. Not that it is much consolation, but I would imagine that if it didn't gain much traction, the incident would be somewhat satisfying. They stole but were not able to attract users. That's what I'm hoping for in my situation.

<comment><USER3> No, the forked off project gained no traction. I suspected it was a developer wanting to put some cred under his belt. By putting his name into an open source project, he can claim credit without doing any work. And his resume would look good. He could say, I founded this P2P project (forked) and blah blah blah. People won't know the difference.

</comment></comment></comment><comment><USER4> Yes. I made <http://www.filleritem.com> about 6 years ago. Copied by many people including Slickdeals.net. Not sure if these people were inspired by my website or simply came up with the idea independently. If anything, it forces you to keep your project working properly.

<comment><AUTHOR> That's a great example (and quite a cool tool) - did you decide to continue building it out or did you lose steam after you found the copies?

<comment><USER4> I have iterated on the idea a few times. Mostly I have to make sure that I am keeping up with the new versions of amazon's api(they discontinue old versions every once in awhile) Amazon doesn't have a way(although they have gotten much better) to make the relevant queries so you have to be a little creative to get the tool to work accurately.

</comment></comment></comment><comment><USER5> haha no never</comment>


The fact that we are living in a simulation - <AUTHOR> https://www.infopadd.com/article/the-fact-that-we-are-living-in-a-simulation/1656 <comment><USER2> This is the least compelling argument on the subject I have seen. New-agey religious hokus-pokus. That you can't prove it wrong, doesn't make it plausible - a LOT of things fall into that category including Bertrand Russel's teapot.

How about talking about the mathematical intuition behind simulation theory. If you think it plausible that we will one day create simulations complex enough to contain conscious beings, and you think it likely we are not the only such civilization in the universe, then it naturally follows that simulated universes well out number real ones. Thus we're more likely to find ourselves in a simulated universe than a real one. If you accept the first premise, which is a jump with our current technology, but maybe not a jump out of reach - then one must accept the conclusion as well.

Or one can look at how odd it is that the entropy of a 3-dimensional volume of space is proportional to the surface area - not the volume. That's a counter- intuitive result that strongly suggests our three dimensions are an illusion.

Or even spooky action at a distance - instantaneous communication of quantum state across vast distances is difficult to explain in a physical universe, but could be much easier in a simulation - especially if entangled particles shared some sort of locality inside the computer running it (e.g. adjacent bits in memory.)

</comment><comment><USER3> the issue is not new. but this is the most interesting and deep argument on the subject i have seen to date. now that i have read this, my life will never be the same! lol</comment>


Show HN: chat without contact information - <AUTHOR>

Mobile group chat today is centralized. Most mobile chat apps rely on a central admin to add each person to their address book and then to select contacts to form a group chat. Additionally, if you want to add someone to the chat, you need to pass their contact information on to the admin. So there is an underlying dependence on digital contact information.
The other problem with group chat today is that over time group chats can veer off topic. Group chats can become static never-ending threads, like one long email chain, instead of being topical and then just going away.
What if you could group chat without the exchange of contact information and without the dependence on a central admin? What if the barrier to creating group chats is reduced so that they can be created instantly? How do you get 20 people in a physical room to start chatting instantly, and, by extension, friends who later might want to join the chat?
This is why we built ChatTag (available on the App Store or check us out at chattag.com). Feedback would be awesome. <comment><USER2> Hey guys, I am the co-founder of ChatTag. We would appreciate any feedback.</comment>


A TensorFlow Implementation of DeepMind's WaveNet Paper - <AUTHOR> https://github.com/ibab/tensorflow-wavenet <comment><USER2> Do you know how long it took to train using that dataset and with what hardware configuration?

</comment><comment><USER3> Doing a forward pass for every sample sounds like it would be prohibitive for real-time applications.

<comment><USER4> It absolutely is. DeepMind reported that 1 second of audio generation takes about 90 minutes to generate.

<comment><USER5> Assuming it's computation bound, it's a factor of 5400 (~13 doublings in CPU power required to get to real-time, assuming no algorithmic improvements).

<comment><USER6> Do they mention it was CPU trained? I assumed GPU. If it was CPU trained, I wonder what the operations keeping it off the GPU were?

<comment><USER7> Google has special neural net ASICs now.

<comment><USER8> Google never stated they use those to train models as far as I know. It seems that they are primarily used to spare energy when deploying trained models at scale.

<comment><USER7> Theres no reason they couldn't use them to train, as long as they can account for the lower precision operations. I think it would be much cheaper to train on them, at that scale anyway.

<comment><USER9> Afaik the Google TPU does inference only, at 8 bits. I don't think it's possible to train a neural network at 8 bit precision at this point in time. FP16 works for training though, and is twice as fast as FP32 on certain nvidia chips

<comment><USER7> Backpropagation can work with any precision, as long as you use stochastic rounding (so that the rounding errors are not correlated.) Without stochastic rounding even 16 bits will have rounding error bias.

[http://arxiv.org/abs/1412.7024](http://arxiv.org/abs/1412.7024)

<comment><USER9> OK. I was going by this - [https://petewarden.com/2016/05/03/how-to-quantize- neural-net...](https://petewarden.com/2016/05/03/how-to-quantize-neural- networks-with-tensorflow/)

I haven't seen 8bit training implemented in any (public) frameworks yet - that's not to say it's not possible. If it works then that's great, especially for specialised hardware.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> I had plans to do the same, I'm glad somebody beat me to it.

<comment><USER11> That is an admirable mindset - I cannot help but be a bit frustrated when someone independently implements my ideas first. On the one hand, it validates the idea. On the other hand, building it would be fun, but now that someone else did it, doing it again would be akin to reinventing the wheel and it is more productive to turn your attention to something new (unless you think you can execute the project much better).

<comment><USER12> In this case, it's DeepMind's idea anyway :)

I get more disappointed when the opposite happens. I think something like, "Yeah, I'm totally going to add support in torch for noisy activation functions like in this paper!" ([https://arxiv.org/pdf/1603.00391.pdf](https://arxiv.org/pdf/1603.00391.pdf)). Then I procrastinate and put it off. Then I think, "No matter, someone else has surely done it by now". Then they haven't.

</comment></comment></comment><comment><USER13> Here's a Theano implementation: [https://github.com/huyouare/WaveNet- Theano](https://github.com/huyouare/WaveNet-Theano)

</comment><comment><USER14> I wonder whether accents could be layered on top of the trained data?

<comment><USER15> Probably. You can add in 'speaker' as a bit of metadata to the samples (this is what is meant by 'conditioning on') and teach it to speak like different people, so if you have a diverse sample of speakers and you add in 'accent' as another variable, it might well learn to disentangle individual speakers from their accents and then you can control generated accents by changing the metadata.

</comment></comment><comment><USER16> I'm really interested in building an RNN and training it against something like movies. I'd love to then take it and input a song and translate it to a music video that's a composite. I'm also interested in the legal ramifications of doing such a thing...

Does anyone know of prior art?</comment>


Hitman Runner Convicted of Mob Murder on GPS Watch Data - <AUTHOR> https://www.runnersworld.com/news/a25924256/mark-fellows-runner-hitman-murder/ <comment><USER2> From what I understand the tracker data was from an earlier time when they were gathering intel on the target.

</comment><comment><USER3> Discussion from a month ago: [https://news.ycombinator.com/item?id=18944605](https://news.ycombinator.com/item?id=18944605)

</comment><comment><USER4> Why would someone wear a GPS watch when committing an assassination?

<comment><USER5> It really just emphasizes that our connected devices make it easy for the police to track you. No privacy, even leaving a phone home won't do it.

<comment><USER6> Except for receiving GPS, it's not really a "connected device", seeing as they had to get a warrant to physically search his home and analyze it.

It's really no different from a Sherlock Holmes scene in the killer gets some specific type of mud in his shoes, or something, except a bit easier to decipher :)</comment></comment></comment>


Geoscore open sources mapping code - <AUTHOR> http://geoscore.com/opensource.html <comment><AUTHOR> Creator of geoScore here. We're looking for contributors to help get this code out and help with documentation. I'll do my best to answer any questions. As far as the javascript client, it is almost ready to release, but I'll be a lot more motivated to put the hours in if there's interest.</comment>


Offline Storage Recommendations for Progressive Web Apps - <AUTHOR> https://medium.com/dev-channel/offline-storage-for-progressive-web-apps-70d52695513c <comment><USER2> It is not file cache or local storage the main obstacles for the wide adoption of PWAs, it is the restriction to easily access phone features. Even something as trivial as "take picture + upload" or "get gps data" is currently a pain. Browser and OS vendors argue these restrictions are necessary for user protection yet a gazillion native apps are installed w/out users having the least interest in double-checking what permissions are given to these apps. A gazillion apps, checked and approved by app stores, are already doing whatever the f* they want with user data.</comment>


Big Data Is Big Market & Big Business - $50 Billion Market by 2017 - <AUTHOR> http://www.forbes.com/sites/siliconangle/2012/02/17/big-data-is-big-market-big-business/

<comment><USER2> Their data table has some problems (see: "Think Big Analytics" where $8m of Big Data revenue on total revenues of $12m somehow makes 167%). Apparently the journalist has trouble with Small Data...</comment>


ReMarkable Paper Tablet - <AUTHOR> https://blog.getremarkable.com/better-paper-better-thinking-432d8a283300#.g7jp42ohv <comment><USER2> For those feeling the impulse to empty their wallets, I urge caution. I just got done being burned by the kickstarter for the goodreader equivalent. [https://www.indiegogo.com/projects/13-3-inch-android-e- reade...](https://www.indiegogo.com/projects/13-3-inch-android-e-reader#/)

I see no evidence that the team behind this "remarkable" product has ever completed anything of this scale.

Some of the claims are very suspicious. [https://liliputing.com/2016/11/remarkable-10-3-inch- writing-...](https://liliputing.com/2016/11/remarkable-10-3-inch-writing- slate-goes-pre-order-379.html)

"reMarkable says the screen has 55ms latency for quick response from pen input"

55ms would be impressive for an LCD. Even the iPad Pro has a latency of 60ms [1]. So a 55ms claim for an E Ink panel? Should raise one's alarm detector.

[1] [http://www.anandtech.com/show/9766/the-apple-ipad-pro- review...](http://www.anandtech.com/show/9766/the-apple-ipad-pro-review/9)

<comment><USER3> They're just reusing the hardware module Sony uses on its Digital Paper DPTS1 thingee and putting Android on it. Assuming it's a legit project.

<comment><USER4> no, we don't use Android, unlike pretty much everyone else.

and the EPD is designed by e ink based on our requirements, e. g. the size and high DPI.

<comment><USER2> > no, we don't use Android, unlike pretty much everyone else.

Most companies making EPD products use the base OS provided by their SoC vendor. Based on your spec which says 1GHz ARM A9 , I'm guessing you're using the NXP (formerly Freescale, now Qualcomm) i.mx6 SoloLite since that's the only 1GHz ARM A9 with an EPDC controller on the market. Freescale gives you a Linux EPD and an Android EPD Linux BSP, both of which use the same epdc driver with pretty much the same latency which is definitely pretty high, much higher than 55ms for sure.

> EPD is designed by e ink based on our requirements, e. g. the size and high > DPI

Are you claiming that E Ink manufactured a custom 10.3" panel just for you?

<comment><USER4> Again, I can't discuss too many technical details. But yes, it's an i.MX6SL, I thought we mentioned that on the web page.

And there are actually several drivers for the EPDC available. Two from freescale for the imx6 and imx7 (though there are some other improvements in the _v2, apart from imx7 support). There's also another one written by lab126, but I'm not sure if they actually use it. there's also some minor variations in the drivers in the different kernel branches and trees from NXP. And then you have the u-boot drivers. And I think there might be one in the bare metal SDK, but I haven't looked. And then you have the 5bit waveform support, which is a whole other story (with iffy GPL implications for some vendors I won't name).

And the display was designed based on our requirements, but we don't have any kind of exclusivity on it. there's already other devices coming out with it (you can find them if you google the specs, especially the awkward resolution we got thanks to the limits of the technology and our DPI requirement).

<comment><USER2> > it's an i.MX6SL, I thought we mentioned that on the web page.

Your website only says: "Processor 1 GHz ARM A9 CPU"

> Two from freescale for the imx6 and imx7

Ok, but you are using imx6.

> There's also another one written by lab126

Nope. That's the same driver from Freescale. You can download the kindle source to verify. [https://www.amazon.com/gp/help/customer/display.html?nodeId=...](https://www.amazon.com/gp/help/customer/display.html?nodeId=200203720)

> then you have the u-boot drivers.

u-boot just draws a splash screen.

> you have the 5bit waveform support, which is a whole other story (with iffy > GPL implications for some vendors I won't name).

I don't understand what you're trying to communicate. Why would a EPD waveform have any GPL implications? An EPD waveform is not software, it is a set of timing values and that's it.

> the display was designed based on our requirements

I'm having difficulty understanding what that means. It sounded like you were saying E Ink designed a panel for you, but maybe what you're saying is just that E Ink had a panel that met your requirements.

<comment><USER4> there are two epdc drivers in the kindle gpl releases. the source for the lab126 one is only available in the tarballs you linked (named mxc_epdc_fb_lab126.c).

as for the waveforms, I'm talking about support for the REAGL (sic) waveforms. grep for it in the linux source in the tarballs you linked to.

and e ink did not have a panel that met our requirements, and designed a new one after we talked with them.

edit; just to be clear, we don't use the lab126 driver, it was just an example of there being more drivers for the imx6 generation epdc.

</comment></comment></comment></comment></comment></comment></comment><comment><USER5> I was sold until this line:

"Your thoughts, whether they're words or sketches, are instantly synced to reMarkable's cloud service"

Imagine for a company only five years back to literally say that your thoughts are sent to their server. I welcome any product that understand we need less distractions and less help from so-called AI, but there are many reasons to be cautious about this one (preorder, latency claim and lack of technical details being some of them).

EDIT: After looking a bit more around, their technical claims does seem credible. Their CTO is/was even a developer at KDE, so let's hope they also will support open standards and personal servers. If so then it's literally the device I've always been dreaming of!

<comment><USER4> the reason we're a bit scant on technical details so far is partly because we have spent most of our technical resources on actually making the device. but we'll try to get out a more technical blog post soon.

another reason is that we can't share too much about what we're working on in case some journalist picks up some wording as promising some feature we can't deliver on. a lot of the stuff we're working on is stuff we don't know if we can deliver in time, in a polished enough form. so what we're talking about is what we have already solved, and which we believe is going to sell the device best to the people we target.

lastly, Certain Companies that have tried to do this for years are really, really interested in how we have solved the latency problem, and we don't want to help them.

EDIT:

> Their CTO is/was even a developer at KDE

is, thank you very much (latest commit was to kio on saturday). even if I don't have as much time for KDE stuff as I used to for obvious reasons.

<comment><USER5> Great to hear from you guys directly! I guess we (i.e techie internet folks, you included) have been served so many crowd funded promises that it's difficult to believe things that are too good to be true. Although I'm personally a big advocate of keeping stuff open, I do understand that a small company has to have some secrets for themselves.

Now I see you're also a developer at KDE which certainly gives credibility to your statements! But on the same note I truly hope the information from the device will be encrypted on your server, and that an opt-out of this sync will be possible. And if there will be support for Owncloud or the like, you've literally made my dream device!

I truly understand and support that you don't promise stuff that aren't really made yet, and I really hope the privacy concerns will be taken as serious as they are.

<comment><USER4> > I guess we (i.e techie internet folks, you included) have been served so > many crowd funded promises that it's difficult to believe things that are > too good to be true.

well, I personally have basically stopped contributing to crowdfunding campaigns, I've been burnt a lot. and this is also why we haven't gone public earlier, even when we've been working on this for years.

> I truly understand and support that you don't promise stuff that aren't > really made yet, and I really hope the privacy concerns will be taken as > serious as they are.

well, privacy is very important to me personally (I even have a couple of commits in owncloud), and we've been discussing several ways to protect the privacy. but until we know which way we do it we can't promise anything, even just speculating will lead to people assuming and get angry if we go for something else.

<comment><USER6> I appreciate your approach of avoiding speculation (apart from the mass- production uncertainties) and I've just pre-ordered. I have a couple LCD pen tablets (Samsung Note 10 and Surface Pro 3, apart from a USB Wacom Intuos 3) and a Kobo Aura H₂O, and your device looks like something I'd use often.

Just to give you a little feedback, I don't expect any reply for now:

\- if the cloud sync can not be disabled I'll just nuke the packets at the router, but I suspect the option will be there.

\- I want the SDK (mentioned as possible in your FAQ), unofficial-void-your- warranty all the way to the moon if you want, to have a programmable scientific calculator (maybe with Computer Algebra System functionality if I find the time) on this device. Having to build a complete firmware image in my laptop (Linux) and flashing it just to install my application is acceptable, simply uploading the file as if it was a PDF is better.

<comment><USER4> > apart from the mass-production uncertainties

these uncertainties is why we hired Dragon Innovation early on. they're very, very good at this and has a very good track record when it comes to hardware startups (e. g. pebble and makerbot).

[https://www.dragoninnovation.com/customers](https://www.dragoninnovation.com/customers)

<comment><USER7> Funny you should mention Pebble, a company currently in its death throes. I hope reMarkable survives longer than they do, since I have now pre-ordered from both companies.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> What I would consider the killer features for this, if present (as in, if guaranteed these, I would buy it):

\- The ability to use it as a drawing tablet for another computer. It's already a perfectly good large touch-sensitive surface meant for drawing, why should I need to buy a second one for Illustrator?

\- ssh, and some way to connect an external keyboard. E-paper is excellent for a terminal, and this is big enough to be useful.

\- Some way to use purely as a display, whether by some plug or by X-server broadcasting via SSH or some form of screen-sharing client. Most non-video uses of a computer (if color is not crucial) work just fine on e-paper.

\- The ability to turn off cloud-sync. Sorry, but I'm not sending you everything I write. For some people that might even go deeper than a personal choice (NDAs, if they work on anything proprietary, depending on how they're phrased).

So, basically, the ability to use it for its components and not just the singular agglomeration of them that you envision. I put that above even the ability to write your own software for it.

In other words, if ReMarkable has the following, I would have already pre- ordered, even if it's got nothing else:

\- an e-paper touch display

\- plus Wi-Fi, USB, HDMI, etc.

\- the ability to disable automatic cloud sync

\- with four built-in programs:

\-- ssh

\-- drivers-for-use-as-drawing-tablet

\-- VNC client

\-- The reader/drawing program demonstrated in the video, for use alone

</comment><comment><USER9> I've tried the prototype device, and I'm very excited that this is finally coming to market!

That said, and it might be nitpicky of me, but the choice of micro-USB for charging is a real annoyance. This is a premium device at a premium price point which I'm expecting to keep for many years. USB-C for portable devices is something that I'm considering a must-have at this point. Will probably wait for the first hardware revision.

<comment><USER4> the reasons we decided against usb c are a) the device would have to be thicker, b) our industrial designer didn't like how it would look, and most importantly; c) I still have a hard time finding usb c cables. I always have to bring my own.

<comment><USER9> As for point C: I fully believe that the opposite will be the case in three years time. Just feels a bit... shortsighted. I mean, even Nintendo is going for USB-C in their upcoming device (and even Apple, in their own hamfisted way :P )

</comment></comment></comment><comment><USER10> Wow, the latency looks really bad. You would think that by August 2017 we would be down to sub-frame latency for stylus input. At this point, I would rather use a stylus with a cord if it meant shaving off 10ms. As is, it's just unusable. I know for people that have been in the tablet-input world for a while, 50ms sounds reasonable, but hand this to a kid, and they'll start drawing all over the screen, waiting for the lines to catch up.

I'll be interested in this when the latency and DPI can keep up with the pace of natural handwriting.

<comment><USER11> What if the display sub system organized the screen into partitions and prioritized the redraws based on which partition the input was happening in? If that's where the eye is focused, then maybe any artifact from refresh- neglect in the periphery would go unnoticed.

</comment></comment><comment><USER12> I really want this to succeed. I'd love to buy one. There's been quite a few failed attempts.

From FAQ > own special operating system Codex / We might however release an unsupported SDK for best developers

That's disappointing. I assume "best developers" means corporates. I'd have hoped for a fully open SDK as you're not able to use anything from Android etc. There's probably no end of utilities solo coders would piece together. I'd probably be looking at whether I could make a few apps myself.

I'm a _little_ disappointed at no lighting, it's made a big difference to my eReader. No doubt LEDs would add much to cost.

<comment><USER4> "best developers" was a bit tongue in cheek, it was late and I didn't have time to come up with good wording (I'm not a good word person). but what I tried to convey; we know that even _if_ we can release a toolchain, we can't deliver a full, polished SDK. so "best developers" was more about developers that don't need any hand-holding.

but again; we can't even promise that we have the time and resources to package up a usable toolchain for third-parties.

<comment><USER13> Is it safe to assume that it will be possible to update the firmware on the device so that some updates will be possible after shipping?

<comment><USER4> of course, one of the nice things with modern hardware is that we can deliver more features after shipping the device.

edit; also, it is a device connected to the internet. not supporting updating the firmware would be extremely irresponsible from a security perspective.

</comment></comment></comment></comment><comment><USER14> I really like the idea. But I don't much care for it syncing to the vendor's cloud server. If it would sync in open file formats to my NextCloud instance, then that's attractive.

Also, there's definitely a balance to be struck between lack of distraction and lack of features. It would be a waste for this not to have an epub reader, for example. But while I'd really appreciate having email on it, that's starting to get into distraction territory.

<comment><USER4> about epub, that's one format we're already committed to supporting. it's listed in the FAQ. we're very careful about not over-promising, that's partly why there aren't more features listed.

edit; really besides the point, but saw your nick. our internal name for the prototype (in u-boot and the kernel) is zero-gravitas.

</comment></comment><comment><USER15> This is very reminiscent of the Noteslate vaporware: [http://www.noteslate.com/](http://www.noteslate.com/)

<comment><USER4> except we waited until we had actual hardware prototypes before going public, from an ODM we've been working on for a while. and (some of our team) are on HN, which gives us much more street cred.

and you can find pictures of us. one of the reasons I've been skeptical about the noteslate is because I couldn't really find out who was making it.

<comment><USER16> Will you show your working prototypes at CES then?

<comment><USER4> we went to CES this year to see if there was any reason for us to go, but based on that we decided not to. it's insanely huge and hard to get any kind of exposure, even if people knew about us beforehand.

but seeing is believing, especially with this product, videos doesn't do it justice imho. so we need some way of getting it into the hands of people, probably some kind of ambassadors that have some reach and a lot of integrity. but this has to wait until our ODM finishes the next batches of prototypes, so we actually have devices that we can send out.

<comment><USER17> Please keep us up to date! This is definitely a "try before you buy" sort of product for myself.

</comment></comment></comment></comment></comment><comment><USER18> For those who really want a PDF annotator, Sony sells a large mostly- equivalent of this, there's the Sony DPT-S1

[https://pro.sony.com/bbsc/ssr/product- DPTS1/?PID=I:digitalpa...](https://pro.sony.com/bbsc/ssr/product- DPTS1/?PID=I:digitalpaper:digitalpaperproductpage)

This is a pro device, costs almost $1000. I don't own one but a friend does... it's very magical looking, and feels nice for the 2 minutes I used it.

<comment><USER4> they've been dumping the price and trying to empty their warehouses, so I'm not sure if you can actually buy it anymore. at least not outside of japan.

<comment><USER19> If your device works well as a PDF annotator, it's going to have a _huge_ market among academics, who right now have a number of very bad solutions to the problem. For me personally, I'm thrilled by the possibility of being able to write unlimited marginalia.

<comment><USER4> academia is one of the biggest target groups, both in terms of marketing and development focus.

<comment><USER7> Can confirm. I'm in academia and preordered this soon after hearing about it.

</comment></comment></comment></comment></comment><comment><USER20> This looks amazing. If you don't mind, I have a couple questions...

\- I know you're not committing to certain things at this time, but can you confirm yet that a subscription fee will NOT be required for full usage? Ie. If I want to store locally or on Dropbox or Google Drive would something like that be possible? I hesitate to preorder without knowing how your full pricing model might be structured.

\- Is the stylus unique to the device, or will any old stylus work? Also, will it need to be charged separately?

\- Will there be the possibility of low frame rate animations? I could see that being super useful for diagrams.

\- Can you share any insights into the current state of eInk technology with regards to color displays? Is it looking like something that might be commercially viable in the next 5 years? 10?

\- As you acknowledge, this tech will likely be copied pretty quickly. How do you build a business moat around that?

Awesome stuff and excited to see how this turns out.

</comment><comment><USER21> That looks rather lovely. The smart paper tablet that some of us have always wanted.

"Better thinking" might be an overstatement, but it is quite a hassle to doodle on a computer, and I do find that I think slightly differently while handwriting.

</comment><comment><USER22> Hi. I am a paper guy too. Until this thing hits the market wide, gets lots of positive reviews and has its costs reduced, does anyone have tips for managing lots of real paper? I feel like some organization tricks could help ease dealing with paper problems.

I use paper to sketch out thoughts and draw diagrams, and I don't want unlimited papers. 5 pages a day is enough for me. I wish I could say I read books - I don't. So I only have to manage papers on which I write things and refer to them quickly whenever possible. It works fine, but if someone has tips to help, please share. Thanks.

<comment><USER23> For a long time I tried to come up with systems for paper. Now I switched to a simpler model: my (only) clipboard I used for the project I focus one, eg. writing my master thesis. I also bought two thin soft binders. The green one is for research and ideas highly related to my current research or projects. I put some metadata on some of the sheet themselves or on small papers to remind quickly what a sheet is about. The red one is for other all other ideas. Any sheet not is a binder will likely roam on one of my desks and will be forgotten. This is actually a feature, like survival of the fittest applied to desk environment.

</comment></comment><comment><USER24> This is huge! I don't want to sound contemptuous but to me, paper feels like an inefficient artefact, just waiting to be disrupted by something that can incorporate the few remnant benefits which current range of E-Readers don't cover. I have had Kindle since about an year and I can't imagine ever going to paper books. I can instantly check words, read in the dark, or purchase whenever I like. The only thing I do miss is marking an important passage.

If notes, and highlighting work as advertised, will printed books have anything to offer other than aesthetic value?

</comment><comment><USER25> I understand the pen doesn't attach in any way to the device? Only the Folio does attempt to help keeping them together?

The movies don't seem to do a good job of demonstrating the advertised pressure and tilt sensitivity levels; I didn't seem to notice any variation in line width.

It would be awesome if you could make Stylus Labs Write ([http://www.styluslabs.com/](http://www.styluslabs.com/)) work on your device — or at least steal the ideas (esp. text moving) for your writing app.

<comment><USER26> +1 for the Styluslab software! Having that on the reMarkable tablet would be a real killer.

</comment></comment><comment><USER27> Very much want one, if it materializes I will feel very jealous of today's college students. This would have been a godsend, I would take notes in class, but organizing them was always a pain. I've lost several class notes I wish I kept.

Will hold out until actual products are given to the public, I've seen several pitches for this that haven't materialized. Best of luck though, I will be waiting.

<comment><USER28> I too struggle (and fail) to keep physical papers organised. But I'm not sure why electronic papers should be any easier? Unless there's some amazing software that can recognise content automatically...

<comment><USER29> You can't grep paper.

<comment><USER4> just to clear up any possible confusion; don't expect text recognition.

it's probably the most requested feature, but it's a really, really hard problem.

but please send me a message at email@example.com if anyone have any tips about solutions to this (we're talking with a couple of vendors, but we might have missed some).

<comment><USER28> FroshKiller is right, a good search feature would make this device much more useful.

Regarding that I do have a 'tip' for you. There is no need for an intermediate textual representation. If a sequence of pen strokes is what you have recorded, then a sequence of pen strokes is what you should search by.

For further tips (or an algorithm) I have to charge :)

</comment></comment></comment></comment></comment><comment><USER30> They need to solve the "lag" problem. Then I'll consider buying one.

<comment><USER4> this is actually the problem we have solved (for epaper).

Compare [https://www.youtube.com/watch?v=AKmfyThA9Sg](https://www.youtube.com/watch?v=AKmfyThA9Sg) to [https://youtu.be/34I27KPZM6g?t=52](https://youtu.be/34I27KPZM6g?t=52)

<comment><USER31> While you have certainly made huge and impressive improvements, I still don't think I could call that "solved". I think _any_ latency is still going to put people off when it comes to writing on this vs. paper.

<comment><USER4> our goal for solving it was to get it down to where it wasn't a detriment for the writing and sketching experience. one of the first things we did was gather data and read what research there was on what kind of latency was noticeable and lead to writing feeling "wrong".

so we solved our goal, but it's always possible to get better.

<comment><USER31> So obviously without actually trying one myself I can't say that you are incorrect, but certainly the demo video you provided still has a feeling of wrongness. Its like with animation, we're still stuck in the uncanny valley but you are definitely climbing out of it.

<comment><USER4> this is one of the reasons we need to get this in the hands of some kind of ambassadors that can test for themselves and give us some validation. imho the video doesn't do it much justice.

</comment></comment></comment></comment></comment></comment><comment><USER32> Looks really cool. Hope you guys nail it.

I'm hoping to see more and more e-ink offerings. For myself, I would like a 50" curved e-ink monitor for work, black and white is fine. I know e-ink has terrible refresh rates, but I'm working with code and consoles 90% of the time. I could put web browsers and other stuff on another monitor.

<comment><USER33> I don't want another monitor, I want a terminal strapped to my face so I can sit wherever I want.

Seriously, a small VR system that's just an SSH client would be a pretty massive improvement on my life.

<comment><USER34> I find the idea of using the most advanced VR technology for your olde command line terribly funny. All those 80s cyberpunks imagining people actually traveling through cyber-information highways, using them in combination with feedback gloves to browse and actuate on the information in a myriad ways... And we just want a command line. I'd love to go back in time to tell them that this is a major use of VR and see the abject horror in their faces.

</comment></comment></comment><comment><USER35> Believe it or not, this is a product that could save an incredible number of lives over time, by allowing us to spend more time outdoors: [http://sunlightinstitute.org/research- studies/](http://sunlightinstitute.org/research-studies/)

<comment><USER16> It's (partially) replacing paper. You can already take paper outside.

<comment><USER4> sssh, it feels good to believe I'm saving the lives of children. :-(

</comment></comment></comment><comment><USER36> This is simply awesome! For a long time I have waited for tablets to actually incorporate the most natural way for making notes and generally working with paper. Not going to preorder (waiting 8 months is kind of too long for me), but probably going to buy just after it comes out.

</comment><comment><USER37> Few questions to the team:

1) Is the screen latency numbers applicable to full-page updates also? I.e. scrolling a page of text.

2) How decent is the performance when dealing with large PDFs?

3) Is the digitizer pressure sensitive? Does it only work with a stylus? If not, how good is palm rejection?

<comment><USER4> we can't release more technical details than what is on the webpage for now, we're still working on the performance. but to give you a rough idea on where we are on UI responsiveness and loading times, this is what we're using for targets: [https://www.nngroup.com/articles/response- times-3-important-...](https://www.nngroup.com/articles/response- times-3-important-limits/)

and the digitizer is an EMR digitizer, completely separate from the touch layer. so we don't have to worry about palm rejection.

edit; you can see the speed of the zoom in the video, which also needs to re- render the page at a different scale. so that should give you an idea about the speed of page flipping.

</comment></comment><comment><USER38> For me, the keypoint is the haptic feeling. As a mechanical keyboard enthusiast, for me the physical "feeling" of the things I use in daily life is a very important and underrated aspect.

Most of the time I find myself switching between my pencil/notebook and google docs. The feel of the pencil on the notebook, the friction, the feeling of pressing on the notebook is a matter of satisfaction which we cannot find on tablets. On the other hand, the flexibility of digital stuff is a must.

With iPhone 7, I am satisfied with the haptic feeling of pressing a button. A similar achievement on a surface would be revolutionary.

</comment><comment><USER39> I am a total paper person. I have notebooks, upon notebooks and still use a paper planner. I could get excited about this once it starts shipping.

If you have an iPad Pro and an Apple Pencil, I recently started using Nebo (by MyScript) and it is working well for me. Handwriting, multiple notebooks, etc. You must have an Apple Pencil to use the app.

For now, none of this will replace my paper, but I am hopeful someday.

ReMarkable Team - I'd love to share how I use paper everyday in hopes some of my specifics make it into your product :-)

</comment><comment><USER40> This is a lot closer, but still too far off the mark. It's still orders of magnitude inferior in terms of lag, convenience, and reliability, while being orders of magnitude more expensive.

Thinking about the iPhone briefly, I think the Steve Jobs formula is to wait until the device can be less than an order of magnitude more expensive, only half as convenient, and about as reliable as the thing it's displacing. I'm also wondering if Microsoft did actually make the right long term decision with regards to its Surface line of hardware.

<comment><USER41> Does that formula, beyond being about as reliable, apply to the iPhone? It seemed the gate was if it was much more convenient.

<comment><USER40> The iPhone was much more convenient in a new context: having access to your data in your pocket, all the time. It was a _worse_ cellphone, with regards to charging and call reception. However, it was good enough as a cellphone, and it enabled _something else_.

</comment></comment></comment><comment><USER42> I really, really hope these guys are successful. Want one v. much

</comment><comment><USER43> Can you talk about the resolution on the device? On the video, it looked to be fairly low, probably lower than the Kindle PaperWhite which I have. I'd be really interested in this for reading PDF's papers and PDF tech books, but only if the text isn't too jaggy.

<comment><USER44> If I understand the eink tech correctly, large hi-dpi screens will have very poor screen redrawing properties. Something about how the individual "pixels" get toggled in series.

</comment></comment><comment><USER45> Awesome... But I will wait for them to be shipped and the first reviews to be in before I commit

</comment><comment><USER46> What is the bottleneck on eInk display refresh rate? Is it a fundamental limitation of the tech, or is the slow refresh rate of devices like the Kindle a power-saving feature?

<comment><USER8> E-paper (E-Ink is a brand name) works by magnetically moving small black or white particles (suspended in fluid) for each pixel whenever it needs to change. It's a bit like an etch-a-sketch, it's an analog system at the low level. At minimum, the movement takes time. Also, the current state of the pixel affects the charge that needs to be applied for a given target state - that means either taking more time to calculate, getting an afterimage, or doing that whole-screen black-white flicker to clear everything out. Probably all three due to precision limits.

<comment><USER46> I don't know a nice way to say this. Your reply has added nothing to my understanding.

<comment><USER8> Yes, it's a fundamental limitation. Changing colors means moving tiny bits of magnetic dust, and the amount of charge needed is based on where they currently are. This takes more calculation than just running electricity through a light, which can be done regardless of whether or not you were running electricity through it a moment ago. This extra calculation will always take more time, unless the simpler tech reaches a fundamental physical limit like how fast power can be cycled without something melting.

</comment></comment></comment></comment><comment><USER47> I want one.

If anyone feels like supporting this project, but doesn't think they'd actually use such a device, let me know, I'd happily accept one to test / use / etc.

<comment><USER48> Let these be my words.

</comment></comment><comment><USER49> I've been waiting for this with a microphone as a LiveScribe replacement. That mythical device would never leave my side. Please consider for version 2.

</comment><comment><USER50> I really, really want something like this but I'm too scared to pre-order one until a bunch of reviews come out first.

<comment><USER13> So was I, but you can apparently cancel up until the shipping date.

</comment></comment><comment><USER16> So, it looks great but

a) does it have a backlight

b) can I sync it with my own server instead of some 3rd party cloud service?

<comment><USER4> no backlight, and as I explained above we can't promise anything other than what is written on the webpage already wrt. features.

<comment><USER51> the primary reason i purchased an kobo aura one is the red led back light, so i can read at night without messing with my sleep cycle. it's a killer feature. you'd be wise to consider it.

<comment><USER4> we're far too late in the development process to add to the features of the hardware, but backlight is one of the ideas for a next generation.

</comment></comment></comment></comment><comment><USER52> Marker looks like a Pencil. I like the concept. Could be godsend for urban sketching.

</comment><comment><USER53> i don't understand why its a steal at almost $400. my tablet does all of this better. except for drawing, which is significantly not as awesome.

i also don't know how adding a fourth device simplifies life at all.

<comment><USER35> Stay indoors a lot do you? That ain't healthy. [http://sunlightinstitute.org/research- studies/](http://sunlightinstitute.org/research-studies/)

<comment><USER53> what?

<comment><USER35> What part of the URL seemed unclear?

</comment></comment></comment></comment><comment><USER54> So a tablet-sized smartboard?

Who is the target market for a product like this?

<comment><USER55> I can see myself being in the target market (sw/hw developer) - while much of my day-to-day work takes place on a computer, I still rely on pen and paper for early sketches/brainstorming and the like, leading to an office with (quite literally!) hundreds of notebooks on the shelves.

If it feels sufficiently paper-y to write on and PDF exporting is seamless-y and with at least a rudimentary tagging function, I'd probably buy one.

<comment><USER54> Interesting. I'm actually envisioning this being a great tool for academic research.

<comment><USER56> Yes, having .pdf versions of papers, that you could annotate would be very cool.

</comment></comment></comment></comment><comment><USER57> from the close up this looks like etch-a-sketch magnet technology.

</comment><comment><USER58> Is this the NoteSlate guys again?</comment>