World: r3wp

Here is a nice GRUB2 startup image with cosmic ship flying to Saturn 
with grub.cfg on how to display the image during GRUB2 menu display: 
http://people.debian.org/~sthibault/hurd-i386/installer/cdimage/current/debian-cd_info.tar.gz

The image and .cfg are easily extractable from the archive.

It would be fun to grow Linux with no X at all! Thoughts anyone?

Here's an article all about it:  http://www.terminally-incoherent.com/blog/2007/05/21/a-day-without-x/

Also: http://wayland.freedesktop.org/

And Kaj already mentioned DirectFB.

Andreas, I'm interested in direct video hardware programming under 
linux. So the following text from a page you mentioned is most interesting 
to me:

One of the details I left out in the above overview is how clients 
actually render under wayland. By removing the X server from the 
picture we also removed the mechanism by which X clients typically 
render. But there's another mechanism that we're already using with 
DRI2 under X: direct rendering. With direct rendering, the client 
and the server share a video memory buffer. The client links to a 
rendering library such as OpenGL that knows how to program the hardware 
and renders directly into the buffer. The compositor in turn can 
take the buffer and use it as a texture when it composites the desktop. 
After the initial setup, the client only needs to tell the compositor 
which buffer to use and when and where it has rendered new content 
into it.


This leaves an application with two ways to update its window contents:


   1. Render the new content into a new buffer and tell the compositor 
   to use that instead of the old buffer. The application can allocate 
   a new buffer every time it needs to update the window contents or 
   it can keep two (or more) buffers around and cycle between them. 
   The buffer management is entirely under application control.

   2. Render the new content into the buffer that it previously told 
   the compositor to to use. While it's possible to just render directly 
   into the buffer shared with the compositor, this might race with 
   the compositor. What can happen is that repainting the window contents 
   could be interrupted by the compositor repainting the desktop. If 
   the application gets interrupted just after clearing the window but 
   before rendering the contents, the compositor will texture from a 
   blank buffer. The result is that the application window will flicker 
   between a blank window or half-rendered content. The traditional 
   way to avoid this is to render the new content into a back buffer 
   and then copy from there into the compositor surface. The back buffer 
   can be allocated on the fly and just big enough to hold the new content, 
   or the application can keep a buffer around. Again, this is under 
   application control.


In either case, the application must tell the compositor which area 
of the surface holds new contents. When the application renders directly 
the to shared buffer, the compositor needs to be noticed that there 
is new content. But also when exchanging buffers, the compositor 
doesn't assume anything changed, and needs a request from the application 
before it will repaint the desktop. The idea that even if an application 
passes a new buffer to the compositor, only a small part of the buffer 
may be different, like a blinking cursor or a spinner.

I'm also very interested in direct framebuffer rendering on Linux. 
Is DirectFB the most advanced framework for such use?

DocKimbel - read also the wayland link above --- at least the text 
I quoted here.

It mentions DRI2.

