[lfs-dev] resizecons : a proposal
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.
> das eine Mal als Tragödie, das andere Mal als Farce
> FAQ: http://www.linuxfromscratch.org/faq/
> Unsubscribe: See the above information page
More information about the lfs-dev