Thanks for doing this! (1024) I had asked for this earlier this year, suggesting"in 2014, isn't 1024x a reasonable default"
but the reply was"must serve the least capable". With fallback, this should be the perfect happy middle ground.

I've probably also mentioned that I worry the 6sec (?) autostart delay is too short for new users.
An experienced user may know to press downArrow, or Tab or whatever, to suspend the countdown...
...and an experienced user can, if desired, edit syslinux.cfg to lower the timeout.

{placeholder: remember to post about custom boot line}

BTW, I'll recheck to verify, but I don't think those countdown timer/spinner images display during my boot.
(it's possible they've become white noise and I just don't notice 'em)

On the live media, the delay is supposed to be *60* seconds. Does this sound reasonable?

I too prefer the 1024 resolution. I would like to see if it is generally supported.

I am now seeing the spinners, and now see (understand) that the timeout is, indeed, 60secs. (Yes, quite reasonable)
so skip what I started to mention above, regarding custom bootline winding up as entry #2

The current ordering of the boot items is not ideal.
Frugal install and yudder install item... those are one-time-ever operations.
Should be at the bottom of the list (just above memtest) so user doesn't need to scroll past them during every boot.

skidoo wrote:Frugal install and yudder install item... those are one-time-ever operations.

Not true! The *first* time you select"Frugal install" it will do a frugal install. Subsequent times it will boot into the frugal system that you installed. I admit the language is not ideal. We are using"Frugal install" to mean two things:

1. Do a frugal install
2. Boot into a frugal install

I admit that what is new and"hot" tends to move up near the top of lists. But ISTM the worst case scenario is someone who is booting from a LiveCD on a low power system. Unlike a LiveUSB, they really can't edit the bootloader menu. And the LiveCD is usually"fast like snail". If they don't have enough RAM to make good use of"toram" then they really should do a frugal install. Think of it as a"todisk" option. You get a great speed-up. You only have to do the big copy once (instead of every boot like with toram) AND you get the remaster and persistence features. I really think it deserves its spot as the second item on the list. OTOH, maybe it won't get used much.

Command Line install is similar but not identical. It boots into the command line. You are free to install or not from there.

We are limited by how many characters we can squeeze in (in many different languages!). Perhaps it would be more correct to drop"install" from"command line install". I think I would slightly prefer this but there is a tension between being technically accurate and creating large signs that are easy for newbies to follow.

On a LiveUSB you can do a"Save" which allows you to set the defaults so it makes sense to me for those (Persistence) entries to be further down the list.

BitJam wrote:...I changed the default to 1024 but it will fall back to 640 if 1024 does not work.

Of the 10 systems currently on the workbench here, 3 of them fail to boot with a screen resoultion greater than 800x600. I suspect a further one of the 10 will also fail but it is presently untested.

Of the 9 systems tested, they all produce perfectly usable working systems once booted. They represent a cross-section by age with the most modern to fail being an eee netbook manufactured approx 2012. It is not unusual to find kit that fails in the above way.

There are very large numbers of systems that are redundant when used with a demanding operating system. This has been exacerbated by the recent demise of Windows XP. That hardware will be around for years and runs antiX well.

Over a considerable period of time, using 800x600 (vga=788) has consistently produced a working bootable system. A default that can be relied upon is an important consideration. 800x600 will work on the overwhelming majority of kit (probably all kit) both old and new. As described above, 1024x768 does not suit as many cases. The selection of a default is not a question of personal preference but one of usefulness. To adopt one that is known to suit fewer cases than the one it replaces on the grounds of personal preference seems a dubious improvement.

BitJam wrote:You can edit the file /live/boot-dev/antiX/boot/syslinux/gfxboot.cfg to change the default between 1024, 800, and 640.

This feature is appealing. The emphasis will be better placed on a user modifying it to suit their personal preference from a working bootable position, rather than having to modify it in order to acheive a working bootable position. This can be done by using 800x600 as the default resolution.

BitJam wrote:The help menu should be available in all resolutions even though it is only listed in 1024.

This seems akin to saying to a user we have chosen to help/inform you less because your kit cannot use a higher resolution, even though that higher resolution is not required to boot your system.

