Keep using syscons -- how?

[Polytropon]

On Wed, 22 Oct 2014 08:10:54 -0500 (CDT), Lars Eighner wrote:
> On Wed, 22 Oct 2014, Polytropon wrote:
> 
> > On Wed, 22 Oct 2014 04:25:12 -0500 (CDT), Lars Eighner wrote:
> >> What do I have to do or not do to keep being able to use syscons in VGA
> >> mode? Is there any way to keep the ability to switch between xwindows and
> >> syscons (in VGA i.e. text mode)?
> >
> > Allow me a more general question. I'm not asking as
> > a "means of insult", but because I'm really interested
> > in the answer:
> >
> > Why not use terminal emulators (xterm, rxvt, konsole,
> > gnome-terminal etc.) inside an X session?
> 
> Because raster fonts are illegible compared to vga fonts,

I always thought X is so superior because of the wide
choice of fonts...



> it is insanely
> difficult to edit the xwindows keyboard compared to editing keymaps in
> syscons,

Can't confirm that. I'm using "programmable keyboards"
(Sun USB type 7, BOSCOM with 5250 layout) with xmodmap,
and it works fine, especially when you have a window
manager that has excellent keyboard support (e. g.
WindowMaker). ;-)



> keeping 11 *terms open fullscreen is very problematic compared with
> switching vttys,

Fullscreen on today's huge screens?

Again, I think this is a problem that can be solved by
using a good window manager that manages virtual desktops,
each one having a terminal emulator in fullscreen. With
good keyboard support, this is just a keystroke away.



> *terms tend to let unicode in instead of maintaining 
> strict iso character sets,

That should be controlled by $LC_* and $LANG environment
variable settings. Personally, Unicode can "pollute" your
files, and the "1 character = 1 byte" paradigm is lost,
and this can affect a lot of other programs (byte counters,
search tools, converters and so on). On the other hand,
the console can be configured to display your local
"special characters" (such as Umlauts and Eszett in
Germany), representing them as 1 byte.



> you end up with extra cursors on the screen and
> with other horrible effects of mousen.

This depends on the terminal emulator and the programs
you're using. I prefer the "no mouse support" option so
I can use the mouse to select text independently from
the cursor position, and also paste text at where the
cursor is located (in opposite to where the mouse pointer
is positioned at).



> Now granted, you can do thing such as making a 4x3 desktop with fvwm or
> possibly a similar windows manager, you can drive yourself crazy trying to
> edit the xwindows keymap so it sort of partially works with everything.

I wrote a tool for that part. :-)



> And
> you are still in point-and-grunt land, burning resources to make things
> pretty for dummies. You cannot kill xwindows and still have a usable
> machine. You have to wait for all the pretty pretties to fire up just to
> check your email. And then you still have to fire up an *term to get a
> command line.

This of course depends on your perception of productivity,
but I tend to agree: The more I think of it, it's really scary
how much time I waste with mouse stuff. That's why I pay attention
to use programs that also have good keyboard support. It's also
important for me to be independent from a specific application
(e. g. mail clients: a lightweight program for X, and one for
the console, both using the same mailbox).



> And of course, xwindows has not really worked since the HAL disaster of a
> a few years back.

When this happened, I decided to rebuild it (and every other
application) _without_ HAL and DBUS, because I don't need any
of those. This was easy in the past, but I'm not sure it is
as easy anymore.



> If you are in Gnome or KDE, abandon all hope.

I tried to configure Gnome to make it halfway usable, it took
me more than a week so everything was partially as I would need
it to be.



> If you can
> get Firefox and GIMP to sort of work in some window manager you have got all
> the good out of xwindows that can be got.

I don't have problem with both, and I use Gimp on a nearly
daily basis.



> Just about everything else is so
> brittle that it breaks if you look at it, and often even if you don't. Try
> charting the dependencies: it looks like a spider operating a Spir-o-graph
> with each leg.

I know what you mean. Do a "make configure-recursive" for some
bigger program for X and end in despair, searching the web for
what the different options mean (because they don't have a name
that would allow you to concluse something), and what new tons
of dependencies they might introduce. I have been told that this
is fully normal and as desired, because of rapid application
development and libraries and APIs and abstractions, which is
the logical consequence of the technical evolution. Resources
which are present _need_ to be consumed, or else there would not
be a need for newer, faster computers every year.

This is a typical expression of this concept:

+--------------------------------------------------------------------+
|                     Options for stupido 19.84                      |
| +----------------------------------------------------------------+ |
| | [X] CUPS         Enable support for printing (requires CUPS)   | |
| | [ ] GTK          Use GTK backend                               | |
| | [ ] KDE4         Use KDE4 backend in room 101                  | |
| | [ ] KLOMPATSH    Use Klompatsh                                 | |
| | [ ] RHUMBOIRE    Use RHUMBOIRE backend                         | |
| | [ ] QUEEKNARG    Enable QUEEKNARG support                      | |
| | [ ] ECK'N'POOT   Build with COM-POOTER module                  | |
| | [ ] SHMEER       Build bindings for SHMEER                     | |
| | [ ] SHLORTS      Enable support for SHLORTS (requires GNOOLFS) | |
| | [ ]              Use nothing, go away.                         | |
+-+----------------------------------------------------------------+-+
|                       [  OK  ]       Cancel                        |
+--------------------------------------------------------------------+

Make your choice. :-)



> The comes from the nonsense of OO.

It's not just OO, in my opinion, it's also "worse is better" in
combination with "everyone runs Linux". Just start some program
from the terminal and see the warnings. You can already see lots
of warnings during compilation which nobody seems to care about.
Also see the "pile of dependencies" concept mentioned above.



> Text mode is robust.  That is really the bottom line.

At least it's more robust than X, but also less complex. This
makes it less usable for today's common workflows...



> > What are reasons (here: your reasons) for switching to
> > text mode from an X session and using the "real" text
> > mode console?
> 
> I generally want to do everything in a vtty except edit graphics and go to
> web sites where I want to see something or when the site is deliberately
> hostile to text browers (cough, Facebook).

This was also my opinion in the past, but somehow, it
changed. It's good to see that this special "attitude"
is still alive. It will hopefully prevent the system
from becoming totally unusable for real work.



> I want to write, read, use databases, and browse the web in text mode. For
> example, if I want to Google something, I want to switch to a vtty to use
> lynx and avoid the garbage. I want to edit text files in a vtty where the
> otherwise invisible unicode markers will standout in order to cut them down.

I can remember having read something comparable:

https://stallman.org/stallman-computing.html

Interesting similarities.



> And of course, I want to switch to the system console to see what if
> anything might be going on.

There's xconsole for X, which will show you the system console's
content. It can even show up when you're not logged in (and the
system is waiting in a display manager, for example xdm). It can
be kept omnipresent in the window manager if desired, or reside
on a virtual desktop on its own.



> >> The command line is already useless in every Linux distribution I can find.
> >
> > Some Linux distributions (usually "the more professional
> > ones") allow easy access to the command line within X,
> > as described above, but in case X isn't running, the
> > text mode consoles are still accessible, even though
> > their "enhanced" screen modes (bigger than 80x25) can
> > cause trouble on some displays which don't display the
> > screen content properly, or don't display it at all.
> > The tiny size of the default fonts may also be a problem
> > on small screens. Yes, I know, _everyone_ has a supermega
> > and ulta HD wide 23" plasma screen these days. :-)
> 
> 
> One's I have tried tend to put the text terminals in something absurd like
> 133x40. And edit the keymap? Forget it!

That seems to be common now, and it's only there for the short
time needed to set up X and continue from there, because "nobody
uses text anymore"...




-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...