[sandsmark]

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.

[pttrsmrt]

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.

[sandsmark]

> 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.

[AlbertoGP]

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.

[sandsmark]

> 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

[gpetersen]

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.

[linuxkerneldev]

You wrote:

> really interested in how we have solved the latency problem, and we don't want to help them.

But just before that, you also wrote ( https://news.ycombinator.com/item?id=13072333 ):

> One of the issues I personally want to solve is the lack of a hackable e-paper device.

So which is it? You want to make a hackable (I interpret that to mean free and open source) e-paper device where you let everyone see how you solved the latency problem? OR do you want to make a closed source thing where only you and you alone have this magical device that has the lowest latency E Ink panel by a factor of 2?

[sandsmark]

it won't take many weeks (or days) from we release the device until our solution is reverse engineered, no matter how much we lock it down. but until then we want to keep as much as possible secret.

as for hackable device; we don't intend to release the magic sauce that makes the latency goes down. what I meant with hackable is that I've wanted an e-paper device which I could run my own code on, without having to look for security holes in the software running on it.

but again; we can't promise anything at this point wrt. hackability; we have limited time and resources, and our focus is on making the device as good as possible. our focus is not on making an open source device, we're not going to release the gerber files. :-)

[linuxkerneldev]

> we don't intend to release the magic sauce that makes the latency goes down.

Ok.

> what I meant with hackable is that I've wanted an e-paper device which I could run my own code on, without having to look for security holes in the software running on it.

If your software is closed source, then I don't understand how anyone other than you effectively (or practically) would be able to solve or fix any security holes.

> we're not going to release the gerber files

You're setting up a strawman there. I was not asking for your hardware design or even mentioning it in anyway. I was pointing out that you are contradicting yourself when you say your product is hackable to software developers and then 30s later say that there will be "magic sauce" in software that will be closed.

[sandsmark]

> If your software is closed source, then I don't understand how anyone other than you effectively (or practically) would be able to solve or fix any security holes.

I'm sorry if I wasn't clear. I meant that for pretty much all current e-paper devices you aren't able to get access to run your own code unless you find a security hole that you can exploit to gain access.

And sorry about the strawman, it wasn't intended that way. I think the rest of the comment before that answers your original question.

[linuxkerneldev]

> I'm sorry if I wasn't clear. I meant that for pretty much all current e-paper devices you aren't able to get access to run your own code unless you find a security hole that you can exploit to gain access.

Ok. That helps clarify things.

But on your website, you do not state that your device will permit flashing "your own code". Your website somewhat implies the opposite, it says:

" DO YOU PROVIDE THE REMARKABLE WITH A SDK FOR CUSTOM DEVELOPMENT? The reMarkable will not initially ship with an officially supported SDK. We might however release an unsupported SDK for best developers. "

Could you clarify what "might" and "best developers" means? In multiple comments, you somewhat imply capabilities and features of the product with terms like "hackable" and "run your own code". Perhaps you could put an explicit statement on your website clarifying your position to match your comments.

[sandsmark]

please see https://news.ycombinator.com/item?id=13114550 for an explanation of the bad wording of "best" developers.

I'm not trying to imply anything, but what I personally want and what we can do are two different things. I'm sorry if I've been sloppy in my comments here, the last days have been pretty hectic.