Just to show one possible way to handle the options, I am attaching 2 screenshots.

The specific aesthetics of the boot menu is less important.

In the “first step”, the user chooses which test to run (one of the tests, or cpuinfo, or help, or tips about possible commands).

After the user presses [ENTER] on the selected test, a second selection appears, which only corresponds to the options offered by that specific test.

All is done in one cfg file only, optionally adding the two DISPLAY files that Explorer09 already prepared.

As said, there are other ways. This is just one possibility (with pros and cons).

Attachment:

cpustress1.jpg [ 17.9 KiB | Viewed 56725 times ]

Attachment:

cpustress2.jpg [ 15.44 KiB | Viewed 56725 times ]

Now, regarding the help, ubcdcmd=helpinfo, cmdhelpinfo=* (and I may be forgetting some other option), it seems a little bit confusing. Reading the help files, it is not so clear why there is a need for both "ubcdcmd=helpinfo" and "cmdhelpinfo=*", and that's in addition to the "ubcdcmd=menu" option.

After the user presses [ENTER] on the selected test, a second selection appears, which only corresponds to the options offered by that specific test.All is done in one cfg file only, optionally adding the two DISPLAY files that Explorer09 already prepared.As said, there are other ways. This is just one possibility (with pros and cons).

Some programs, such as Stress, can have many many options to test.

Your idea can work if there's only a few options (or presets) to use. However, none of the program developers offer me such presets.

ady wrote:

Now, regarding the help, ubcdcmd=helpinfo, cmdhelpinfo=* (and I may be forgetting some other option), it seems a little bit confusing. Reading the help files, it is not so clear why there is a need for both "ubcdcmd=helpinfo" and "cmdhelpinfo=*", and that's in addition to the "ubcdcmd=menu" option.

The "cmdhelpinfo" option is to specify which help to display inside the "helpinfo" script. For example, "ubcdcmd=helpinfo cmdhelpinfo=mprime" displays the help of MPrime.

The "ubcdcmd" is generally used to tell CPUstress which program to run after booting. "ubcdcmd=menu" means it will just show the menu.

Perhaps you can read this post by Icecube, in which he had already explained it.

I have implemented a 1-level menu currently because I am unsure what sensible defaults exists for the other programs (eg. Stress, with its large number of parameters - number of CPUs, threads, HDD I/O etc.). So I will hold off the 2nd level menu until I see a more concrete picture of the possible defaults.

The help files are both accessible from the "CPU" menu and the "CPUstress" menu.

It's good to give CPUstress its own menu 'cos the actual version of the image can be indicated independent of the versions of the apps inside.

Victor, I think it would be better for the cpustrs*.txt files to be located in "/ubcd/boot/cpustress/" (and only there), so all the information and help files (and all potential changes and editions) are "contained" together in the same directory (except the boot menus, as usual). In UBCD, there is no need for additional subdirectories nor for additional copies in the menus directory. Then the corresponding line in the cfg files would be for example "

F1 /ubcd/boot/cpustress/cpustrs1.txt

".

***

Note: I am just pointing out the next little issue for the sake of customizations; there shouldn't be any conflict in an official release of UBCD.Those 2 cpustrs*.txt files are "called" from the Syslinux boot menu using F1-F2, which are also used by other help files. In theory, there is no problem using the same Fx keys for different help files, since the calls are located in different Syslinux cfg files that are loaded independently. So an official release of UBCD should be fine with this. But some customizations could have some inconveniences. Using other keys (F3-F4) would be a possible solution for them.

***

Off-topic:Victor, I thought the next release (whenever it may get out) of UBCD would be V.5.2.1 (not 5.3.beta), eventually with small potential corrections and with potential feedback regarding fdubcd superfloppy image.

Also, generally speaking, it should be helpful to post md5 checksums for the files involved in the xdelta command, just in case (I had no problems, but who knows when a bad download could strike, or a mix up with the adequate original ubcd520.iso image).

II have implemented a 1-level menu currently because I am unsure what sensible defaults exists for the other programs (eg. Stress, with its large number of parameters - number of CPUs, threads, HDD I/O etc.). So I will hold off the 2nd level menu until I see a more concrete picture of the possible defaults.

The help files are both accessible from the "CPU" menu and the "CPUstress" menu.

It's good to give CPUstress its own menu 'cos the actual version of the image can be indicated independent of the versions of the apps inside.