Additionally, if the help section is only visible in the proposed 1024x768 mode, its availability is apparent to those that need it least. Conversely, if it is not visible at lower resolutions its availability is not apparent to those that potentially need it the most.

Overall it does not seem an egalitarian approach to helping and informing our users.

BitJam wrote:There may look like there is plenty of extra room to the right but this goes away depending on the language selected (and to a lesser extent the time zone and other options).

If the variability of the line length is a constraint, is it possible to remove it from the equation by taking a slightly different approach?

Some random(ish) ideas.


Remove variability Rationale: When a user has opened a section (e.g. Language) and selected their own, there is little to be gained by displaying it in full underneath the section header (F2). They are aware they changed it.

In this way the line length becomes a fixed length that might accommodate the required sections.

Might it be possisble to have the user selected choice indicated when the section is opened? e.g. When desktop has been changed the main menu will show modified, pressing F7 might indicate the one selected such as Space-IceWM.

How about moving F8 Save from the main menu to within F4 Options menu? This will free up further line space without losing functionality.

Thanks for the enlightening post, Sam.

Hmm, I thought I had read that the"desktop" selector was going away (had fallen under the axe).
I didn't welcome the prospect of that change, but it made sense ~~ toward freeing some real estate on the boot screen.
Similarly, The timezone chooser (displayed as a selectbox) is not"necessary", in the sense that
getting it wrong won't interfere with boot, and user can supply tz= on the boot line anyhow, right?

We are using"Frugal install" to mean two things:

Do a frugal install
Boot into a frugal install

The labeling is a tough nut to crack.

regarding"Command Line Install":
Choosing this does nothing beyond the result achieved by manually adding"3" to the boot line?
Without reading docs, I doubt I would have ever tried this option."What? Why would I want, or need, to `install` the commandline?"
If it results in a post-init script which invites the user to install (or exit the script)... oh, okay.
If not, why not just"Boot to command line" as the label, without mentioning `install`?

ps:
@800x600 these shiny new labeled lines will force"memtest" etc lines offscreen?
(and no scrollbar is displayed, eh)

On a LiveUSB you can do a"Save" which allows you to set the defaults

Okay, that's the clincher. I agree.
During most boots, I'll be clicking"Custom Boot" (which is consistently displayed as line#2)

actually, just tried on the netbook, and although I can't boot the 64bit OS, I can see the boot menu screen. F6 menu is half off the screen, and F7 and F8 are gone altogether.

the netbook has a 1024x600 screen.

Thanks for all the great testing!

It is clear we need to stay with the 800x600 default resolution.

Has anyone seen it fall back to the 640x480 resolution?

The"F1 Help" is just a static label. We can easily add it to the background image, perhaps near where it already says"Live". This should make the instructions for pressing F1 to get help stand out even more.

The"F1 Help" is just a static label. We can easily add it to the background image, perhaps near where it already says"Live". This should make the instructions for pressing F1 to get help stand out even more.

I was thinking the same thing...put it in the background.

BitJam wrote:It is clear we need to stay with the 800x600 default resolution.

This is welcome. In such a crucial area (boot up), it is clearly sensible to adopt shipped defaults that work for the greatest number of our users.

Will you clarify which of the following will be the outcome?

Case 1
The default graphic file will use 800x600
The default console resolution will use something greater than 800x600

Result
Will fail to boot on any system that is unable to use a vga boot resolution greater than 800x600.
Refer to my previous post in this thread for examples of this where 3 of 10 systems failed.


Case 2
The default graphic file will use 800x600
The default console resolution will use 800x600
The default console colour depth will be 16 (vga=788) rather than 24 (vga=789) or non-deprecated equivalents.

Result
Will successfully boot on the overwhelming majority of kit (probably all kit) both old and new. I hesitate to say 100% of kit even though I cannot recall a single instance of it failing over years of use and a myriad of different kit.
Refer to my previous post in this thread for examples of this where 3 of 10 systems failed.


Conclusions
In terms of achieving a boot up, Case 2 presents the greastest prospect of success. Straight-out-of-the-box, it suits the largest number of users because it works on the widest range of kit. This seems to be the ideal and expected behaviour for a shipped default setting in a crucial area. From this position a user is able to adjust the shipped defaults by changing them to the values they prefer. In effect they are creating their own personal default settings that are specific to their own local item of kit. These can then be saved via F8 Save to survive for subsequent sessions.