(I didn't read about DRI2.)

Here's a DRI2 page (a lot of unknown terms): http://www.x.org/wiki/DRI2

Looking at the DRI2 Wikipedia's page, it seems it still needs X to 
run?

In computing, the Direct Rendering Infrastructure (DRI) is an interface 
and a free software implementation used in the X Window System to 
securely allow user applications to access the video hardware without 
requiring data to be passed through the X server. Its primary application 
is to provide hardware acceleration of the Mesa implementation of 
OpenGL. It has also been adapted to provide OpenGL acceleration on 
a framebuffer console without an X Server running.

 http://en.wikipedia.org/wiki/Direct_Rendering_Infrastructure_(DRI)

X with many DRI apps would be fun!!!

From that wpedia page: "[DRI] is now part of the X.Org Server."

So it seems that DRI and DRI2 are way to go.

DirectFB allows applications to talk directly to video hardware[...]

 "The [DirectFB] library allows developers an alternative to a full 
 X Window System (X11) server[...]" http://en.wikipedia.org/wiki/DirectFB

Unrelated thing: "The Linux framebuffer (fbdev) is a graphic hardware-independent 
abstraction layer to show graphics on a computer monitor, typically 
on the console. The word framebuffer means a part of video memory 
containing a current video frame, and the Linux framebuffer means 
\u201caccess method to the framebuffer under the Linux kernel\u201d, 
without relying on system-specific libraries such as SVGALib or another 
user space software." http://en.wikipedia.org/wiki/Linux_framebuffer

More DRI info: "Wayland display server, hosted by freedesktop.org 
and developed by several X.Org developers, both addresses criticisms 
of X by replacing it completely and works directly with the hardware 
via DRI. It is planned for Wayland to eventually replace X in Ubuntu[10] 
and Fedora,[11] the two most popular Linux distributions.[12] Wayland 
handles backward compatibility with X by optionally running an X.org 
server as a client, which can be rootless (having one Wayland window 
per X client).[13]"  http://en.wikipedia.org/wiki/X_Window_System

And more DRI and DirectFB: "Other competitors attempt to avoid the 
overhead of X by working directly with the hardware. Such projects 
include DirectFB. The Direct Rendering Infrastructure (DRI), which 
aims to provide a reliable kernel-level interface to the framebuffer, 
may make these efforts redundant.[14]" (same article)

So this clears all issues for me.

Faster DEs: "Q: How much faster is fluxbox compared with XFCE? A: 
Fluxbox will certainly load much faster after the login screen, and 
will consume probably 1/2 to 1/3 of the RAM that xfce will, but if 
you have lots of RAM you probably won't notice much speed difference 
after the loading process. However, if you only have 256MB of RAM 
fluxbox is the way to go..." http://forums.linuxmint.com/viewtopic.php?f=142&t=30599
(Untested by me)

gnewsense:

aptitude search dri|grep DRI

p   driconf                         - DRI configuration applet   
               

p   libgl1-mesa-dri-dbg             - Debugging symbols for the Mesa 
DRI modules

p   x11proto-xf86dri-dev            - X11 DRI extension wire protocol

with my nvidia card: :( driconf 
Xlib:  extension "XFree86-DRI" missing on display ":0.0".
Screen "0" is not direct rendering capable.

nouveau.freedesktop.org nvidia drivers wiki doesn't include the word 
DRI :(((

Ah. It includes a DRM word.

Fine :)

DirectFB looks outdated to me. It seems to support only old graphic 
cards.

My latest gnewsense 2.3 doesn't include DRI.

So it seems I need to build my own CLFS cross-lfs.org ... Though 
I didn't search for Linux distros supporting DRI.\

DRI links: http://dri.freedesktop.org/wiki/Links--- includes OSes, 
Linux distros, cards supporting DRI

AltME. I installed RHEL-based 64-bit Linux. And yum shows no 32-bit 
emulation libs. Anyone knows is it possible to set up RHEL64 for 
32-bit altme? The disto is ScientificLinux http://scientificlinux.org

As far as I know, DRI requires 3D support. DirectFB supports 2D hardware 
and drivers. It can be combined with OpenGL

It's quite possible that the OpenGL combination requires DRI

It seems 3D is optional at DRI.

Not sure.

REBOL Folks. How to fix a font in REBOL editor---it's unreadable!!! 
http://s017.radikal.ru/i401/1202/f0/b05d8abc5412.png

???

lsb_release -a;uname -a
No LSB modules are available.
Distributor ID:	gNewSense
Description:	gNewSense GNU/Linux 2.3 (deltah)
Release:	2.3
Codename:	deltah

Linux greenmeadow 2.6.24-30-generic #1 SMP Thu Jan 12 02:39:14 UTC 
2012 i686 GNU/Linux
Ok

sudo apt-get install xfonts-100dpi xfonts-75dpi
[sudo] password for gouslar: 
Reading package lists... Done
Building dependency tree       
Reading state information... Done
xfonts-100dpi is already the newest version.
xfonts-75dpi is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Ok

It's completely impossible to work with such a renderer of an editor.

I'll try to install R3---maybe it's more OK.

I recommend using an external editor. R2's internal editor is not 
very good.

R3 does not have an internal editor.

I'd be happy to attach an external editor to [Edit] Button in R2 
or R3.

I usually do it the other way around. Find a favorite editor and 
attach R2 or R3 to it.

That all is imperfect. OK.