My humble opinion. I don't like that additional level of the menu. It will just add confusion.

I suggest another way:

Note the differences:

The CPUstress image become an entry that boots into its own `menu`.

It's in the same level as other stress-test programs, so the user won't need to "crawl" the menus in order to find the program he/she needs.

Some programs, such as Stress, can have many many options to test.Your idea can work if there's only a few options (or presets) to use. However, none of the program developers offer me such presets.

I don't see the conflict, but that's fine. Each user should better learn how to use these programs by himself anyway.

Quote:

Perhaps you can read this post by Icecube, in which he had already explained it.

Sure, I can read the post . My intention, possible incorrectly expressed, was that the help files for CPUStress to be included in UBCD could be more clear regarding these options. Just as an example, what would be the difference between "ubcdcmd=helpinfo" alone and "ubcdcmd=helpinfo cmdhelpinfo=helpinfo"? I don't mean that I need the answer here, but that maybe the help files can be improved.

Victor, I think it would be better for the cpustrs*.txt files to be located in "/ubcd/boot/cpustress/" (and only there), so all the information and help files (and all potential changes and editions) are "contained" together in the same directory (except the boot menus, as usual). In UBCD, there is no need for additional subdirectories nor for additional copies in the menus directory. Then the corresponding line in the cfg files would be for example "

F1 /ubcd/boot/cpustress/cpustrs1.txt

".

Thank you. But I will rather put it in /ubcd/boot/cpustress/help . Because there are too many documents in /ubcd/boot/cpustress/ directory.

Thus the cfg line shall be "

F1 /ubcd/boot/cpustress/help/cpustrs1.txt

"

ady wrote:

My intention, possible incorrectly expressed, was that the help files for CPUStress to be included in UBCD could be more clear regarding these options. Just as an example, what would be the difference between "ubcdcmd=helpinfo" alone and "ubcdcmd=helpinfo cmdhelpinfo=helpinfo"? I don't mean that I need the answer here, but that maybe the help files can be improved.

I think the document in helpinfo is explained well enough. I leave out the cmdhelpinfo thing in cpustrs1.txt because it's too advanced and unnecessary.

I don't see "too many" files in "/ubcd/boot/cpustress/". There are pdf files in the images directory, which contains many more files. The menus have many files and they are not a problem.

It may be just you. For me, there is a readme.txt already, and a changes.txt. I just don't want the directory to look messy when I pack it. If I follow your suggestion, then there will be 6 txt files in the first directory in my 7z archive.

- Image is now called 5.2b4. So the sequence is 5.2b1 => 5.2b2 => 5.2b3 => 5.2.0 => 5.2b4 => 5.2.1 etc. Reason why I am naming it this way is I am trying to keep the length to 5 characters to avoid adjusting the spaces in the title line in default.cfg in between releases. I know, I am lazy. Also, I don't expect a lot of widely-distributed beta releases for minor updates.

- F1, F2 now points to /ubcd/boot/cpustress/help/syslinux/cpustrs*.txt, which is where the files reside in the original package uploaded by Explorer09. I have updated those files to the latest.

- Added separate entry for CPUstress main menu as suggested by Explorer09. It is not the first entry as per your sample cfg file, but the 3rd, because I have a separate script that sorts all the entries in the cfg files alphabetically, and making exception for this one entry will require substantial changes.

In ubcd/boot/cpustress/, can the old-readme.txt and the readme.txt be merged into one file?

Is the "/ubcd/boot/cpustress/bzImage" file actually used in UBCD? I would like to know its utility. Is there any situation where it could be useful (for example, can it be used if for some reason pmagic's bzImage can't? Or in such case this bzImage would not boot either?). To be clear, I am only talking about its inclusion and utility in UBCD. Its inclusion and utility in Explorer's package is clear.

@Explorer, just for convenience, in your text files you might want to express the boot lines (examples and help) in a slightly different way. For example, from you current:

- Image is now called 5.2b4. So the sequence is 5.2b1 => 5.2b2 => 5.2b3 => 5.2.0 => 5.2b4 => 5.2.1 etc. Reason why I am naming it this way is I am trying to keep the length to 5 characters to avoid adjusting the spaces in the title line in default.cfg in between releases. I know, I am lazy. Also, I don't expect a lot of widely-distributed beta releases for minor updates.

.If I were you, I'll try the version like '5.3a1'. I think it is fine to have a sequence like 5.2.0 -> 5.3a1 -> 5.2.1 . Personal opinion.

