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.
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.
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.
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).
> 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?
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. :-)
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.
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.
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.
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.
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.