<ironm> gfxboot is not my prefered way to create live images with different language/keyboard/... settings - it is an additional work and makes creation of live images more complicated.
<SynrG> i don't think that's a valid argument against it. i think the solution is to make gfxboot easier for developers of live systems easier to use, then <SynrG> gfxboot, imho, is the only sane way to handle very large numbers of languages <SynrG> and to only handle a very small number of languages as you do is a very limited approach that doesn't scale well <SynrG> yes. that no_codename thing hit me too <SynrG> i mentioned it in your bug earlier. have not yet taken action to split it <SynrG> since the bug mentions multiple issues at different layers <ironm> It was _not_ a final solution ... more an idea how to solve it in an easy way <SynrG> gfxboot? or your solution? <ironm> my solution <SynrG> ok. but then if you think there's some way to make it scale that would make it competitive with gfxboot, say so on the bug :) <SynrG> gfxboot is not the only way. it's just the only reasonable way proposed so far. <ironm> I was reading today about using gfxboot .. A LOT of work .. _too_ much for my time resources <ironm> another thing is that I would like to use it also for yaboot .. I am not sure if I can use gfxboot also for yaboot <SynrG> as i said, gfxboot needs to be *integrated* into debian-live <ironm> the standard way (boot menu) allows 150 entries .. it is enough in most cases .. <SynrG> it never was easy for people to hand-edit everything required to make a live image. <SynrG> this is the whole reason for the existence of debian-live <SynrG> 150 entries in multiple screens is not practical in a text interface, i feel. <ironm> gfxboot is not much better ... when you have 150 entries <SynrG> gfxboot is a way out <SynrG> a solution to the problem of presenting far more info than comfortably fits on our present boot menu screens <ironm> my proposal is very easy to use .. I can work more on the code to create dynamically variables for added languages (in the configuration) <ironm> you can scroll down ... <SynrG> gfxboot is not going to make a screen with 150 entries on it <SynrG> my understanding is that gfxboot gives you the ability to add some submenus <SynrG> with syslinux menus you have to navigate away from the initial page <SynrG> this is cumbersome <SynrG> confusing to the end user <ironm> well .. so long live-build doesn't support gfxboot and there is NO documentation about how .. it doesn't exist for an average live-build user <SynrG> yet <SynrG> i think we're discussing where to focus energies in future to solve this. <SynrG> there's nothing preventing you from using your solution *now* <SynrG> we're only discussing what's best for the project in the longer term <SynrG> if gfxboot meets this need (made easy, as you say is necessary and i agree) ... <SynrG> then the project's energies are better spent pursuing this <ironm> as I don't have _any other choice_ I have to use it .. make the code a bit more extendable <ironm> well .. it is only one issue .. the more important one SHOWSTOPPER is just the base-installer issue <SynrG> http://farm4.static.flickr.com/3338/3581212324_833db35145_o.png <SynrG> that looks fine to me <ironm> can I use such gfxboot menu also for yaboot? .. what if installing in an ascii terminal window? <SynrG> if your objection is that for some architectures & hardware some non-gfxboot solution is needed then yes, i can see that point. however, in such corner cases there is always the current solution which is the user specifies the appropriate boot params. <SynrG> it has always been the case that for very old hardware and "strange" architectures the user accepts some burden of extra responsibility to make things work. <ironm> a lot of people have the old MAC mini (PowerPC based) - this boxes are beautiful for editing work (just using a live image) <ironm> for an average user it is EVEN too difficult and complicated to extend the boot command line for the required language and keyboard settings ... <ironm> that means ... a gfxboot is not an universal solution giving you a real free choice <SynrG> this is a problem for the gfxboot project to solve then, isn't it? <SynrG> afaik nothing makes gfxboot inherently x86-only <ironm> SynrG, is it OK for you if I add our "gfxboot discussion" to the ticket? <SynrG> well, i am not certain my *last* assertion here is correct. i did qualify it with 'afaik' <SynrG> i am investigating <SynrG> i see that *currently* there is only x86 support ... <SynrG> i am simply not aware of what the limitations are for future support on other arches <SynrG> there is this: <SynrG> https://blueprints.launchpad.net/ubuntu/+spec/portable-gfxboot <SynrG> it seems to me that people wanting gfxboot-like functionality for non-x86 should get behind projects like this <SynrG> i'm not sure the whole discussion adds value. maybe just some small excerpts of it? <SynrG> anyway, feel free to quote. <SynrG> my principal objections to using syslinux for this job are: <SynrG> 1. there is limited screen space on the initial boot screen. it is not the place for an explosion of the "live" option into per-language options <SynrG> 2. a secondary submenu showing all languages is possible, but this is not what you've implemented. this *may* be a viable alternative that scales well and addresses other arches, but i don't see an easy way to do it ... <SynrG> you said something about scrolling for other languages ... how is that done with syslinux? ironm> Ad. 1 the small amount of space is not a real problem as you can scroll down with the cursor key to make the apropriate language choice <ironm> Ad. 2 keep all things as simple as possible ... I will not use a second menu (syslinux) .. everybody (live image creator) can put the most preffered languages at the beginning in the syslinux boot menu. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
