sandsmark

Picture of one of the first prototypes (from 2015 or thereabouts) from remarkable.com/careers, guess the naming scheme: https://images.ctfassets.net/og7ujiyra5gx/15KAaMUsNXP8cQu3lP...

:-)

We generally have a policy of not communicating externally by default (way too many startups have failed because of loose lips and over-promising), but I'll answer with what's already known publicly. :-)

> How many people are in your company?

Around 70¹.

> Where in Norway are you located?

Oslo¹ (or you can search for reMarkable on google maps).

> Are you looking to increase the number of people working in your company? Planning to hire more software developers?

Yes, yes and yes. :-)

https://remarkable.com/careers

> [...] is everything that the community would need available in order to create a fully open source alternative “firmware” (or really, a “distro” might be a better name for it since it’s running a Linux kernel and all) that can run on your hardware?

It's just a completely standard Linux system, and as required we publish the source code for u-boot and Linux and whatnot, so yes.

I originally wanted to just run plain Debian on it (or ALARM), but it was easier to just start with a minimal system and put on as little as possible, especially when you're a single person trying to keep track of everything.

Now we've expanded the team a bit, and ideally we could upstream at least the kernel patches so we don't have to forward-port everything ourselves, but it's not a high priority unfortunately.

And we're still a relatively small team, it's a bit hard to find a lot of good kernel developers who want to switch jobs in Norway.

¹: https://www.dn.no/teknologi/teknologi/nettbrett/remarkable/r...

Hmm, I thought we were at 2017.75, are you sure your device is up to date?

We shipped the first software with an old dropbear, though it had backported patches for the known CVEs: http://cgit.openembedded.org/openembedded-core/tree/meta/rec...

> [...] but having a mosh console on there would allow here to ditch her macbook. [..] Being able to code on it would also cause me to get one and ditch my iPad Pro.

Not officially supported or endorsed in any way, shape or form, and I don't even know if it even still builds, but I did a quick proof of concept porting fingerterm; https://iskrembilen.com/fingerterm+vim.jpg

https://github.com/reMarkable/fingerterm

I don't think it's very usable in practice, though, but it was cool for about five minutes to muck about in a terminal emulator on an e ink display.

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.

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.

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

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.

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

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

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 martin.sandsmark@remarkable.no if anyone have any tips about solutions to this (we're talking with a couple of vendors, but we might have missed some).

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.

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

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.

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.

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

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.

> 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

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

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

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

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.

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.

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.

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

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.

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.

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.

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.

the latency is basically the only thing we've focused on for a while, it's a very focused device in terms of what we spend our resources on.

the high latency is one of the reasons normal tablets suck for writing and sketching.

this is actually the problem we have solved (for epaper).

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