Good points SamK.

The current plan is to have an 800x600 bootloader screen and no vga boot parameter by default. The current"F7 Console menu" (which is masked on LiveUSB systems with the 800x600 bootloader) has a"default" setting that enables framebuffer console decoration (splash=v) but no vga parameter. BTW, you can see that menu even on a LiveUSB by erasing the file /live/boot-dev/boot/syslinux/gfxsave.on. You can get the save menu back by creating a non-empyt gfxsave.on file (as root:) IIUC, these defaults should work as well or better than the ones you suggested. Part of the reason for removing the vga parameter as a default was in response to your previous comments about it. Another part is related to moving graphics drivers into the initrd so they can kick in earlier. If we also have a vga boot parameter then the fbcondecor code gets fooled. It sets the console decoration using the vga=xxx framebuffer then the video module gets loaded creating a different frame buffer and we lose the decoration.

While there are ways of dealing with this, it seemed we would do the greatest good for the greatest number if we left vga=xxxx off by default. Systems that support a modeset driver will get a high resolution frame buffer right away due to the graphics drivers in the initrd. The only one left without a framebuffer are those who need to use"nomodeset" and those who don't have a graphics chipset that is supported by a modeset driver. These people will still be able to use the"F7 Console" menu (when it is available) but by default they will have the standard 80x25 virtual consoles with no decoration.

I just realized there is another small problem with this setup. The"splash=v" boot parameter comes from the"F7 Console" menu. If we replace that menu with"F7 Save' then we lose the splash boot parameter and thus lose console decorations during the early boot process. Technically, we could solve this with the previous scheme of replacing the"F6 Desktop" menu with"F6 Save" but this was counter-intuitive and unpopular.

Given the present development release I am unable to test the information you provide and questions raised. Consequently, the following is largely drawn from what I can infer from that information. Additionally, that restriction means I have refrained from commenting on large sections and may have to revisit much ground once a suitable development release becomes available.

BitJam wrote:The current plan is to have an 800x600 bootloader screen and no vga boot parameter by default.
[...]
IIUC, these defaults should work as well or better than the ones you suggested.

So, we will display a reasonably good looking default boot image file at 800x600. This will switch to 80x25 during the initial stage of the boot procedure and ultimately to someting else at a later stage of the boot up. 80x25 should work with all hardware from the last 25(ish) years but at a cost of being very ugly. 800x600 should work on a similar age range and be more in step with the resolution of the default boot image file.

What colour depth will this use?
In my previous posts it can be seen that the forcing of a 16bit colour depth is a key part of enabling the initial stage of the boot process to succeed, which then allows subsequent switching to occur. In the current plan (where the colour depth is not explicitly specified) if it is possible for the system to default to using a colour depth greater than 16bit, (for the type of kit I mentioned) the boot might still fail at the very initial stage, i.e. before any attempt to load graphics drivers is reached, irrespective of where the drivers are are stored..

BitJam wrote:...fbcondecor code gets fooled. It sets the console decoration using the vga=xxx framebuffer then the video module gets loaded creating a different frame buffer and we lose the decoration.
[...]
While there are ways of dealing with this...

It seems we are unnecessarily creating our own problems for which we then have to invent resolutions/workarounds.

From your earlier comments it looks as though we agree that shipped defaults for the crucial boot role should be as catholic as practicable. Hopefully this is not an unintentional misrepresentation of your view.

Console decoration is essentially eye-candy. It is not required to achieve a successful boot up. In such a case it is suboptimal to allow it to fundamentally influence the boot up process. When using it as a shipped default is adversely affecting reaching the agreed goal, it is a strong argument in favour of it becoming something the user elects to use, rather than something from which the user has to opt out. In this way its constraints do not have to be accommodated at the earliest stage of the boot up, for every user irrespective of whether or not they use it.

Confining any impact in the above manner might enable it to be handled at a different stage/time/location and limit it to only those occasions it is selected. In turn this maximises the potential of reaching the agreed goal for the shipped defaults whilst the user remains able to set their own personal defaults for their specific item of kit.