Victor Chew wrote:

- Added separate entry for CPUstress main menu as suggested by Explorer09. It is not the first entry as per your sample cfg file, but the 3rd, because I have a separate script that sorts all the entries in the cfg files alphabetically, and making exception for this one entry will require substantial changes.

Ok.

ady wrote:

In ubcd/boot/cpustress/, can the old-readme.txt and the readme.txt be merged into one file?

The old readme file is just for historical reference. You can choose to not include it in the UBCD.

ady wrote:

Is the "/ubcd/boot/cpustress/bzImage" file actually used in UBCD? I would like to know its utility. Is there any situation where it could be useful (for example, can it be used if for some reason pmagic's bzImage can't? Or in such case this bzImage would not boot either?). To be clear, I am only talking about its inclusion and utility in UBCD. Its inclusion and utility in Explorer's package is clear.

"/ubcd/boot/cpustress/bzImage" is the old kernel that is used in Icecube's cpustress image. Yes, it is useful when pmagic's bzImage doesn't boot, although that seldom happens.

ady wrote:

@Explorer, just for convenience, in your text files you might want to express the boot lines (examples and help) in a slightly different way. For example, from you current:

If I were you, I'll try the version like '5.3a1'. I think it is fine to have a sequence like 5.2.0 -> 5.3a1 -> 5.2.1 . Personal opinion.

I don't know about others, but using "5.3" just to go back to "5.2" confuses me (not to mention that the current changes only "deserve" a future new 5.2.1 at most, not a 5.3 version). Additionally, "5.3a1" would be interpreted by many (including myself) as the first alpha of a future release "5.3". OTOH, what Victor proposed uniquely identifies each release (whether final or for testing). Under the "5.2" branch (or "line"), "5.2bn" is a testing version, and once in a while a new minor (non-testing) release gets out as "5.2.m". Note that this is different than using "5.2.mbn".

In other words, what Victor proposed is adequate IMO.

Now back on topic. ***

Quote:

ady wrote:

In ubcd/boot/cpustress/, can the old-readme.txt and the readme.txt be merged into one file?

The old readme file is just for historical reference. You can choose to not include it in the UBCD.

That's Victor's decision (but generally speaking, I would be glad if some known-as unnecessary files and unnecessary directories wouldn't be included in UBCD).

Is there anything in the old readme that is currently relevant and that is not part of other included text files? For a hypothetical example, if the only relevant info would be adequate credits, that should be easily merged, shouldn't it?

Explorer09 wrote:

"/ubcd/boot/cpustress/bzImage" is the old kernel that is used in Icecube's cpustress image. Yes, it is useful when pmagic's bzImage doesn't boot, although that seldom happens.

OK. Is there any kind of hardware requirement that would be different between the two bzImage files that would affect CPUStress usage? For example, is it possible that an old system ("old" CPU, relatively small amount of RAM, yet CPU Stress programs are still able to run on such hardware) wouldn't boot with pmagic's bzImage but it would successfully boot with "

/ubcd/boot/cpustress/bzImage

"? (Note: I wouldn't recommend running CPUStress on old hardware anyway, but that's not my concern regarding this question).

My focus regarding this question is about different hardware. I remember users reporting (in the past, not recently) that they were able to use CPUStress with pmagic's bzImage but not with the original, and other users stating exactly the opposite, depending on the hardware they were trying to test.

If both bzImage files are really useful and really necessary, then maybe this should be mentioned somewhere. If only one bzImage is needed to cover all practical cases, then the unnecessary file should be only part of the package (for testing purposes for example) but not part of UBCD.

Quote:

ady wrote:

@Explorer, just for convenience, in your text files you might want to express the boot lines (examples and help) in a slightly different way. For example, from you current:

so the lines are shorter and easier to read. Both formats are equivalent.

If I do that, you'll need to edit the syslinux2grub4dos scripts. Would you do that?

I don't think there would be a need to change syslinux2grub2dos scripts, since Victor already uses a similar format in UBCD as I am suggesting here for your help files (it is not a direct copy from your help files). My suggestion was (is) for convenience and easier reading in your help files (there wouldn't be a need to clarify the artificial use of an extra line for 'append'). But, if the scripts are a concern regarding these lines, I am willing to test and report back if necessary.

Who is online

Users browsing this forum: No registered users and 4 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum