[lfs-dev] resizecons : a proposal

Ken Moffat zarniwhoop at ntlworld.com
Thu May 17 15:28:16 PDT 2012


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.

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce



More information about the lfs-dev mailing list