As noted in thread, I've been using an e-paper device, the Onyx BOOX Max Lumi, for about a year. It's my strong preference for reading, and I do some Linux-type stuff on it, mostly through Termux.
A few thoughts:
- If you think you're going to avoid distraction simply by changing the screen properties ... you're likely to be disappointed. Though desaturation and reducing animations does no doubt help. You and your environment remain your biggest enemy.
- Shutting off WiFi is your biggest win for productivity.
- High-density, high-contrast, B&W display is a pleasure to read.
- The lack of tools to schedule / manage / organise tasks and resources on my tablet itself is a huge frustration. Much of that is the lack of tools to view / manage content metadata. If you're reading a book at a time, or 2, or 10, that's not such a problem. I treat my tablet as a library, with 100s to 1,000s of references / documents available. There are no tools to effectively manage these.
- Much of the problem with content presentation online is not due to shortcomings of the PDF format itself, but of displays. Simply having a large enough and portrait-mode display is a huge win. "Large enough" starts at about 9", though I'd recommend 10" -- 13" for the sweet spot. A problem of course is that you want to accommodate the worst cases you're likely to encounter, and for me that's three-column, small-font, scanned in journal and periodicals articles. 13" is almost too big for standard book reading, but it's awfully nice for handwritten notes.
- Having a fixed keyboard at all times might actually be a disadvantage. Being able to flexibly transition from tablet to laptop seems a useful option.
- There's a stunning amount that can be done at shell and with fairly minimal system capabilities. Serving up the modern Web is not amongst these. The degree to which a web browser absolutely pigs out a system really cannot be overstated. This is sad and a Very Bad Thing.[1]
- Android sucks.
- I really cannot express in words how much Android sucks. I'd desperately like to have some sort of e-ink / mobile / portable device that isn't based on Android or iOS. Real Motherlovin' Linux would be awesomesauce. That said, the more you pile onto a mobile platform, the more battery life will suck. Some compromises simply have to be made.
- Android sucks specifically because: 1. The OS management is not geared to constand usage. 2. User state is constantly lost/discarded. 3. The app ecosystem is abysmal. 4. Filesystem access is walled off. 5. The device owner is subordinate to the system and OS, and lacks root by default. 6. Such arcane matters as handling keyboard input consistently across applications seem to be Deep And Insurmountable Mysteries Of The Universe. 7. Google Play Is Motherfucking Spyware. 8. Google. 9. This is not the end. It's not the beginning. It's not even the beginning nof the prelude of the introduction of the preface of the beginning.
- Which raises some interesting prospects for battery-sparing power. A very lightweight terminal handler (reads keystrokes, updates display), paired with a larger system that fires up when Other Shit Needs Doing, such that the platform is effectively catnapping most of the time, might work out. How often the system wakes and processes is an interesting question, but that might be anywhere from every few seconds to every few minutes. The key is for wake/sleep to draw less power than remaining on constantly. On mains power, wake would persist for longer. An audio-output channel might also remain more persistently awake.
- So long as E-Ink (the company) controls patents and production, e-paper display costs will be high. I don't know what the BOM for Onyx's display is, but suspect it's a major share of the device's final $800 cost. That means that everything else will have to fall into whatever residual budget exists. Yes, the laptop will be expensive relative to its processor / memory / storage specs. OTOH, it's probably possible to economise considerably on graphics.
- Prototyping this as a display module option for the Framework laptop[2] might be really interesting.
- If presented as a desktop, optimisations for E-Ink will be necessary. How much of this is attainable through existing desktop environments/software, and how much needs customisation, remains to be seen. I espect some significant teething pains in this area. This applies to both the graphical shell and applications. Einkbro, an e-ink optimised Web browser (Android) is a good study in what optimisations are useful. If anything, the app does not go far enough in favouring paging to scrolling, IMO.
- Some sort of dedicated hard screen refresh is likely necessary. Ghosting is tolerable to a point, and then it's not. Giving the user an option to refresh seems highly useful.
- The ability to divide the screen into different regions of different refresh/quality modes would be useful. Text -> "Regal", scrolling "Speed" or "A2" mode, animations / video, "X Mode". These would probably be assigned either by appllcation, or by content within applications --- e.g., video -> X Mode, images -> Speed. (In my experience, the halftoning / dithering of Speed and A2 modes is actually preferable to "Regal" for images. "Regal" is best suited to text and handwriting.) This is all but certainly an E-Ink / vendor issue, and not something Modos would be able to address themselves, though there might be hooks / conversions in the graphics layer (Xorg or Wayland?) that would address this.
- Modos all but certainly wants to use a tiled / tiling-friendly window manager.
- In addition to the display, I'd like to see a decent audio system, with hardwired audio output and no onboard speaker. Both audio media (e.g., podcasts) and voice comms should be an available function of the device. (Use for voice comms would probably entail battery/performance compromises, podcast playback largely should not.)
________________________________
Notes:
1. How to fix this is of course one of the Perennial Conversations and a Hard Problem. I'm increasingly of the view to 1) split the web into a) content, b) applications, c) media, and d) commerce, and to impose extreme penalties on poorly-performing and standards-noncompliant sites. Of course, a major driver of all of this is monetisation and control, both of which are their own long digressions. But unless these are addressed, no technical fixes will suffice. Defeat the system itself.
> Some compromises simply have to be made. [...] A very lightweight terminal handler (reads keystrokes, updates display), paired with a larger system that fires up when Other Shit Needs Doing, such that the platform is effectively catnapping most of the time, might work out.
Check out PaperTerm [1]. I like it a lot and keep bringing it up, but there have been no other news about it yet.
As noted in thread, I've been using an e-paper device, the Onyx BOOX Max Lumi, for about a year. It's my strong preference for reading, and I do some Linux-type stuff on it, mostly through Termux.
A few thoughts:
- If you think you're going to avoid distraction simply by changing the screen properties ... you're likely to be disappointed. Though desaturation and reducing animations does no doubt help. You and your environment remain your biggest enemy.
- Shutting off WiFi is your biggest win for productivity.
- High-density, high-contrast, B&W display is a pleasure to read.
- The lack of tools to schedule / manage / organise tasks and resources on my tablet itself is a huge frustration. Much of that is the lack of tools to view / manage content metadata. If you're reading a book at a time, or 2, or 10, that's not such a problem. I treat my tablet as a library, with 100s to 1,000s of references / documents available. There are no tools to effectively manage these.
- Much of the problem with content presentation online is not due to shortcomings of the PDF format itself, but of displays. Simply having a large enough and portrait-mode display is a huge win. "Large enough" starts at about 9", though I'd recommend 10" -- 13" for the sweet spot. A problem of course is that you want to accommodate the worst cases you're likely to encounter, and for me that's three-column, small-font, scanned in journal and periodicals articles. 13" is almost too big for standard book reading, but it's awfully nice for handwritten notes.
- Having a fixed keyboard at all times might actually be a disadvantage. Being able to flexibly transition from tablet to laptop seems a useful option.
- There's a stunning amount that can be done at shell and with fairly minimal system capabilities. Serving up the modern Web is not amongst these. The degree to which a web browser absolutely pigs out a system really cannot be overstated. This is sad and a Very Bad Thing.[1]
- Android sucks.
- I really cannot express in words how much Android sucks. I'd desperately like to have some sort of e-ink / mobile / portable device that isn't based on Android or iOS. Real Motherlovin' Linux would be awesomesauce. That said, the more you pile onto a mobile platform, the more battery life will suck. Some compromises simply have to be made.
- Android sucks specifically because: 1. The OS management is not geared to constand usage. 2. User state is constantly lost/discarded. 3. The app ecosystem is abysmal. 4. Filesystem access is walled off. 5. The device owner is subordinate to the system and OS, and lacks root by default. 6. Such arcane matters as handling keyboard input consistently across applications seem to be Deep And Insurmountable Mysteries Of The Universe. 7. Google Play Is Motherfucking Spyware. 8. Google. 9. This is not the end. It's not the beginning. It's not even the beginning nof the prelude of the introduction of the preface of the beginning.
- Which raises some interesting prospects for battery-sparing power. A very lightweight terminal handler (reads keystrokes, updates display), paired with a larger system that fires up when Other Shit Needs Doing, such that the platform is effectively catnapping most of the time, might work out. How often the system wakes and processes is an interesting question, but that might be anywhere from every few seconds to every few minutes. The key is for wake/sleep to draw less power than remaining on constantly. On mains power, wake would persist for longer. An audio-output channel might also remain more persistently awake.
- So long as E-Ink (the company) controls patents and production, e-paper display costs will be high. I don't know what the BOM for Onyx's display is, but suspect it's a major share of the device's final $800 cost. That means that everything else will have to fall into whatever residual budget exists. Yes, the laptop will be expensive relative to its processor / memory / storage specs. OTOH, it's probably possible to economise considerably on graphics.
- Prototyping this as a display module option for the Framework laptop[2] might be really interesting.
- If presented as a desktop, optimisations for E-Ink will be necessary. How much of this is attainable through existing desktop environments/software, and how much needs customisation, remains to be seen. I espect some significant teething pains in this area. This applies to both the graphical shell and applications. Einkbro, an e-ink optimised Web browser (Android) is a good study in what optimisations are useful. If anything, the app does not go far enough in favouring paging to scrolling, IMO.
- Some sort of dedicated hard screen refresh is likely necessary. Ghosting is tolerable to a point, and then it's not. Giving the user an option to refresh seems highly useful.
- The ability to divide the screen into different regions of different refresh/quality modes would be useful. Text -> "Regal", scrolling "Speed" or "A2" mode, animations / video, "X Mode". These would probably be assigned either by appllcation, or by content within applications --- e.g., video -> X Mode, images -> Speed. (In my experience, the halftoning / dithering of Speed and A2 modes is actually preferable to "Regal" for images. "Regal" is best suited to text and handwriting.) This is all but certainly an E-Ink / vendor issue, and not something Modos would be able to address themselves, though there might be hooks / conversions in the graphics layer (Xorg or Wayland?) that would address this.
- Modos all but certainly wants to use a tiled / tiling-friendly window manager.
- In addition to the display, I'd like to see a decent audio system, with hardwired audio output and no onboard speaker. Both audio media (e.g., podcasts) and voice comms should be an available function of the device. (Use for voice comms would probably entail battery/performance compromises, podcast playback largely should not.)
________________________________
Notes:
1. How to fix this is of course one of the Perennial Conversations and a Hard Problem. I'm increasingly of the view to 1) split the web into a) content, b) applications, c) media, and d) commerce, and to impose extreme penalties on poorly-performing and standards-noncompliant sites. Of course, a major driver of all of this is monetisation and control, both of which are their own long digressions. But unless these are addressed, no technical fixes will suffice. Defeat the system itself.
2. https://news.ycombinator.com/item?id=28606962 https://pluralistic.net/2021/09/21/monica-byrne/#think-diffe...