• 0 Posts
  • 29 Comments
Joined 4 years ago
cake
Cake day: June 28th, 2020

help-circle









  • Boox Tab Ultra

    Looks pretty nice device! Even the camera makes a bit sense in the demo they give (though apparently in practice the scanning rarely works). And cheaper to boot as well. I might consider getting this one.

    But is the display really better quality? Atleast the DPI is slightly higher at 219 on the Boox Tab Ultra vs 190 on the Daylight. And Boox weighs 70 grams less, and that’s the device some reviews call heavy (and some lightweight…).

    These reviews mention the slow display speed:

    So perhaps there is some room for improvement? That being said, some other reviews don’t mention it and one says it’s faster than typical e-ink display, though that doesn’t sound immediately purely praising.


    In the end it probably comes to the software: how fast it is, it well it works, how nice it is to use. It seems both have customized the standard Android, so I suppose the difference is in which one has done it better and which one has better custom apps. Per the reviews Boox doesn’t fare too well in this aspect. Maybe someone will make a comparative review of the devices.






  • flux@lemmy.mltoLinux@lemmy.mlUbuntu Snap Hate
    link
    fedilink
    arrow-up
    4
    arrow-down
    1
    ·
    8 months ago

    I think the second point is the biggest for me: it’s almost like Canonical wanted to have a single dominant store for apps, as the ecosystem they are building supports only one. And, apparently, that one server is also closed?

    So if you try to make an alternative source and give instructions to people how to configure their snap installation to use it (I found this information very hard to find for some reason…), your “store” probably won’t have the same packages Canonical’s has, so users won’t be able to find the packages and I imagine updates are also now broken?

    Contrasting this with flatpak: you just install apps from wherever. Or from flathub. Or your own site. Doesn’t matter. No business incentive behind—built into the tools—to make everyone use flathub.org.





  • Just keeping a single frame buffer image can take tens of megabytes nowadays, so 100MB isn’t all that much. Also 64-bit can easily double the memory consumption, given how pointer-happy the ELISP data structures can be (this is somewhat based on my assumptions, I don’t actually know the memory layouts of the different Emacs data structures ;)).

    But I don’t truly know, though. If I start a terminal-only Emacs without any additional lisp code it takes “only” 59232 kilobytes of resident memory. Still more than I’d expect. I’d expect something like 2 MB. But I’ll survive.