[lfs-dev] resizecons : a proposal

xinglp xinglp at gmail.com
Fri May 18 00:16:30 PDT 2012

2012/5/18 Ken Moffat <zarniwhoop at ntlworld.com>:
> On Thu, May 17, 2012 at 02:33:16PM -0700, Qrux wrote:
>> On May 17, 2012, at 12:31 PM, Ken Moffat wrote:
>> >
>> > 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:
>  I would hope that you can answer that question from your own build
> logs, but here's my response:
>  Resizecons has been in kbd since what it pleases me to call "time
> immemorial" (technically, that's an English legal phrase, and there
> is a year associated with, somewhere in the 1400s, I think, which is
> obviously an exaggeration for computing questions).  My oldest
> remaining logs are from LFS-6.3 - I purged the older ones, and
> should probably purge some more - where resizecons was built and
> installed.  Note: in those days, LFS was on i?86 only, those of us
> building on ppc or x86_64 had mostly moved to cross-lfs.
>  After LFS became able to build on x86_64, I soon stopped building
> for i686 - the restricted registers just seemed so wrong!  On *all*
> of my x86_64 builds, the resizecons program was not installed but
> its manpage was.  Same on ppc/ppc64 (macs, so using framebuffers).
> But I never noticed until it was queried last week.  I discovered
> that upstream (git) now *does* install resizecons on x86_64 as well
> as i?86, probably after someone raised a bug at SuSe, but it isn't
> useful without svgalib - and that was for linux-2.4, although some
> distros patch it to still build.
>> "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).
>  I would hope that is true for everyone building LFS, although
> modern macs technically use the can of worms called EFI, not a BIOS.
>  I've snipped the rest - on this occasion I agree with your
> sentiments, but you're answering the wrong question : it was noted
> that on x86_64 the manpage exists but the program doesn't.  From
> there I determined that we *could* build it on x86_64, but it could
> not do anything without the obsolete svgalib.
>  My preference is to get rid of it, but there were some alternatives
> in a mail I sent earlier this evening.  Meanwhile, I'm waiting to
> see if xinglp has a problem - we've had this redundant program for
> years now, so best to wait a bit to find out if dropping it will
> expose a problem for someone.

In fact, I didn't know about resizecons until days before.
Since I  found "man ifup" display dash "-" into a "■" on local console,
I diged into kbd, and found resizecons, I think it maybe usefull.
When I use my "live lfs" I put "vga=ask"  in grub,
So, if I can "resizecons" after boot, it's better :-) , but that's not
a easy dream.

> ĸen
> --
> das eine Mal als Tragödie, das andere Mal als Farce
> --
> http://linuxfromscratch.org/mailman/listinfo/lfs-dev
> FAQ: http://www.linuxfromscratch.org/faq/
> Unsubscribe: See the above information page

More information about the lfs-dev mailing list