Can we have a more clear persist boot menu?

Forum Forums New users New Users and General Questions Can we have a more clear persist boot menu?

Tagged: , ,

  • This topic has 13 replies, 5 voices, and was last updated Oct 13-1:38 pm by seaken64.
Viewing 14 posts - 1 through 14 (of 14 total)
  • Author
    Posts
  • #27630
    Member
    rayluorayluo

    Hi AntiX team, thanks for all the good work. I’ve been switched to use AntiX exclusively on all my PCs. It has been a pleasant journey so far.

    One question though. Historically there were only 3 kinds of persistence (plus the frugal one which is not really the topic today), documented in the easy-to-find FAQ page here. It was reasonably clear about what they do differently.

    But nowadays the AntiX boot menu provides much more options than them. One of them, the “p_static_root”, was introduced and seemingly only documented in AntiX 19 b1 release note. But I don’t quite get the other new options.

    So, can someone clarify the meaning of those menu items? Perhaps by correcting my understanding and filling the gaps in the table below?

    
    +----------------+-----------------------+----------------------+-----------------------+--+
    | Menu Item      | Persist home on disk? | Persist root in ram? | Persist root on disk? |  |
    +----------------+-----------------------+----------------------+-----------------------+--+
    | persist_home   | Yes                   | No                   | No                    |  |
    +----------------+-----------------------+----------------------+-----------------------+--+
    | persist_root   | Yes? No?              | Yes                  | No                    |  |
    +----------------+-----------------------+----------------------+-----------------------+--+
    | p_static_root  | Yes? No?              | No                   | Yes                   |  |
    +----------------+-----------------------+----------------------+-----------------------+--+
    | persist_static | Yes?                  | No                   | Yes                   |  |
    +----------------+-----------------------+----------------------+-----------------------+--+
    | persist_all    | Yes?                  | ?                    | ?                     |  |
    +----------------+-----------------------+----------------------+-----------------------+--+
    

    Perhaps, when/if we can have a clarification on all those boot options, we can come up with a different set of option names which can be more clear. To that end, trying to map a 2-dimension or even 3-dimension table into a 1-dimension list of options would intrinsically be ineffective. Perhaps we can/should split them into different menus (F5 Persist Home Static: On/Off, F6 Persist Root: Ram/Static/Off, F9 Frugal: On/Off) so that they can naturally support any meaningful combination.

    Thoughts?

    Regards,
    Ray Luo

    #27637
    Member
    Avatarskidoo

    (previously tested) inclusion of additional dropdowns causes the rightmost columns to become inaccessible for users with lesser resolution displays.

    The F1 helptext strives to clarify the implications (“dimensions”) for each of the (e.g. persist_all) labels, because explanation of all the “dimensions” cannot reasonably conveyed via a table ~~ given the limited 80-char (62char?) fixed-width help window.

    re: “a different set of option names which can be more clear”
    Clarity has been sacrificed for the sake of brevity (character count).
    The autosized layout width of each dropdown in the bootmenu is determined by the longest labelstring in its option set.

    The persistence options could (conceivably, per /live/boot-dev/boot/isolinux/README), be moved//expanded and displayed to a separate “custom” gfxboot submenu… but that would incur a LOT of work (setup, and testing) and is subject to diminishing returns (those menus are only accessible to users who are booting Legacy BIOS).

    With the status quo labels, IMO the most likely-to-confuse detail is the (seemingly TRINARY) nomenclature “root” vs “home” vs “all”.

    re: “fill-in-the-blanks”

    We can “reason about” each of the permutations, but because I haven’t tested each of the permutations (e.g. I have never found occasion to use persist_all), I cannot definitively fill in all the blanks.

    Even when discussing only ONE of them, a thorough explanation would require several “asides” due to circular definitions.

    persist_root .... Fast. Only saves root (uses RAM, saves at shutdown)
    
    Root Persist
    Save all the changes to the file-system in RAM and then
    transfer these changes to disk right before you shutdown or reboot.
    Fast, but space is limited by how much RAM you have.

    Predictably, the user will probably wish to preserve (persist) the contents of hisHERtheir home directory. Does the user know/care whether or not that content shall be persisted within a separate (homefs) “container”? If so, meaning the user does know/care… does the user understand that write operations for changed homefs are (always, intrinsically) performed immediately, aka are “static”? Is the user aware of the possibility to additionally utilize Live-USB-Storage?

    “root persist [..] transfers these changes to disk right before you shutdown or reboot”
    This bit confusingly//inaccurately overlooks the manual/semi/auto “dimension” ~~ during semi-automatic mode, changes can be transferred repeatedly, on-demand, throughout the livesession. (as I mentioned above, clarity within the livehelp has been sacrificed for the sake of brevity.)

    re: persist_root “Persist home on disk?”
    Yes, changes to the content are preserved. No, a separate homefs container is not employed. If it were, write operations to it would be “static” and would obviate the the possibility of having the choice of manual/semi/auto.
    -=-
    It stands to reason the moniker “persist_all” exists to describe _that_ scenario ~~ one in which both a rootfs and a homefs are employed. We should (are required to) understand that homefs writes will be immediate and that homefs rootfs writes will be governed by choice of manual/semi/auto.

    • This reply was modified 3 months, 2 weeks ago by skidoo. Reason: typo corrected (thanks rayluo)
    #27645
    Member
    rayluorayluo

    Hi Skidoo, thanks for trying to help! I did learn a thing or two from your response. Besides, I think your last sentence might contain a typo, you probably mean to say “… and that ROOTFS writes will be governed by choice of manual/semi/auto”.

    It is also understandable and generally acceptable that “Clarity has been sacrificed for the sake of brevity (character count)”. It is just that in this case, some brevity are really close to confusion. When we reach to a point that we need some extra mental cycle to “reason about” a menu item, and thought we get it, but then when we saw the next menu item, we are like “wait, wouldn’t this new one more suitable to what I just guessed? Then what was the previous one again?” … We know it is not optimal.

    Even if we understandably do not want to introduce more menus, the 2-dimension table above can comfortably fit inside a (62-character-wide) F1 help window (after wrapping some table header text, of course), so maybe that is a low hanging fruit?

    #27649
    Member
    Avatarskidoo

    Here’s my attempt to shrink the proposed table.
    50chars wide as-is (leaving breathing room for you to modify it further)
    14 lines tall, as-is
    (per mockup screenshot, leaves room for 5 lines of text on Page One of “F5:PersistDetails”)

                  | Persist contents | rootfs content
      Menu Item   |  of /home/*      | occupies ram
                  |                  | during session?
    --------------+------------------+----------------
    persist_home  | Yes              | N/A
    persist_root  | Yes              | Yes
    --------------+------------------+----------------
    p_static_root | Yes              | No
                  |  (inside rootfs) |
    --------------+------------------+----------------
    persist_static|                  |
                  | Yes (saved into  | No
                  | separate homefs) |
    persist_all   |                  | Yes

    .

    #27651
    Member
    Avatarskidoo

    …or 53chars x 11 lines

                  | Persist contents    | rootfs content
      Menu Item   |  of /home/*         | occupies ram
                  |                     | during session?
    --------------+---------------------+----------------
    persist_home  | Yes                 | N/A
    persist_root  | Yes                 | Yes
    --------------+---------------------+----------------
    p_static_root | Yes (inside rootfs) | No
    --------------+---------------------+----------------
    persist_static| Yes (saved into     | No
    persist_all   | separate homefs)    | Yes
    • This reply was modified 3 months, 2 weeks ago by skidoo.
    #27671
    Member
    rayluorayluo

    Admittedly, I did not previous know the F1 Help menu. How come the “F1: Help” is not even listed in the bottom bar? Now only people who somehow already know there is an F1 Help system would use it, people who are new to AntiX – i.e. those who need F1 Help most – won’t know it. That makes no sense.

    Those existing explanation in that F1 Help System for persistence is at least informational for me to fill in the gaps in my 2-dimension table. Combining with Skidoo’s effort (thanks again!), how about the follow table?

    
                  | Persist contents    | Persist contents
      Menu Item   |  of /home/* ?       | of root changes?
    --------------+---------------------+--------------------------
    persist_home  | Save into homefs    | No
    persist_static| Save into homefs    | Save into rootfs
    persist_all   | Save into homefs    | In RAM during session (*)
    --------------+---------------------+--------------------------
    persist_root  | Same home and root in RAM during session (*)
    p_static_root | Save home and root on disk together.
    --------------+------------------------------------------------
    
    (*) In-RAM content can optionally be flushed to disk at shutdown.
    (+) There are another set of frugal_* options which behave the same,
        plus frugal install.
    

    The pre-existing Help page for persistence is already 69chars x 20lines (per page).

    The proposal above is roughly 63chars x 14 lines (including footnote)

    Another question. What is the length limit of each menu option? The “F5 Persist” menu locates at the middle of the screen, therefore I think it still have enough room to contain some longer option names? That would give us tremendous room for improvement (pun not intended). For example, we can change the menu items in above table into these, that way people do not have to rely on F1 Help system.

    
    F5 Persist
    none
    home_only
    home_root_on_disk_separately
    home_on_disk_root_in_ram
    home_root_in_ram
    home_root_on_disk_together
    

    And we can have another set for frugal:

    
    f_home_only
    f_home_root_on_disk_separately
    f_home_on_disk_root_in_ram
    f_home_root_in_ram
    f_home_root_on_disk_together
    
    #27672
    Member
    Avatarskidoo

    .

    thoughts:

    With attention to precluding further circular definition, I would take care to avoid introducing additional terminology.
    What means “flushing”? (doesn’t seem like a synonym for “preserving” or “persisting”, eh)

    The status quo phrasing is already jarringly inexact//inconsistent ~~ example: “persist_home” seen in dropdown labeltext, vs “Home Persist” presented within the F1 helptext.

    Even root (suggesting root user, accountname root) vs rootfs may stand as a source of confusion for some users.

    “disk”? FWIW, several of the (long uptimes, running liveboot sessions) machines here have no fixed storage drives attached.

    #27674
    Member
    VWVW

    It’s all in the FAQ too skidoo, complete with two of Dolphin’s excellent videos.

    “The state is the coldest of all cold monsters. Coldly it lies, too; and this lie creeps from its mouth: `I, the state, am the people.’… Everything about it is false; it bites with stolen teeth. ” ~ Friedrich Nietzsche

    #27685
    Moderator
    masinickmasinick

    Respectfully I believe that we already have a very good system in place. It is a good compromise between capabilities and simplicity.

    Dolphin Oracle does a great job of producing documentation and video demonstration of a significant amount of the features.

    If anything is unclear, ask him. I suspect that he would be happy to simplify and clarity, but it is reasonable to review the existing documentation and video demonstration and question anything that is unclear, specifying “When you say “””…” I am unsure what this (means, does…). Again, such dialogue would either clarify or further improve the offering rather than further complicate and potentially increase confusion.

    Is that a reasonable request for you and others?

    Thanks for your time and feedback.

    Brian Masinick

    #27696
    Member
    Avatarskidoo

    The pre-existing Help page for persistence is already 69chars x 20lines (per page).
    FYI, the F1 help content is authored as an html document (one entire helpdoc, per each language).
    That content gets ‘munged’ and rolled into a cpio blob during the process of compiling the gfxboot component.
    At runtime, the wordwrap applied by the gfxboot presentation will depend on the (pre)configured fontsize and dialogbox size.

    .
    Refer to the screenshot in my earlier post. Apparently gfxboot wraps based on whole words (vs exact char column).
    v—– wordwrap occurs after 66 chars
    Only save changes to files and directories under /home. This will
    include all of your bookmarks and personal settings. Changes are
    ^—– wordwrap occurs after 64 chars

    This portion (as would the table) contains linebreak tags. Above, when I mentioned “50..62char?”, that was from from foggy memory of having suggested alternative verbiage for the painfully short righthand descriptions (necessary to avoid forced linewrap)

    <em>off</em> ......... No Persistence/No frugal<br/>
    <em>persist_all</em> ..... Save root in RAM, save home on disk (save root at shutdown)<br/>
    <em>persist_root</em> .... Save root and home in RAM then saved at shutdown<br/>
    <em>persist_static</em> .. Save root and home on disk with home separate on disk<br/>
    <em>p_static_root</em> .... Save root and home on disk together<br/>

    the 2-dimension table above can comfortably fit…
    maybe that is a low hanging fruit?

    sudo apt install git
    cd (or mkdir, your choice of path)
    git clone https://gitlab.com/antiX-Linux/antiX-Gfxboot

    The helptext document will be available for inspection and editing
    …Help/antiX/en.html

    After editing the document, if you move to the toplevel git project directory and type
    make antix
    the “built” content will be generated in the project’s …/Output/ subdirectory.
    Those files, if you overwrite the same-named files on a stock liveboot pendrive
    you can boot the customized pendrive to test the visual result.
    (If an easier way to “preview//test” exists, I missed seeing that in the inline docs)

    When you are confident that your revised helpdoc content is “ready”,
    you can fork the gitlab.com/antiX-Linux/antiX-Gfxboot repository, add your changed file
    and send a pull request to the upsream project.

    (At gitlab or github, you can even do it all via browser UI: fork, edit the en.html file, send pull request)

    Another question. What is the length limit of each menu option?
    The “F5 Persist” menu locates at the middle of the screen,
    therefore I think it still have enough room to contain some longer option names

    I skimmed through the gfxboot source code files and did not find a “hard limit”. The set of textlabels for each option are parsed (into an array) as string data. The number of items determines (at runtime) the height of the popup box for that optiongroup. The width of the popup box is calculated based on the longest charlength item in the group.

    Similarly, the set of labelnames for the options are concatenated and displayed to a horizontal box at runtime.
    If you edit “Language” to a shorter string (“Lang”) and rebuild… in the result you would see that all the subsequent labels are automagically shifted leftward. If you replace “Language” with an overly-long string (for the sake of testing) e.g “Please select Language”… you’ll notice that the subsequent option names have been pushed rightward. Depending on your display resolution width, it’s entirely possible that the rightmost items will have become inaccessible (they are displayed, but displayed to coordinates which are offscreen out-of-bounds for your screen). Prior to antiX 17, the stated goal was to ensure the legacyBIOS bootmenu rendered correctly for (was accessible to) users with 800×600 displays. As of antix 17, the stated goal (IIRC) is to ensure the bootmenu fits a 1024px wide display.

    Possibly the bootmenu could be revised to present “Language|Timezone|…” via a vertical (vs horizontal) box. Possibly you have the patience (admittedly, I do not) to wrestle with the task of achieving a “re-themed” bootmenu presentation layout.

    ps (ocurred to me while proofreading):
    Configuring gfxboot to use a smaller font size is probably an available way to “fit more onscreen”, but I can’t guess “how small is TOO small” for users with HiDPI displays.

    • This reply was modified 3 months, 2 weeks ago by skidoo.
    #27729
    Member
    rayluorayluo

    .

    Interesting. My distant memory suggests that I might (accidentally?) see such “press F1 for help” phrase before, but it does NOT show up in my 2 laptops here. Not sure whether it is caused by lower screen resolution, my Dell Inspiron 1525 has a 1280×800 screen and my Thinkpad X220 has 1366×768 screen. I can possibly paste a screenshot later.

    Regardless of why/how that “press F1 for help” ends up disappeared, now we know that it is unreliable, this actually brings me back to one of my earlier point: can we revisit the decision to use a too-short-to-be-meaningful, up-to-14-char-long, option names for persistence options? Imagine that if we put the entire “F5 Persist” to be the left-most menu, would it allow its options to have almost the entire screen width hence easily contain a short sentence? That might be an even easier yet more useful approach (albeit still not as clear as a table).

    thoughts:

    With attention to precluding further circular definition, I would take care to avoid introducing additional terminology.
    What means “flushing”? (doesn’t seem like a synonym for “preserving” or “persisting”, eh)

    The status quo phrasing is already jarringly inexact//inconsistent ~~ example: “persist_home” seen in dropdown labeltext, vs “Home Persist” presented within the F1 helptext.

    Even root (suggesting root user, accountname root) vs rootfs may stand as a source of confusion for some users.

    “disk”? FWIW, several of the (long uptimes, running liveboot sessions) machines here have no fixed storage drives attached.

    All these are good points! I consider this forum post is a way to test the water to see whether such an attempt would be blessed by AntiX team (I don’t exactly know whom they are). If so, sure we can work out a Pull Request and then proofread it there.

    The pre-existing Help page for persistence is already 69chars x 20lines (per page).

    the 2-dimension table above can comfortably fit…
    maybe that is a low hanging fruit?

    sudo apt install git
    cd (or mkdir, your choice of path)
    git clone https://gitlab.com/antiX-Linux/antiX-Gfxboot

    The helptext document will be available for inspection and editing
    …Help/antiX/en.html

    After editing the document, if you move to the toplevel git project directory and type
    make antix
    the “built” content will be generated in the project’s …/Output/ subdirectory.
    Those files, if you overwrite the same-named files on a stock liveboot pendrive
    you can boot the customized pendrive to test the visual result.
    (If an easier way to “preview//test” exists, I missed seeing that in the inline docs)

    When you are confident that your revised helpdoc content is “ready”,
    you can fork the gitlab.com/antiX-Linux/antiX-Gfxboot repository, add your changed file
    and send a pull request to the upsream project.

    (At gitlab or github, you can even do it all via browser UI: fork, edit the en.html file, send pull request)

    Thanks for pointing me to that source code repo. I work on open source projects on github daily, so I’m familiar with the process. But again, before sending out a PR, I would like to test the water to see whether such an attempt would at least be considered. So far, it seems none of that repo’s maintainers ever commented in this thread.

    • This reply was modified 3 months, 2 weeks ago by rayluo.
    • This reply was modified 3 months, 2 weeks ago by rayluo.
    #27734
    Member
    rayluorayluo

    Respectfully I believe that we already have a very good system in place. It is a good compromise between capabilities and simplicity.

    Dolphin Oracle does a great job of producing documentation and video demonstration of a significant amount of the features.

    If anything is unclear, ask him. I suspect that he would be happy to simplify and clarity, but it is reasonable to review the existing documentation and video demonstration and question anything that is unclear, specifying “When you say “””…” I am unsure what this (means, does…). Again, such dialogue would either clarify or further improve the offering rather than further complicate and potentially increase confusion.

    Is that a reasonable request for you and others?

    Thanks for your time and feedback.

    Thanks for this comment, too. I think I might need to clarify a few things here.

    1. “it is reasonable to review the existing documentation and video demonstration and question anything that is unclear … Is that a reasonable request for you and others?”

    Not sure what you were trying to hint, but I did STFW before I started this post. I even provided some links in my first post in this thread.

    2. “question anything that is unclear, … such dialogue would either clarify or further improve the offering rather than further complicate and potentially increase confusion.”

    Aren’t we just starting such a dialogue? More specifically, I’m suggesting a systematic approach to potentially improve the help system, including but not limited to its menu position, option name length, help page format (paragraphs VS table), and then wording. If you think any particular suggestion (the wording?) that would “further complicate and potentially increase confusion”, please give specific suggestion, rather than discourage the entire effort.

    3. “Dolphin Oracle does a great job of producing documentation and video demonstration of a significant amount of the features. If anything is unclear, ask him.

    Dolphin Oracle’s work in AntiX is definitely awesome! No question about that! And, at this point in this thread, thanks for all the contributing comments (mainly from Skidoo – I thank him too), I personally gain enough information for ME to better use AntiX persistence. I could just enjoy these information myself. But the whole point of this thread is trying to contribute back to AntiX and, specifically, to potentially help Dolphin Oracle to get him out of the situation that he becomes the bottleneck of answering questions (although we know that he does not normally reply to most of the threads anyway – and even when he does, the reply would be very concise – LOL).

    #27739
    Member
    Avatarskidoo

    800×600, when scaled to fit a 1280px or 1366px screen width…
    yeah, I can imagine the portion of image displaying the embedded F1 msg might wind up offscreen
    and (wow) I don’t recall anyone ever mentioning this throughout the betatesting bughunting topics.

    .

    Imagine that if we put the entire “F5 Persist” to be the left-most menu...
    Sounds like the point I tried to illustrate in prior post was unclear.
    No worries ~~ only the POPUP box widths are affected by the width of the individual option item names.

    #28003
    Member
    Avatarseaken64

    I’m all for better help and more clear menus. However, there are so many things that are “clear” to one person yet lost on another. It is nearly impossible to create and interface that is clear to everyone, even when the resources seem unlimited.

    I would not want to unnecessarily add more work to the developers in an effort to make it more “clear”, which is rather subjective to begin with.

    I admit to being confused as to what are the various options on the “Fx” menus. But this is part of the fun for me. I try it and see what happens. When something happens that I can’t sort out I ask questions and get instruction. Many times the response is to read some document or reference and try to sort it out myself. To me, that is the best way to learn. I could ask for the instructions to be more clear so I could skip reading and trying more stuff. But for me, I like learning by trying and reading.

    I have no problem with this thread and the request for more clarity. Skidoo’s responses were very enlightening to me. But I also agree with others who believe the system we now have in place is good enough. The only thing I can add as a suggestion on this topic is to make sure we have current documentation that matches up with the new menu items when the menus change.

    Seaken64

Viewing 14 posts - 1 through 14 (of 14 total)
  • You must be logged in to reply to this topic.