to X, or not to X...

[crankypuss]

Suppose that, instead of requiring that an X Server always be running in
order to support fullscreen applications, it was optional. That is to
say, what if there was a fullscreen character-mode support layer that
would allow pixel-mode windows to be created as part of its ongoing
character-mode support?

No, I've never written an X Windows application; yes, I've written
custom controls on MS-Windows that drew everything from the border in
and handled all the mouse flyovers and so forth (and reading about X
what I find is that Microsoft even used at least some of the same
message names as X), and yes I've written a character-mode window
manager during a previous life... so yes, I'm talking out of my ass, but
not entirely, so turn the concept over in your head and see how it looks.

Granted, today's "customers" think computers are portable (or not so
portable) entertainment consoles for their enjoyment, and are hard
pressed to simply poke a button on a touchscreen. On the other hand,
some few of us still persistently consider computers to be tools for
working with information. And frankly we few seem to have been left in
the dust by the pretty-icon crowd.

Suppose you want to build an application that uses a fullscreen approach
but doesn't need icons with pictures of padlocks and floppy disks. All
it needs is characters... letters and words. And you want it to run no
matter what else is running.

If you run it from a GUI seat you need to bring up a terminal emulator
because only terminal emulators don't think that icons are god. If you
run it from a non-GUI seat you're still stuck running through a terminal
emulator (type="linux" on this distro). In either case, someone has
trapped a bunch of the keys for Their Very Own control purposes. And in
both cases, the option of using char-down and char-up events for the
control key are out the window unless you start twiddling the user's
settings at a minimum.

Then there are the umpteen layers of support libraries between the
hardware and the application, and when X is in the picture there's some
socket protocol involved. The amount of waste is enormous, the
potential for mismatching libraries is huge, and the whole thing seems
like a big mess.

Maybe I'm wishing for the good old days when the bulk of the computer's
power wasn't being wasted by library after library, thinking how stoopid
it is that the size specifications for character-mode terminal emulators
have to be given in pixels instead of characters, and so on and so forth.

