Live data from Hacker News

PaperTerm Concept, An e-paper remote terminal device

paperterm.org

71–80 of 94 posts

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

#71

Earlier quoted context omitted.

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 microcont…

I promise you can make Linux wake from a low power state much faster than you can wake up the radios and negotiate a stable network connection with "the cloud!?". Not to mention battery life... Even if my host was connected over ethernet I wonder how realtime benchmarks would compare with whatever network hardware you have in mind.

I love the idea of having cell and wifi modems, but these seem like high priority secondary concerns to me personally.

I understand that I may not have the same vision as you exactly, but I really am pretty much your target consumer. I totally get the elegance of reimplementing the "dumb terminal", but I really challenge you to justify it.

On that note, do you plan to support PDFs?

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

#72

Earlier quoted context omitted.

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

You could probably do that with a cheap laptop by cutting down a Linux distro then removing/breaking all network hardware antennas/ports

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

#73

Earlier quoted context omitted.

I built something similar: https://bbenchoff.github.io/pages/dumb.html What are you going to do about the actual cost of the device? You've already got an e-paper display, but you're also adding a 'laptop' style enclosure, real keyboard, and if you're storing SSH keys, you're really close to running a cut-down Linux system. That's basically a laptop, and you could get the same thing with, you know, a laptop. Have you…

That is very cool! Have you built a physical copy of it? No, I think the smaller size is probably a non-starter for the intended audience. This is meant to be a tool that a lot of these folks are using for hours and hours a day so overall typing and reading experience is paramount, and meant to be a "selling" point. Cost-wise, yes--we're still grappling with costs of the e-ink screen. It's the by far the largest expe…

Have you considered using a DES display or Sharp Memory LCD? I know the first is definitely cheaper than a branded E-Ink display, and the latter has much faster refresh rate and may be more suited to being a terminal (and may also be cheaper than E-Ink, I just haven't looked into it).

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

#74

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…

I would be pretty close to the exact target for this product. The killer feature that would put it over the edge for me would be the possible "crashcart" KVM feature mentioned later in the notes.

Lugging around a full KVM console is overkill (unless it is literally on a cart and you only need it at one location). And USB crash cart adapters are buggy, overpriced, and unmaintained.

With serial, SSH, and KVM this will fill the perfect "there is a piece of hardware on the rack I need to interface with" role.

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

#75

Earlier quoted context omitted.

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 microcont…

I promise you can make Linux wake from a low power state much faster than you can wake up the radios and negotiate a stable network connection with "the cloud!?". Not to mention battery life... Even if my host was connected over ethernet I wonder how realtime benchmarks would compare with whatever network hardware you have in mind. I love the idea of having cell and wifi modems, but these seem like high priority seco…

I think the disconnect between us is that this is running on a microcontroller. Think "a beefier version of what runs your smart thermostat." Linux isn't unheard of for such a device, but is a pretty heavy lift because of limited resources. Using a microcontroller has its advantages. One advantage goes exactly to the point--with smart design it can maintain a wifi connection, waking for milliseconds at the required interval, so when you want to use it there is no wifi negotiation time. Keeping things open all the way to the remote host is whole other matter, but I believe that's touched on in the document.

What is your use case for this sort of device? We'd certainly like to support as many as possible without compromising the overall vision. You mention PDFs--is your use case for reading or creating documents?

There was no plan to support local viewing of PDFs--again, parsing them is a pretty heavy lift for a low-power microcontroller to do with acceptable performance. We've got a related (very alpha) project that uses Chromium to render websites in a fancy text-only fashion. This is because for most devices, having a modern web browser is table stakes so we want to support that for this device. However, this browser would would be installed on the host you connect to with this device, not on the device itself. The browser can view PDFs (it uses Mozilla's pdf.js). I can show you screenshots of output of this browser, but not much else at this point. Those closest relative of this browser that is public is Browsh. It would give you an idea for what can be done: https://www.brow.sh/

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

#76

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…

Does the e-paper display you use have to "flash to black" on just about every change like so many of the Kindle whites do?

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

#77
post #76

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…

Does the e-paper display you use have to "flash to black" on just about every change like so many of the Kindle whites do?

Our panel supports partial refresh (no black flash) which makes it much more performant. The software does have to do occasional flashes to keep the screen tidy (otherwise you get a lot of ghosting over time). You can control how often this happens.

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

#78

Earlier quoted context omitted.

That is very cool! Have you built a physical copy of it? No, I think the smaller size is probably a non-starter for the intended audience. This is meant to be a tool that a lot of these folks are using for hours and hours a day so overall typing and reading experience is paramount, and meant to be a "selling" point. Cost-wise, yes--we're still grappling with costs of the e-ink screen. It's the by far the largest expe…

Have you considered using a DES display or Sharp Memory LCD? I know the first is definitely cheaper than a branded E-Ink display, and the latter has much faster refresh rate and may be more suited to being a terminal (and may also be cheaper than E-Ink, I just haven't looked into it).

Yes we have considered it. Do you know of any such large (over 12 inches) panels with decent resolution and pretty fast updates that are available? Such a thing would probably help with power consumption. (e-inks consume a lot of power during screen updates).

Looking at all of the options a simple full RLCD would probably be best for us--not eink--but we can't find appropriate parts for the size and resolution.

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

#79

I leave a picture of my setup that I previously posted in Reddit: https://www.reddit.com/r/emacs/comments/o16nfa/pretty_please... This is a BOOX Note Air, with Termux + Mosh + TMUX and my editor of choice Emacs DOOM. I'm pretty happy of this setup. I went in holiday and I manage to use my editor to do some coding. The only side effect is that it requires internet for extra processing power, although you could still r…

I tried to throw together something similar for my Kindle browser just now. I connected my bluetooth keyboard to my phone and ran the following in termux:

  pkg install shellinabox
  shellinaboxd -d -t -p 8080 -s "/:$(whoami):$(whoami):/:tmux attach"
There are better web terminals, but the don't seem to work with the crappy "Experimental Browser".

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

#80

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 android. Are you disabling the "Whiten Apps Background" optimization? It's on by default and it makes it harder to use apps I find because controls and buttons end up hidden. Turn it off and it's fine.

Thank you for this suggestion! I have a Nova 3 myself and I didn't realize that this "optimization" was on by default. Any clue if there's a way to change this to off-by-default?
Post reply on HN