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?

        Q


-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Reply via email to