Programs like installers and backup/restore utilities ought not need the
whole pyramid in order to function. So you few who inhabit this usenet
group (golly it isn't a web forum with smiley-face icons), what do you
think about going back to basics in a way that doesn't require all the X
applications and all the applications that are built on top of the
various libraries to make X applications easier to write be thrown away?

[Russell Shaw]

I think about the good old days every day. The only thing holding back
advancement of the open desktop graphics system is poorly documented or
proprietory graphics hardware, preventing anyone from making a new graphics
system. Wayland is new, but that's being developed by Intel, so they have
insider information.

Really, the only way to come up with a new system with minimal graphics cruft is
to make your own computer using only hardware with freely available
documentation. You may need to make the equivalent of a GPU with a larger number
of components such as small multicore CPUs or an FPGA, but it would be worth it
even if it ran 100x slower than a proprietory GPU, yet could still play MPEG.
The only loss would be action games, but i don't do games anyway.

[Ivan Shmakov]

>>>>> crankypuss <noe...@noemail.invalid> writes:

[Cross-posting to news:comp.windows.x, for this discussion is
hardly specific to its GNU/Linux implementations.]

> Suppose that, instead of requiring that an X Server always be running
> in order to support fullscreen applications, it was optional. That
> is to say, what if there was a fullscreen character-mode support
> layer that would allow pixel-mode windows to be created as part of
> its ongoing character-mode support?

As in: Wayland?

[...]

> So you few who inhabit this usenet group (golly it isn't a web forum
> with smiley-face icons),

It depends on the software used. For instance, Gnus provides a
setting to substitute smiley-face icons for ASCII smileys.
OTOH, one'd hardly encounter any icons on Web fora when using
Lynx, as I do.

> what do you think about going back to basics in a way that doesn't
> require all the X applications and all the applications that are
> built on top of the various libraries to make X applications easier
> to write be thrown away?

I think that if I can't run it over SSH, it doesn't worth the
effort. (Why, I now have four machines running continuously in
my bedroom's network.) Naturally, both X and "text terminal"
applications are capable of that.

The inability of the applications to take certain keys or their
combinations for their own uses away from an unsuspecting user
(as in: me) looks like an advantage on its own. At least after
the logic behind such behavior is revealed.

But I do agree that the situation with "X libraries" (or,
rather, GUI toolkits) is somewhat a bitter one. My current
preference (though I hardly do any serious GUI programming) is
Tk, but even it has some issues.

--
FSF associate member #7257 np. Know Why the Nightingale Sings -- Nightwish

[Aragorn]

On Saturday 23 February 2013 20:33, crankypuss conveyed the following to
comp.os.linux.x...

> Suppose that, instead of requiring that an X Server always be running
> in order to support fullscreen applications, it was optional.

Well, X /is/ optional. On my systems, X does not start automatically at
boot time. I log into my user account on a virtual console and then
start X manually for my user account via "startx".

> That is to say, what if there was a fullscreen character-mode support
> layer that would allow pixel-mode windows to be created as part of its
> ongoing character-mode support?

I believe that it is already possible to use pixel mode graphics on non-
X11 terminals, provided that the system is using something like the vesa
console framebuffer driver, or the likes. You can see this effect if
you are running a distribution which, during the kernel bootstrap
process, shows you penguins at the top of the screen (or some
distribution-specific logo) to show you the number of (virtual) CPUs in
the system.

Of course, implementing this for (physical or emulated) terminals over
an ssh connection or connected to the machine via USB or RS-232 is
another thing, and so is the ability to map pixel-mode windows onto that
framebuffer when the framebuffer is primarily used for raster/character
mode output.

Ivan Shmakov mentioned Wayland, but while Wayland has some interesting
features, it also has some negative ones, such as the fact that it does
not support network transparency (which X11 does) and that it runs in
the kernel (as the display servers of Microsoft Windows and Apple OSX
do). And the latter is /not/ a good idea.

> No, I've never written an X Windows application; yes, I've written
> custom controls on MS-Windows that drew everything from the border in
> and handled all the mouse flyovers and so forth (and reading about X
> what I find is that Microsoft even used at least some of the same
> message names as X), and yes I've written a character-mode window
> manager during a previous life... so yes, I'm talking out of my ass,
> but not entirely, so turn the concept over in your head and see how it
> looks.

Character mode window managers do exist for UNIX-style systems, albeit
that their look & feel is a bit different from the ones running on DOS
at the time (such as Quarterdeck DesqView or IBM TopView). GNU screen
and tmux are both so-called terminal multiplexers, and thus character
mode window managers, if you will. They can also detach the session
from the active terminal, so that you can attach another terminal to the
session later and continue working from another physical location.

But of course, this does not address the ability to overlay pixel mode
graphics onto a character mode raster graphics terminal.

> Granted, today's "customers" think computers are portable (or not so
> portable) entertainment consoles for their enjoyment, and are hard
> pressed to simply poke a button on a touchscreen.

I think the term you are looking for is "household appliances". :p

> On the other hand, some few of us still persistently consider
> computers to be tools for working with information. And frankly we
> few seem to have been left in the dust by the pretty-icon crowd.

I agree with that. While I personally do like my shiny, themed KDE4
desktop - which I have completely customized to match /my/ preferences,
and not those of people who feel that everything should look like
Microsoft Windows - I also often find myself nostalgically logging into
a few pure character mode sessions. After all, that's where text is the
most readable, because that's what those terminals were designed for:
text (and other raster mode glyphs).

I used to do some programming back in the days of DOS, and I continued
doing that - albeit with slightly different tools - on OS/2, but always
in character mode. I used the OS/2-proper ReXX scripting language, but
I steered clear from anything GUI-related, so that my ReXX stuff would
run in full-screen character mode sessions only, or in "OS/2 prompt"
windows.

In fact, the whole Windows/GUI hype was one of the main reasons why I
stopped writing programs altogether - I was not a professional
developer, mind you - because all the code needed for that graphical
junk and buttons and mouse actions and whatever made me feel like I was
trying to write a database application in assembler: way too much code
and way too much bloat. Function became subordinate to form.

> Suppose you want to build an application that uses a fullscreen
> approach but doesn't need icons with pictures of padlocks and floppy
> disks. All it needs is characters... letters and words. And you want
> it to run no matter what else is running.
>
> If you run it from a GUI seat you need to bring up a terminal emulator
> because only terminal emulators don't think that icons are god. If
> you run it from a non-GUI seat you're still stuck running through a
> terminal emulator (type="linux" on this distro).

The terminal is not an evil concept, since we /are/ talking of a multi-
user operating system, and thus there has to be an abstraction layer
which makes multi-seat scenarios possible.

UNIX was designed as a multi-user operating system - unlike for instance
Microsoft Windows, which is an evolution of the DOS philosophy, where
every computer was used by one person only - and as such, I think it is
important to keep the concept of a (physical, virtual or emulated)
terminal alive.

> In either case, someone has trapped a bunch of the keys for Their Very
> Own control purposes. And in both cases, the option of using char-
> down and char-up events for the control key are out the window unless
> you start twiddling the user's settings at a minimum.

I'm afraid I don't follow here. What do you mean by "char-up and char-
down events for the control key"?

Remember that I am not a developer and I also don't have any degrees in
computer science, plus that there could (eventually but not necessarily)
also be some language barrier issue here.

> Then there are the umpteen layers of support libraries between the
> hardware and the application, and when X is in the picture there's
> some socket protocol involved. The amount of waste is enormous, the
> potential for mismatching libraries is huge, and the whole thing seems
> like a big mess.

X was primarily intended to be network-transparent. It allows one to
use things like thin clients, for instance. That's why it's so cool.
:-)

> Maybe I'm wishing for the good old days when the bulk of the
> computer's power wasn't being wasted by library after library,
> thinking how stoopid it is that the size specifications for
> character-mode terminal emulators have to be given in pixels instead
> of characters, and so on and so forth.

Well, Joe Sixpack wants pixels because he's now also using his computer
to watch DVDs on in High Definition. With Dolby Surround sound. And
those colored 3D goggles. :p

> Programs like installers and backup/restore utilities ought not need
> the whole pyramid in order to function.

True, but the users - who for most part these days all come from the
Windows world - want the shiny and pointy-clicky stuff, and so
distribution developers create their installers as shiny, pointy-clicky
things, and set up the system to boot up into a graphical display
manager and log-in, and people aren't even aware of the existence of the
character mode virtual consoles anymore.

It's the Microsoft Windows and Apple MacIntosh mentality. It has made
access to computer technology more democratic, but at the cost of
corrupting the expectations and instilling a completely erroneous view
on what computers are, how they behave and what you should use them for
into the minds of the grey, unwashed masses.

> So you few who inhabit this usenet group (golly it isn't a web forum
> with smiley-face icons), what do you think about going back to basics
> in a way that doesn't require all the X applications and all the
> applications that are built on top of the various libraries to make X
> applications easier to write be thrown away?

I would personally welcome more character mode-oriented applications and
interfaces again, but the point here is that I am by no means
representative for the vast hordes of ex-Windows-user GNUbies who demand
the pointy-clicky stuff.

On the other hand, I wouldn't want to dismiss X11 altogether either. As
a network-transparent display server, it is a fantastic thing to have,
and architecturally still a better solution than Wayland - which doesn't
support network transparency and runs in the kernel, which introduces a
significant vulnerability and instability factor - but alas, X11 has
been seriously abused by the Microsofties and the MacIntosh fans.

