World: r3wp

:-)

hmm. tar is unoptimal on linux. tar shows 20% cpu usage on the following:

tar -xzvf debian-hurd.img.tar.gz
debian-hurd-20111214.img
Ok
ls -Hl
size=3146776576 debian-hurd-20111214.img
size=260521812 debian-hurd.img.tar.gz
Ok

it must show 0.0000(0)1 cpu usage on optimal OS and fs and tar implementation

gzip shows 45% cpu while this

Are there desktop gadgets sitting on the screen background and screen 
foreground etc available on Linux, who knows?

Is there such a desktop environment?

The article http://www.scribd.com/doc/55687428/Gadgetsattributes 
the first use of the word gadget regarding the software to AmigaOS.

I want +"screengadgets" +software +linux --- but there's NONE!!! 
:(

SHIT. GTK+ 3.x now supports CSS.
machines get slower and slower with all of that
stupid architects

http://library.gnome.org/misc/release-notes/3.2/

I discard GTK+ into a trashcan with such directions of development.
Qt supports CSS either. Trashcan, too.

I guess that's why people are sticking with GTK+ 2.x.

m.: EFL has a set of pretty light libraries
--- what's EFL?

--- m., this? http://www.enlightenment.org/p.php?p=about/eflThe 
Enlightenment Foundation Libraries (EFL)

this url is an interesting stuff. One can program graphics bypassing 
X

Is that so? EFL was always built on X

The design also has limitations with threading/multi-core and hardware 
rendering

look at the diagram. EFL can either work with X or without X

the diagram below (the more complex one) document ways with no X

hardware rendering --- it has OpenGL, FrameBuffer and some other 
no-X ways... i don't know

re: threading/multicore i don't know

I mean no-X OpenGL and no-X Framebuffer. Maybe that diagram is misleading 
but maybe it is not misleading

It does seem to be less limited than it used to be. Although DirectFB 
figures in the text, but not in the diagrams

I considered it for a Red binding, but GTK has many more advanced 
third-party widget projects

Also, GTK is cross-platform. The EFL diagram vaguely mentions Win32/CE 
but mainly it still seems to be tied to Linux and maybe BSD

On Mac, EFL works only on X11. On Windows, not all components work

Enlightenment DE also doesn't support UTF-8 output garbling the cyrillic 
characters.

on gnewsense Linux

Really? They talk about rendering Hindi, so I suppose it should work

Well. With tweaking configs and stuff maybe. Out of the box, it doesn't 
work.

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