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