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

help-circle

  • I just noticed https://lemmy.ml/u/giloronfoo@beehaw.org had proposed the same, but here’s the same but with more words ;).

    I would propose you try to split the data you have manually into logically separate parts, so that you could logically fit 0.8 TB on one drive, 0.4 TB on another, and maybe sets of 0.2TB+0.2TB on a third one. Then you’d have a script that uses traditional backup approaches with modern backup apps to back up the particular data set for the disk you have attached to the system. This approach will allow you to access painlessly modern “infinite increments” backups where you persist older versions of data without doing full and incremental backups separately. You should then write a script to ensure no important data is forgotten to be backed up and that there are no overlapping backups (except for data you want to back up twice?).

    For example, you could have a physical drive with sticker “photos and music” on it to back up your ~/Photos and ~/Music.

    At some point some of those splits might become too large to fit into its allocated storage, which would be additional manual maintenance. Apply foresight to avoid these situations :).

    If that kind of separation is not possible, then I guess tar+multi volume splitting is one option, as suggested elsewhere.










  • I rather enjoy Tilix. It can tile a single tab without tmux and it can also give special handling to links matched from regexps. I use it to go from Python stacktraces to correct line in Emacs with just a click. It can also do Quake-like terminal, which I use alot.

    The project is looking for maintainers, though, so it’s possible at some point I need to start looking for alternatives…






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




  • I doubt there would be a measureable benefit: after all, the kernel is already compiled without 32-bit support, and the code related to it just doesnt exist in the resulting binary. I assume there could be some small exceptions, though, like choosing to do something in a certain way so that the same approach will also work for 32-bit, and opting for another approach would perform better in 64-bit. That’s just a guess, though.

    It’s mostly about maintenance load.

    Btw, with PAE the host can have more than 4 GB of memory, so the limit would only apply to individual processes. Still quite feasible to use that kind of system even in the modern day–even if the browser can sometimes become quite large… And then there are of course the numerous embedded applications.