Live data from Hacker News

PaperTerm Concept, An e-paper remote terminal device

paperterm.org

61–70 of 94 posts

Re: PaperTerm Concept, An e-paper remote terminal device

#61

Earlier quoted context omitted.

I own one, it's a true three star experience. It's completely unique in its class as it's a true e-ink display at A4/Letter scale and even has two monochromatic backlight sources, one without any blue light. That rocks. It's a near-perfect reader and digital notepad and that's what I use it for. The software however is bad. Did I say bad? It's laggy, it's supposedly Android but not really. Lots of apps only work semi…

> it's a true three star experience Out of how many stars total?

Doesn't everyone use five stars these days? :)

Re: PaperTerm Concept, An e-paper remote terminal device

#62
post #57

Oh, hi all! I didn't my project to show up here today! This was just my private notes-to-self I'm using to organize a group to create this thing. These notes haven't been cleaned up to be public yet (near the end it gets particularly messy and the memory map has changed from the state shown on this page), but oh well, it's been found! I will answer any questions you may have. And if you want to help make this, my ema…

Do you estimate thay this concept will ever come to life? (say, P1) If so, when? (I'm OP, sorry for unsolicitedly posting your notes to HN. I guess I am just a bit too excited for this)

We have a prototype-y thing part way between P0 and P1 already.

A "you can build it yourself" P1 version of that will probably be well-documented by early next year, but it won't be something you can just go out and buy yet. You'll have to gather together the parts needed, get the PCB produced, etc.

The plan was for us to get something to that P1-stage and then go more public about the project. No worries on jumping the gun with posting it. It's not exactly a secret, just not *intended* for public consumption yet.

I think when we have a couple of copies of P1s ready to show off (and videos of the product, and an actual product website! :-) having something put together we can show off would help open up some doors from people with more experience with getting hardware produced so people can get this more readily (even if just in kit form to start). Right now we're just doing one-off prototyping.

Re: PaperTerm Concept, An e-paper remote terminal device

#63
post #48

Oh, hi all! I didn't my project to show up here today! This was just my private notes-to-self I'm using to organize a group to create this thing. These notes haven't been cleaned up to be public yet (near the end it gets particularly messy and the memory map has changed from the state shown on this page), but oh well, it's been found! I will answer any questions you may have. And if you want to help make this, my ema…

Sounds like a very interesting project, I certainly would be tempted to have an eInk terminal. Can you post images on how the terminal looks on the eInk screens?

I can give you images of how a terminal looks on e-ink screens but not with the final panel we're likely to use nor with final software, so probably best no to since it wouldn't be representative.

Google can give you an idea of how it looks, but with a much smaller screen than we're using (ours is 13.3") so these images feel more cramped and look more "plain jane": https://www.google.com/search?q=e-ink+terminal&um=1&ie=UTF-8... With the larger screen and more refined setup than these Google Images pictures show, it is very pleasant to use. I hands-down prefer it to a laptop running a terminal, except when color is important.

Re: PaperTerm Concept, An e-paper remote terminal device

#64
For PF, I recommend "disconnected by default" I've been using my laptop like this for a while now and the peace of mind is easily worth the one command I need to run to connect each time. Especially on a distraction free device where I wouldn't expect a lot of notifications and synchronizations.

Re: PaperTerm Concept, An e-paper remote terminal device

#65

For PF, I recommend "disconnected by default" I've been using my laptop like this for a while now and the peace of mind is easily worth the one command I need to run to connect each time. Especially on a distraction free device where I wouldn't expect a lot of notifications and synchronizations.

This could only happen if we've got some local apps beyond the main (terminal) app. PF-timeframe, as you say. I will write the idea down so it doesn't get lost.

It probably makes sense as a toggle, perhaps selected when initially setting up/getting a software tour of the device, depending on who is using the system. Writers for example, would want it, sysadmins, not so much.

Re: PaperTerm Concept, An e-paper remote terminal device

#66
post #25

Earlier quoted context omitted.

Sounds like an easy 'dev mode' to add, and capture a large market of developers. For years I've been looking into eink for development etc.

Remarkable is actually very open. Getting root access is as easy as going to the bottom of the About page to get the device's ip and its root password for SSH access. But still, the hacking scene is far from big. There is no SDK. You can do things with QT but for a lot of use cases, you have to work directly with the screen capacities. e-ink screens are not good old framebuffer screens. If you want to have nice perfo…

It would be great, if there were more documentation to get started with developing for the remarkable and perhaps a few shared libraries with commonly used functions, e.g. just to be able to display a given png. Even if it were just a command line program, it would enable many usages.

It is trivial to compile Go programs for the reMarkable - just compile with ARM as a the target architecture. One can do that on any machine with Go installed. But for the lack of APIs, I have had no idea yet where to reasonably start with programming the reMarkable.

Re: PaperTerm Concept, An e-paper remote terminal device

#68

For PF, I recommend "disconnected by default" I've been using my laptop like this for a while now and the peace of mind is easily worth the one command I need to run to connect each time. Especially on a distraction free device where I wouldn't expect a lot of notifications and synchronizations.

This could only happen if we've got some local apps beyond the main (terminal) app. PF-timeframe, as you say. I will write the idea down so it doesn't get lost. It probably makes sense as a toggle, perhaps selected when initially setting up/getting a software tour of the device, depending on who is using the system. Writers for example, would want it, sysadmins, not so much.

I'm sorry if I'm misunderstanding you but, why are local apps a prerequisite for controlled networking? Or is that just how you want to build it out?

To be clear, all I'm suggesting is executing a command like `network connect ` instead of automatically connecting to saved networks.

Maybe I'm just not sold on the concept of a truly remote terminal (like the real old terminals). Why should I have to carry around two devices when Linux could run on this device itself? Perhaps it's a lot more work? but there have been some efforts made on this already. I would like to casually launch vim and start writing, without worrying about connectivity.

As an aside, also consider looking at how the reMarkable tablet implements ether/IP over USB, that has been working pretty well for me too, though I really wish it would broadcast an mDNS entry over WiFi as well.

Re: PaperTerm Concept, An e-paper remote terminal device

#69

Earlier quoted context omitted.

This could only happen if we've got some local apps beyond the main (terminal) app. PF-timeframe, as you say. I will write the idea down so it doesn't get lost. It probably makes sense as a toggle, perhaps selected when initially setting up/getting a software tour of the device, depending on who is using the system. Writers for example, would want it, sysadmins, not so much.

I'm sorry if I'm misunderstanding you but, why are local apps a prerequisite for controlled networking? Or is that just how you want to build it out? To be clear, all I'm suggesting is executing a command like `network connect ` instead of automatically connecting to saved networks. Maybe I'm just not sold on the concept of a truly remote terminal (like the real old terminals). Why should I have to carry around two d…

Ah, I misunderstood you. Without the local apps, unless you are connected to a network, there is literally nothing to do with this device. That's because it is more-or-less a terminal only (excluding the few PF local apps). There are no notifications to speak of.

A Linux OS based device can't meet the goals of the device from a couple of standpoints (power, availability, and the limited RAM/resources on the microcontroller pop to mind right away). Think of this as an instant on appliance. You turn on your old Commodore 64 and you are instantly able to type.

I hear ya, when it comes to "just wanting to be able to open the thing and start typing into vim (or whatever)". We're working on sanding down those edges in a couple of ways--1) eventually, we'd like to point people to a very cheap, simple cloud linux deployment if they don't want to setup their own, with lots of conveniences. 2) regarding actually getting a network connection since we're talking terminal-only the bandwidth requirements are tiny; because of that, it looks like we're going to want to add cell network connectivity. This is early-stages in thinking this through, but there are plans in the $40 - $60 range for an ENTIRE YEAR that would give you unlimited bandwidth that is plenty fast for terminal purposes (128kbps after using a limited amount of faster 4G bandwidth).

I will take a look at the reMarkable ether over USB. Thanks for pointing it out. It'll be a while before we've got a full USB stack working though. Remember, the software footprint for this device is tiny by design.

Re: PaperTerm Concept, An e-paper remote terminal device

#70

Earlier quoted context omitted.

I realize this might simply put me into the "not target demographic" group, but what makes this so useful as a terminal, that a laptop won't do? I could understand the no-distraction writing i.e. word processor use-case that some people think E-Ink would be good for, but that doesn't appear in your list of possible applications either.

Use as a distraction-free word processor is listed as a use-case if you read far enough. (As mentioned, the notes are a bit of a mess and weren't cleaned up for public consumption.) But, yes, a laptop can do pretty much everything Paperterm can do. A laptop can do everything a Kindle can do. A laptop can do a huge percent of what your phone can do. If the advantages of this niche device (e.g., sunlight-readable displ…

A distraction free word processor that could display PDFs along with the text (for writing LaTeX) would be a real godsend for me. In fact I am writing this very comment while distracting myself from some LaTex I am supposed to be writing...
Post reply on HN