> [...] 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
I didn’t realize it until visiting your HN profile but I see you are one of the people behind reMarkable!
And you guys are based in Norway too!
A few questions if you don’t mind.
How many people are in your company?
What are the current and future plans of the company in terms of product? Keep improving the software for the current hardware? Make new models with different hardware?
Where in Norway are you located?
Are you looking to increase the number of people working in your company? Planning to hire more software developers?
And in terms of the open source parts of it, I don’t have this product, nor have I really heard about it before, so I haven’t had a chance to try it but, 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?
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?
> [...] 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.
Have you considered hiring remotely? (I read your recruitment pages and while it does not say that you don’t explicitly your hiring process looks as if you are recruiting only for on-site positions).
Did you try running Emacs? Apparently the console version of Emacs has code to merge edits together so as be usable on slow high-latency connections (like in the 80's and early 90's I guess). In terms of refresh rate E-ink displays have similar characteristics so should be interesting to try!
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 protected] if anyone have any tips about solutions to this (we're talking with a couple of vendors, but we might have missed some).
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 :)
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.
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.
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 )
"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.
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.
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.
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?
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).
> 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.
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.
:-)