[lfs-dev] resizecons : a proposal
qrux.qed at gmail.com
Thu May 17 14:33:16 PDT 2012
On May 17, 2012, at 12:31 PM, Ken Moffat wrote:
> On Thu, May 17, 2012 at 01:17:46PM +0800, xinglp wrote:
>> Does the 'setfont' resize the console on the fly as change the
>> "vga=xxx" of grub do.
>> The behavior of changing console's resolution on the fly is usefull
>> when use a "live" lfs.
>> As I don't have X installed.
> No idea - I don't use vga= with grub (although I do use
> video=1024x768 on a machine with a 1600x1200 LCD and an 8x16 font),
> so I don't really know how things appear with that grub option.
> Does this work for you ?
Was resizecons a part of pre-7.1 LFS? If not...What is the rationale for inclusion at this point? It sounds like a horrific thing. Here's a description I've read:
"The resizecons command tries to change the videomode of the console. There are several aspects to this: (a) the kernel must know about it, (b) the hardware must know about it, (c) user programs must know about it, (d) the console font may have to be adapted."
So, we have a program that has these complex interactions, and...provides console size/font management? What is the use-case here? The edge case where developers use the console for development? If it's just a case of "Oh crap, I borked my network settings and I can't SSH in," or "Bummer, I screwed up my X settings, and I can't start X", then I certainly can live for 20 minutes debugging some conf file in vi in a 80x25 window. I'm perfectly happy with the janky BIOS interface (unless newer kernels won't/can't do that anymore).
* * *
Assuming newer kernels can still use the BIOS console interface...
It's not that there aren't reasons. Obviously, there's a lively debate about how to build resizecons, etc, so people are putting in their valuable time. But, a reason doesn't necessarily mean it's a good reason.
When it was suggested that LFS would make a good template for a minimum system, that was met with:
"Oh, Gerard says it's not a minimal system.
"He says it's a full-fledged dev system."
Which I would claim in 2012 is completely bull. How many devs do you know dev straight on the console? Of the oft-quoted tens-of-thousands who've downloaded LFS, what percentage of them develop on the console? Seriously...How many developers do you know who don't interact with their Linux box either through X or through the network? How many use the console? The "full-fledged dev system" might have been true in '94, when it was hard(er) to get X working. I think today, that's a specious argument. I could count the ones I know on one hand...If forming a zero with thumb and index finger is permitted.
It seems to boil down to this. If LFS is *not* a minimal system, but a "full-fledged dev system", then it ought to include a lot of other tools--of which resizecons might be one--to make it a usable dev system. If it is, then why does it routinely get bogged down in trying to keep things like ethtool or brctl out while using an equivalent amount of mail traffic to discuss including things which don't seem worth the conversation time (like resizecons)? What is the size of the target-audience being served by this?
What, exactly, is the technical rationale for putting resizecons in LFS? Or, marketing rationale--if the answer is going to be in terms of an identifiable population that uses the console to dev in any significant way--because there's already a working console. What exactly is the value proposition (in terms of time spent) in making the console slightly (or even a lot) better?
More information about the lfs-dev