The former because they don't know any better - we mustn't forget that
many of today's developers have themselves already grown up in a world
where Windows was the established hegemony - and the latter because
Steve Jobs made a rip-off of Xerox PARC and the Apple snobs consider
themselves part of an artistic elite.

--
= Aragorn =
(registered GNU/Linux user #223157)

[crankypuss]

On 02/24/2013 03:58 AM, Russell Shaw wrote:
> I think about the good old days every day. The only thing holding back
> advancement of the open desktop graphics system is poorly documented or
> proprietory graphics hardware, preventing anyone from making a new
> graphics system. Wayland is new, but that's being developed by Intel, so
> they have insider information.
>
> Really, the only way to come up with a new system with minimal graphics
> cruft is to make your own computer using only hardware with freely
> available documentation. You may need to make the equivalent of a GPU
> with a larger number of components such as small multicore CPUs or an
> FPGA, but it would be worth it even if it ran 100x slower than a
> proprietory GPU, yet could still play MPEG. The only loss would be
> action games, but i don't do games anyway.

I'm not against the idea of having some custom hardware made up. On the
other hand, I don't see why that should be necessary. And given a
version of such software that could be used by older hardware, showing
the increase in performance and flexibility it is likely to afford, the
natural greed of hardware makers would lead them to provide whatever
hardware turns out to be beneficial.

There's nothing wrong with the capabilities provided by the existing
graphics hardware as far as I can tell, it's the software that I see as
somewhat less than optimal.

[crankypuss]

On 02/24/2013 04:10 AM, Ivan Shmakov wrote:
>>>>>> crankypuss <noe...@noemail.invalid> writes:
>
> [Cross-posting to news:comp.windows.x, for this discussion is
> hardly specific to its GNU/Linux implementations.]
>
> > Suppose that, instead of requiring that an X Server always be running
> > in order to support fullscreen applications, it was optional. That
> > is to say, what if there was a fullscreen character-mode support
> > layer that would allow pixel-mode windows to be created as part of
> > its ongoing character-mode support?
>
> As in: Wayland?

I'm not familiar with Wayland other than having gotten the idea that it
is a replacement for x11 that is under development and that people seem
to disapprove of, am I in the process of reinventing their wheel?

> > what do you think about going back to basics in a way that doesn't
> > require all the X applications and all the applications that are
> > built on top of the various libraries to make X applications easier
> > to write be thrown away?
>
> I think that if I can't run it over SSH, it doesn't worth the
> effort. (Why, I now have four machines running continuously in
> my bedroom's network.) Naturally, both X and "text terminal"
> applications are capable of that.

There seems to be a definite need to remotely control headless servers,
but that seems (to me at least) to be something of an application issue.
On a conceptual basis any subroutine can be called through a
socket-like connection as long as the amount of data transferred and the
latency involved do not create insurmountable performance problems; the
main issue involved in controlling headless servers (imo) really amounts
to the security of the connection and the availability of suitable
software on both sides. I don't see it as problematic.

> The inability of the applications to take certain keys or their
> combinations for their own uses away from an unsuspecting user
> (as in: me) looks like an advantage on its own. At least after
> the logic behind such behavior is revealed.

There should (imo) be *one* inviolate key combination that is owned by
the "operating system" and can be used at any time to escape into a
known and trusted environment. Beyond that, applications should (imo)
be able to use whatever they please, keeping in mind that "applications"
may consist of many levels that set up increasingly specific conventions
for the user environments they create.

> But I do agree that the situation with "X libraries" (or,
> rather, GUI toolkits) is somewhat a bitter one. My current
> preference (though I hardly do any serious GUI programming) is
> Tk, but even it has some issues.
>

Since I want my applications to run whether or not an X server has been
started (or whether X is even installed), I've been using an abstraction
based on ncurses and relaunching into a terminal emulator when
necessary. It is not what I consider an acceptable solution.

[Aragorn]

On Sunday 24 February 2013 14:06, crankypuss conveyed the following to
comp.os.linux.x...

Latency is generally only a problem in this context when the remote user
wants to have all the eye candy available over the network connection -
think "remote desktop". Pure character mode implementations are
generally not that bandwidth-hungry. That's another argument in favor
of character mode. :-)

>> The inability of the applications to take certain keys or their
>> combinations for their own uses away from an unsuspecting user
>> (as in: me) looks like an advantage on its own. At least after
>> the logic behind such behavior is revealed.
>
> There should (imo) be *one* inviolate key combination that is owned by
> the "operating system" and can be used at any time to escape into a
> known and trusted environment. Beyond that, applications should (imo)
> be able to use whatever they please, keeping in mind that
> "applications" may consist of many levels that set up increasingly
> specific conventions for the user environments they create.

Well, the Linux kernel does have the "magic SysRq" keys to let the
operator at the local console interact with the system directly - but
on-screen feedback of this interaction is of course restricted to
character mode, as the X server doesn't have any way of trapping said
output - but other than that, everything is pretty much defined at the
application layer.

>> But I do agree that the situation with "X libraries" (or,
>> rather, GUI toolkits) is somewhat a bitter one. My current
>> preference (though I hardly do any serious GUI programming) is
>> Tk, but even it has some issues.
>
> Since I want my applications to run whether or not an X server has
> been started (or whether X is even installed), I've been using an
> abstraction based on ncurses and relaunching into a terminal emulator
> when necessary. It is not what I consider an acceptable solution.

One of the (many) things I find interesting about a UNIX-style operating
system is that the applications are typically written with separation of
function and form, which on account of X Window System applications
typically means that they are only GUI front-ends to the same tools as
one would use from a command line prompt - office suite applications
such as LibreOffice et al excluded, of course.

In earlier RedHat distributions and derivatives (such as early
Mandrake), you had a number of tools for system administration which ran
with an ncurses interface when invoked in a pure character mode
terminal, or with an xlib interface when invoked from within a GUI -
including starting them from a terminal emulator window in a GUI
environment.

The version of GNU emacs which I have here on my system behaves
similarly. If I start it in a pure character mode virtual console,
it'll have the conventional emacs user interface, and if I start it from
a terminal emulator window or a shortcut icon or menu entry in a GUI
environment on top of X, then it'll have a graphical user interface.
Not quite the same interface as with xemacs - as that's a different
thing - but you still do get some of the advantages of the GUI, such as
a more prominent syntax highlighting with different fonts and font
attributes - e.g. italicized for comments - et al.

The main problem, as I see it, is the biological unit between the
keyboard and the chair, and that which said biological unit has adopted
as "the norm", with a little help of other biological units in which
typically large amounts of the intelligent logic either have become
defunct or entered a power savings mode from which they continuously
fail to recover. <grin>

[crankypuss]

On 02/24/2013 05:08 AM, Aragorn wrote:

<snip>

> But of course, this does not address the ability to overlay pixel mode
> graphics onto a character mode raster graphics terminal.

<snip>

> The terminal is not an evil concept, since we /are/ talking of a multi-
> user operating system, and thus there has to be an abstraction layer
> which makes multi-seat scenarios possible.
>
> UNIX was designed as a multi-user operating system - unlike for instance
> Microsoft Windows, which is an evolution of the DOS philosophy, where
> every computer was used by one person only - and as such, I think it is
> important to keep the concept of a (physical, virtual or emulated)
> terminal alive.

We may have to agree to disagree on this one Aragorn, or perhaps
redefine the word "terminal". What I think of as a "terminal" *is* an
evil concept, and the concept of "multi user operating system" is
grossly outmoded.

I have in front of me a device that displays pixels, and a keyboard, and
a mouse. If you want to call that set of hardware a "terminal" we might
come to some agreement. On the other hand, if you want me to remain in
the obeisance position before an array of obsolete hardware ranging from
the KSR to the 327x and beyond then we will never come to any sensible
agreement; the idea of having software convert display calls into
various arcane and obsolete sequences of characters so those can be sent
to a "terminal emulator" which deciphers them and finally after all this
possibility of translation error for the purpose of much processor
wastage writes them to the device in front of me that displays pixels, I
am going to fight that all the way. I am also of the opinion that
vector-mode "terminals" are now obsolete given the level of resolution
possible in terms of pixels, except insofar as their interfaces might
represent specialized manufacturing hardware that moves a scribe or
router from one position to another etc.

As for the "multi user operating system", the concept is a joke; there
are clients and there are servers, connected by local or remote
protocols, and any numeric relationship between the number of clients
and the number of servers is completely artificial until after you've
implemented the whole. Port-80 on google.com probably splits into
dozens (or hundreds) of servers and they may well be the clients of
several database servers. The fact that some "operating systems" are
only capable of supporting a single client is symptomatic of their
inadequacy and little more, they are nothing more than a special case of
the client-server paradigm which uses local-only communication.

>> In either case, someone has trapped a bunch of the keys for Their Very
>> Own control purposes. And in both cases, the option of using char-
>> down and char-up events for the control key are out the window unless
>> you start twiddling the user's settings at a minimum.
>
> I'm afraid I don't follow here. What do you mean by "char-up and char-
> down events for the control key"?

What I mean is, when the user pushes the ctl key I want to be notified,
and when the user releases the ctl key I want a separate notification;
without key-down and key-up events it is basically impossible to pop up
the appropriate auxiliary windows when they are desired.

> Remember that I am not a developer and I also don't have any degrees in
> computer science, plus that there could (eventually but not necessarily)
> also be some language barrier issue here.

I'll remember it if you will. We don't all know the same things and we
haven't all run through the gauntlets which taught us the hard ones;
that doesn't mean we're unable to work together to solve common problems.

[Ivan Shmakov]

>>>>> crankypuss <noe...@noemail.invalid> writes:
>>>>> On 02/24/2013 04:10 AM, Ivan Shmakov wrote:

[...]

>> I think that if I can't run it over SSH, it doesn't worth the
>> effort. (Why, I now have four machines running continuously in my
>> bedroom's network.) Naturally, both X and "text terminal"
>> applications are capable of that.

> There seems to be a definite need to remotely control headless
> servers,

It's not only about "headless servers", it's also about the
ability to have an application installed and configured at one
place (host), but to be available at another. It may be
unreasonable to install such an application just everywhere, for
it may require:

* a different OS or distribution that's needed at the place it's
to be used; (due to a "must have" application there, for
instance);

* too much effort to synchronize the working state of such an
application between hosts (as in: reading netnews from several
places; won't it become necessary to keep .newsrc in sync?);

* more resources that are physically available at that place (as
in: modelling and computations software may require a better
CPU's and larger RAM that's available at the machine sitting
on one's table.)

[...]

> the main issue involved in controlling headless servers (imo) really
> amounts to the security of the connection and the availability of
> suitable software on both sides. I don't see it as problematic.

With text terminal-oriented applications, the /only/ software
that needs to be available "on the other side" is SSH. Which is
a huge win.

Also to note is that in the GNU world, the majority of "server"
applications may be configured via either a text editor, or a
command-line tool (or both.) Both of which are easily
"SSH-friendly" means.

>> The inability of the applications to take certain keys or their
>> combinations for their own uses away from an unsuspecting user (as
>> in: me) looks like an advantage on its own. At least after the
>> logic behind such behavior is revealed.

> There should (imo) be *one* inviolate key combination that is owned
> by the "operating system" and can be used at any time to escape into
> a known and trusted environment. Beyond that, applications should
> (imo) be able to use whatever they please, keeping in mind that
> "applications" may consist of many levels that set up increasingly
> specific conventions for the user environments they create.

How do you prevent abuse from such an all-powerful application?

Say, my preference is that Alt-F4 brings to me the 4'th virtual
terminal. Now, an application developer decided that the "Quit"
command is to be bound to such a sequence. Given the system
suggested, how do you prevent him or her from doing just that?

Conceptually, it's right, indeed, but my preference is that some
of the aforementioned "levels" reside in a place which can only
be altered using a privileged user account ("root".)

From this viewpoint, the idea of using HTML forms for a user
interface has its merit, BTW: with a single application directly
interfacing the user, the chances of the "payload" application
getting "out of hand" are lower than ever. (Somehow, I believe
that NeWS advocated essentially the same approach.)

[...]

> Since I want my applications to run whether or not an X server has
> been started (or whether X is even installed), I've been using an
> abstraction based on ncurses and relaunching into a terminal emulator
> when necessary. It is not what I consider an acceptable solution.

Indeed.

FWIW, I start my applications under GNU Screen, and then detach
and re-attach them to the terminals as I see fit. This way, I
may go from a text VT to an XTerm window to a remote SSH session
(and then back again) almost instantly, without having to
re-launch my applications at any time.

[Aragorn]

On Sunday 24 February 2013 14:41, crankypuss conveyed the following to
comp.os.linux.x...

> On 02/24/2013 05:08 AM, Aragorn wrote:
>
>> The terminal is not an evil concept, since we /are/ talking of a
>> multi- user operating system, and thus there has to be an abstraction
>> layer which makes multi-seat scenarios possible.
>>
>> UNIX was designed as a multi-user operating system - unlike for
>> instance Microsoft Windows, which is an evolution of the DOS
>> philosophy, where every computer was used by one person only - and as
>> such, I think it is important to keep the concept of a (physical,
>> virtual or emulated) terminal alive.
>
> We may have to agree to disagree on this one Aragorn, or perhaps
> redefine the word "terminal". What I think of as a "terminal" *is* an
> evil concept, and the concept of "multi user operating system" is
> grossly outmoded.
>
> I have in front of me a device that displays pixels, and a keyboard,
> and a mouse. If you want to call that set of hardware a "terminal" we
> might come to some agreement.

Yes. It needs no further refinement than that description. However, an
operating system should offer support for multiple such terminals (as
defined in this manner).

> [...]

>
> As for the "multi user operating system", the concept is a joke; there
> are clients and there are servers, connected by local or remote
> protocols, and any numeric relationship between the number of clients
> and the number of servers is completely artificial until after you've
> implemented the whole. Port-80 on google.com probably splits into
> dozens (or hundreds) of servers and they may well be the clients of
> several database servers. The fact that some "operating systems" are
> only capable of supporting a single client is symptomatic of their
> inadequacy and little more, they are nothing more than a special case
> of the client-server paradigm which uses local-only communication.

Well, I do not see multi-user functionality as separate from the
client/server paradigm.

>>> In either case, someone has trapped a bunch of the keys for Their
>>> Very Own control purposes. And in both cases, the option of using
>>> char- down and char-up events for the control key are out the window
>>> unless you start twiddling the user's settings at a minimum.
>>
>> I'm afraid I don't follow here. What do you mean by "char-up and
>> char- down events for the control key"?
>
> What I mean is, when the user pushes the ctl key I want to be
> notified, and when the user releases the ctl key I want a separate
> notification; without key-down and key-up events it is basically
> impossible to pop up the appropriate auxiliary windows when they are
> desired.

Well, historically the Ctrl key has been used to enter special character
sequences at the application level, but as I said, if you're looking for
something which /directly/ interfaces with the operating system itself,
then that is what the System Requests are for.

>> Remember that I am not a developer and I also don't have any degrees
>> in computer science, plus that there could (eventually but not
>> necessarily) also be some language barrier issue here.
>
> I'll remember it if you will. We don't all know the same things and
> we haven't all run through the gauntlets which taught us the hard
> ones; that doesn't mean we're unable to work together to solve common
> problems.

Of course. And I may not have the diplomas hanging from my wall, but I
do have quite a bit of experience in the field, and a mind capable of
thinking about The Greater Good (tm), unlike some half-brained
individuals you and I know to be dwelling in a newsgroup for an over-
hyped GNU/Linux distribution which tries very hard not to look like
GNU/Linux anymore. <grin>

[crankypuss]

On 02/24/2013 08:19 AM, Aragorn wrote:
> On Sunday 24 February 2013 14:41, crankypuss conveyed the following to
> comp.os.linux.x...
>
>> On 02/24/2013 05:08 AM, Aragorn wrote:
>>
>>> The terminal is not an evil concept, since we /are/ talking of a
>>> multi- user operating system, and thus there has to be an abstraction
>>> layer which makes multi-seat scenarios possible.
>>>
>>> UNIX was designed as a multi-user operating system - unlike for
>>> instance Microsoft Windows, which is an evolution of the DOS
>>> philosophy, where every computer was used by one person only - and as
>>> such, I think it is important to keep the concept of a (physical,
>>> virtual or emulated) terminal alive.
>>
>> We may have to agree to disagree on this one Aragorn, or perhaps
>> redefine the word "terminal". What I think of as a "terminal" *is* an
>> evil concept, and the concept of "multi user operating system" is
>> grossly outmoded.
>>
>> I have in front of me a device that displays pixels, and a keyboard,
>> and a mouse. If you want to call that set of hardware a "terminal" we
>> might come to some agreement.
>
> Yes. It needs no further refinement than that description. However, an
> operating system should offer support for multiple such terminals (as
> defined in this manner).

I think some further clarification might be needed. I intend to compose
a second reply to Ivan's original response, where he decided to
crosspost since he considers this not a linux-specific topic, so please
do read that when it appears.

>> [...]
>>
>> As for the "multi user operating system", the concept is a joke; there
>> are clients and there are servers, connected by local or remote
>> protocols, and any numeric relationship between the number of clients
>> and the number of servers is completely artificial until after you've
>> implemented the whole. Port-80 on google.com probably splits into
>> dozens (or hundreds) of servers and they may well be the clients of
>> several database servers. The fact that some "operating systems" are
>> only capable of supporting a single client is symptomatic of their
>> inadequacy and little more, they are nothing more than a special case
>> of the client-server paradigm which uses local-only communication.
>
> Well, I do not see multi-user functionality as separate from the
> client/server paradigm.

It is only the ability of the operating system to track the ownership of
the resources it has allocated (the most obvious example being files)
that makes an operating system capable of handling multiple users.

[crankypuss]

We seem to have (already) moved into the realm of apples vs oranges,
please see my second reply to your initial post in this thread.

[Aragorn]

On Sunday 24 February 2013 19:14, crankypuss conveyed the following to

comp.os.linux.x...

> On 02/24/2013 08:19 AM, Aragorn wrote:
>
>> On Sunday 24 February 2013 14:41, crankypuss conveyed the following
>> to comp.os.linux.x...
>>
>>> On 02/24/2013 05:08 AM, Aragorn wrote:
>>>
>>> I have in front of me a device that displays pixels, and a keyboard,
>>> and a mouse. If you want to call that set of hardware a "terminal"
>>> we might come to some agreement.
>>
>> Yes. It needs no further refinement than that description. However,
>> an operating system should offer support for multiple such terminals
>> (as defined in this manner).
>
> I think some further clarification might be needed. I intend to
> compose a second reply to Ivan's original response, where he decided
> to crosspost since he considers this not a linux-specific topic, so
> please do read that when it appears.

Yes, and by that cross-post, Ivan has helped me realize that there are
multiple newsgroups related to this subject beside this one, so I have
subscribed to those groups as well now. :-)

>>> As for the "multi user operating system", the concept is a joke;
>>> there are clients and there are servers, connected by local or
>>> remote protocols, and any numeric relationship between the number of
>>> clients and the number of servers is completely artificial until
>>> after you've implemented the whole. Port-80 on google.com probably
>>> splits into dozens (or hundreds) of servers and they may well be the
>>> clients of several database servers. The fact that some "operating
>>> systems" are only capable of supporting a single client is
>>> symptomatic of their inadequacy and little more, they are nothing
>>> more than a special case of the client-server paradigm which uses
>>> local-only communication.
>>
>> Well, I do not see multi-user functionality as separate from the
>> client/server paradigm.
>
> It is only the ability of the operating system to track the ownership
> of the resources it has allocated (the most obvious example being
> files) that makes an operating system capable of handling multiple
> users.

Plus that a genuine multi-user operating system is also capable of
allowing unprivileged users full productivity without that they require
elevated privileges. Elevated privileges can then be relegated to a
specific and/or specialized user account (as in the case of the root
user on traditional UNIX systems) or via a more fine-grained role-based
access control system (as is available on Solaris and via an add-on RBAC
framework on GNU/Linux as well).

[crankypuss]

On 02/24/2013 04:10 AM, Ivan Shmakov wrote:

>>>>>> crankypuss <noe...@noemail.invalid> writes:
>
> [Cross-posting to news:comp.windows.x, for this discussion is
> hardly specific to its GNU/Linux implementations.]

I'm unfamiliar with the purview of comp.windows.x but I am assuming that
it is for discussion of X Windows, rather than MS-Windows.

After reading your later response, and giving the matter some additional
thought because of the issues you brought up, I think that it may very
well be a linux-specific topic rather than anything really relevant to X
Windows.

I am not suggesting that X be modified, removed, or that anything at all
be done to X. What I am suggesting is something quite different from
that, which seems to apply specifically to linux (although it might or
might not equally apply to Unix).

There is much talk about the linux operating system but there truly is
no such thing; there is a linux kernel, there is a set of core commands
which have been inspired by their Unix counterparts, there is a set of
linux filesystems, and there are many "linux distributions" that include
the aforementioned plus numerous applications, but linux is more of a
toolkit than an "operating system".

And I am not really suggesting here that *any* of that be changed.

What I am suggesting is basically the interposition of a thin-client
layer between the hardware and the X Server, which would support a
character-mode interface to the pixel-capable screen for application
use, and, within that screen, allocate windows which could be used by X.

This thin-client layer could also provide access to the server operating
within the same physical housing, such things as killing runaway
processes or even configuration functions.

And it could do it *without* the need to translate application output
into arcane character sequences defined by "terminal" hardware obsoleted
decades ago and then deciphering it in order to perform simple display
functions.

[crankypuss]

Privilege levels are the domain of the server based on the authorization
granted to recognized clients, nyet?

[Aragorn]

On Sunday 24 February 2013 19:58, crankypuss conveyed the following to

comp.os.linux.x...

> On 02/24/2013 11:40 AM, Aragorn wrote:
>
>> On Sunday 24 February 2013 19:14, crankypuss conveyed the following
>> to comp.os.linux.x...
>>

>>> It is only the ability of the operating system to track the
>>> ownership of the resources it has allocated (the most obvious
>>> example being files) that makes an operating system capable of
>>> handling multiple users.
>>
>> Plus that a genuine multi-user operating system is also capable of
>> allowing unprivileged users full productivity without that they
>> require elevated privileges. Elevated privileges can then be
>> relegated to a specific and/or specialized user account (as in the
>> case of the root user on traditional UNIX systems) or via a more
>> fine-grained role-based access control system (as is available on
>> Solaris and via an add-on RBAC framework on GNU/Linux as well).
>
> Privilege levels are the domain of the server based on the
> authorization granted to recognized clients, nyet?

That depends on how you define "server" in this context. In GNU/Linux
specifically, the security subsystem is part of the kernel itself. In
GNU proper - i.e. GNU with the Mach/HURD microkernel - it is instead
under the control of a userspace daemon.

And in Microsoft Windows, it's an optional layer in the kernel, which
can be bypassed in its entirety by simply using a filesystem which
doesn't support ACLs, such as vfat (FAT32). Instant 777 rights for
everyone! ;-)

[Ivan Shmakov]

>>>>> crankypuss <noe...@noemail.invalid> writes:
>>>>> On 02/24/2013 04:10 AM, Ivan Shmakov wrote:

>> [Cross-posting to news:comp.windows.x, for this discussion is hardly
>> specific to its GNU/Linux implementations.]

> I'm unfamiliar with the purview of comp.windows.x but I am assuming
> that it is for discussion of X Windows,

It's "X window." No trailing "s".

> rather than MS-Windows.

LIST NEWSGROUPS reads:

comp.windows.misc Various issues about windowing systems.
...
comp.windows.x Discussion about the X Window System.

> After reading your later response, and giving the matter some
> additional thought because of the issues you brought up, I think that
> it may very well be a linux-specific topic rather than anything
> really relevant to X Windows.

Reading your message, I don't think the issue is all that
relevant to GNU/Linux, either. Perhaps news:comp.terminals
would be a better fit.

[...]

> What I am suggesting is basically the interposition of a thin-client
> layer between the hardware and the X Server, which would support a
> character-mode interface to the pixel-capable screen for application
> use, and, within that screen, allocate windows which could be used by
> X.

> This thin-client layer could also provide access to the server
> operating within the same physical housing, such things as killing
> runaway processes or even configuration functions.

I do not understand this point. Why not to use separate
utilities for these tasks? (As it's currently done.)

> And it could do it *without* the need to translate application output
> into arcane character sequences defined by "terminal" hardware
> obsoleted decades ago and then deciphering it in order to perform
> simple display functions.

Whenever one has a subsystem and an application which needs to
interface it, there /is/ a choice. The two may communicate via
series of "function calls" (which may require that the subsystem
is really just a library, running in the very same address space
as the application itself.) Or, the two may communicate by
passing around "messages" (which are, for the most part, memory
buffers annotated with length.) Or, there may be a stream,
which is either composed of "octets", or "ASCII codes." (Which
is a kind of "subset" of an octet stream. Then, either stream
may carry serialized "messages", too, but it isn't necessary.)

As it is, AIUI, X uses an octet stream (and "messages" on top of
that), while the text terminal interface uses an "ASCII code"
stream.

The crux of the things, however, is that there /must/ be an
encoding. (And once the goal is set to provide a way to run the
application over a network connection, this encoding should be
"compatible" with octet streams.)

Above, you show your dissatisfaction of having to "translate
application output into arcane character sequences ..." But the
truth is that, one way or another, the machine only understands
numbers (and octet streams are only capable of delivering
octets.) So, irrespective of the goals, the application would
/have/ to describe its intent in numbers.

For instance, there's /no way/ for application to command "set
the cursor at 3, 7": not until there's defined a some
combination of numbers for this command (like: 13 3 7.) So, the
only real issue you're having is that you dislike the particular
set of numbers set for that action (as in: 27 91 51 59 55 72.)
Which doesn't seem all that reasonable.

It's entirely the same for the keyboard (and pointer) input:
there's a particular encoding to choose. To my mind, ASCII is
quite a sensible choice. I understand that the "classic" PC
keyboards offer three (NB!) more "scan-code" encodings to choose
from (I don't know if the USB keyboards allow for either, or
all, of them, or provide yet another one), but would this really
be a sensible choice to use a particular piece of hardware as a
"reference" for such a protocol? Wouldn't we then need to use
an emulation once we move to some different hardware?

Also, you say "... defined by 'terminal' hardware obsoleted
decades ago." Yet again, the truth is, whatever hardware one'd
choose to model the interface after is going to be "obsoleted
decades ago" a few, well, decades from now. Wouldn't that mean
that every single application created for that particular
interface would have to be abandoned, and the whole decades-long
effort to be started from scratch?

[Aragorn]

On Sunday 24 February 2013 20:43, Ivan Shmakov conveyed the following to
comp.os.linux.x...

> crankypuss <noe...@noemail.invalid> writes:
>
>> I'm unfamiliar with the purview of comp.windows.x but I am assuming
>> that it is for discussion of X Windows,
>
> It's "X window." No trailing "s".

I already meant to comment on that myself, but given that when I say
such things, I am often found to be a pedantic asshole, I chose not to
say anything this time. :p

On the other hand, I read a nice quote about this in my fortune database
the other day - I can't remember who exactly said it - which went
something like this...:

"You can call it the X Window System. You can call it X11. You may
even call it just plain X. But call it X-Windows and somebody's
going to flame you over it. And you will have deserved it."

;-)

P.S.: Ivan, the way your newsreader accentuates the attributions makes
it very hard to actually make out who wrote what in relation to
the quoting indentation. I've been meaning to tell you this
earlier on already, but I didn't specifically want to reply to
one of your posts just tell you only about that particular thing.

[crankypuss]

On 02/24/2013 12:43 PM, Ivan Shmakov wrote:
>>>>>> crankypuss <noe...@noemail.invalid> writes:
>>>>>> On 02/24/2013 04:10 AM, Ivan Shmakov wrote:
>
> >> [Cross-posting to news:comp.windows.x, for this discussion is hardly
> >> specific to its GNU/Linux implementations.]
>
> > I'm unfamiliar with the purview of comp.windows.x but I am assuming
> > that it is for discussion of X Windows,
>
> It's "X window." No trailing "s".

Thanks. I know that, I just can't remember it... I have trouble
remembering things that are rote and somewhat nonsensical... after all
what good is one "window" and why even call it a "window" if it is truly
singular. I'll try to remember so as not to offend. Although I think
it's really "X Window System" and not "X Window". Oh well, so it goes.

> > rather than MS-Windows.
>
> LIST NEWSGROUPS reads:
>
> comp.windows.misc Various issues about windowing systems.
> ...
> comp.windows.x Discussion about the X Window System.

Whew! <g> Anyway, I've removed the crosspost to comp.windows.x in order
not to annoy any more folks than... well, "necessary" isn't the right
word, perhaps better to say "than have already been annoyed".

> > After reading your later response, and giving the matter some
> > additional thought because of the issues you brought up, I think that
> > it may very well be a linux-specific topic rather than anything
> > really relevant to X Windows.
>
> Reading your message, I don't think the issue is all that
> relevant to GNU/Linux, either. Perhaps news:comp.terminals
> would be a better fit.

Interesting. Maybe it isn't relevant to anything at all. I really
couldn't say. The question was initially posed somewhere else, wherever
that might have been.

> [...]
>
> > What I am suggesting is basically the interposition of a thin-client
> > layer between the hardware and the X Server, which would support a
> > character-mode interface to the pixel-capable screen for application
> > use, and, within that screen, allocate windows which could be used by
> > X.
>
> > This thin-client layer could also provide access to the server
> > operating within the same physical housing, such things as killing
> > runaway processes or even configuration functions.
>
> I do not understand this point. Why not to use separate
> utilities for these tasks? (As it's currently done.)

Indeed, why not have separate bits glued on here and there wherever
someone thought they might be useful, as seems to have been the case
since days-of-yore. Why not keep the umpty-dozen methods of specifying
command-line options for that matter (as it is currently done), and so
forth and so on.

I'll admit that my thinking on the real issue behind all this shifts
around somewhat... sometimes I think that I want to maintain a "minimal
modification" strategy, and sometimes I think that what I want is to
keep the linux kernel and filesystems and pitch most of the rest down a
dry well somewhere and call the result a "new distro".

> > And it could do it *without* the need to translate application output
> > into arcane character sequences defined by "terminal" hardware
> > obsoleted decades ago and then deciphering it in order to perform
> > simple display functions.
>
> Whenever one has a subsystem and an application which needs to
> interface it, there /is/ a choice. The two may communicate via
> series of "function calls" (which may require that the subsystem
> is really just a library, running in the very same address space
> as the application itself.) Or, the two may communicate by
> passing around "messages" (which are, for the most part, memory
> buffers annotated with length.) Or, there may be a stream,
> which is either composed of "octets", or "ASCII codes." (Which
> is a kind of "subset" of an octet stream. Then, either stream
> may carry serialized "messages", too, but it isn't necessary.)
>
> As it is, AIUI, X uses an octet stream (and "messages" on top of
> that), while the text terminal interface uses an "ASCII code"
> stream.
>
> The crux of the things, however, is that there /must/ be an
> encoding.

That rather depends on how one chooses to look at it, if you want to
find an encoding it's easy to find one... information is after all
encoded as bits-and-bytes.

> (And once the goal is set to provide a way to run the
> application over a network connection, this encoding should be
> "compatible" with octet streams.)

Far be it from me to interfere with your religious beliefs whatever
those might be; however, "should" can be evaluated on the basis of
various priorities, for example: efficiency, simplicity,
maintainability, compatability, and "the way we've always done it".

> Above, you show your dissatisfaction of having to "translate
> application output into arcane character sequences ..." But the
> truth is that, one way or another, the machine only understands
> numbers (and octet streams are only capable of delivering
> octets.) So, irrespective of the goals, the application would
> /have/ to describe its intent in numbers.

Look closely enough and you'll find there's not even any understanding
of numbers, it's just inputs to adders and suchlike buried in the guts
of some chip or another, and those are no more than voltage levels
entirely divorced from any "numeric" meaning other than that which the
circuit's own semantics imply.

> For instance, there's /no way/ for application to command "set
> the cursor at 3, 7": not until there's defined a some
> combination of numbers for this command (like: 13 3 7.) So, the
> only real issue you're having is that you dislike the particular
> set of numbers set for that action (as in: 27 91 51 59 55 72.)
> Which doesn't seem all that reasonable.
>
> It's entirely the same for the keyboard (and pointer) input:
> there's a particular encoding to choose. To my mind, ASCII is
> quite a sensible choice. I understand that the "classic" PC
> keyboards offer three (NB!) more "scan-code" encodings to choose
> from (I don't know if the USB keyboards allow for either, or
> all, of them, or provide yet another one), but would this really
> be a sensible choice to use a particular piece of hardware as a
> "reference" for such a protocol? Wouldn't we then need to use
> an emulation once we move to some different hardware?
>
> Also, you say "... defined by 'terminal' hardware obsoleted
> decades ago." Yet again, the truth is, whatever hardware one'd
> choose to model the interface after is going to be "obsoleted
> decades ago" a few, well, decades from now. Wouldn't that mean
> that every single application created for that particular
> interface would have to be abandoned, and the whole decades-long
> effort to be started from scratch?
>

Let's all just wallow in the current muck then, well, all of you folks
who wish to continue to endure it anyway, and I'll go off and play with
my own toys.

[crankypuss]

On 02/24/2013 04:10 AM, Ivan Shmakov wrote:

>>>>>> crankypuss <noe...@noemail.invalid> writes:
>
> [Cross-posting to news:comp.windows.x, for this discussion is
> hardly specific to its GNU/Linux implementations.]
>
> > Suppose that, instead of requiring that an X Server always be running
> > in order to support fullscreen applications, it was optional. That
> > is to say, what if there was a fullscreen character-mode support
> > layer that would allow pixel-mode windows to be created as part of
> > its ongoing character-mode support?
>
> As in: Wayland?

I think DirectFB sits at the level I want to work with and also supports
X as a back-end. So if my understanding is correct, it might be
possible to use DirectFB for what I wish to do.