> You can improve safety, which is always a good thing to do, but improvements will be asymptotic to a value below perfectly safe.

To be exact, this is true for *everything* in life. There simply is no such thing as "perfectly safe".

I do agree with your posting though.

Great. Name calling, with zero actual substance. I am reminded now why I don't frequent Slashdot much anymore. I suppose you can't be bothered to bring actual arguments against what I wrote in my earlier, post, right? No, spitting out curses is much easier of course. It should be completely obvious that I am *not* speaking for Raster, but instead am stating that he *would* agree with what I said since his design decisions for Evas are pretty much what I described. But hey, I don't expect an actual discussion anymore. Continue with your infantile name calling.

If you mean enlightenment evas, note that the lead developer would agree with me. Evas has been one of the earlierst adopters of client-side drawing. It is so efficient that it can even outperform GL-accelerated 2D drawing in certain cases. Evas has (or had) support for the Xrender extension as well, but quickly dropped that, because letting the application handle all of the drawing and small-bitmap blitting (by that I mean stuff like icons) is so much more efficient. If anything, Evas is a perfect example of why the "blitting bitmaps" paradigm is the better one.

And none of them use the X way of remote desktop either. Yet, they are efficient, and in heavy use. You make it sound as if remote desktop is unfeasible without the X remote functionality, which simply isn't true. Stick VNC/RDP to Wayland, and you are done.

Again, I wrote:

Also, you completely disregard the MUCH bigger number of administrators and helpdesk personnel working with VNC, RDP, Citrix etc.

You said it yourself: the X remote functionality is okay for *old* stuff (RHEL5 is from when, 2007?), which still draws content by asking X draw this line, that text etc. It is much more efficient to let the application draw these things by itself these days, which is why every newer toolkit and application uses this client-side drawing model. And this is *exactly* where X is broken: it is fundamentally ill-suited for this new paradigm, which only needs a much simpler system. One like Wayland, which only provides surfaces applications can draw into. That's it. Anything else is an anachronism.

Qt4 just pushes bitmaps (even Qt3 did, partially). So does Gtk 3. So do Chromium and Firefox, and IIRC also Thunderbird. Yes, that fits the term "most", unless you are running some old distro.

Which is what 99,99% percent of all modern OpenGL applications will do.

You are talking about indirect 3D rendering, which is a fundamentally different topic. It is true that you can in theory send OpenGL command streams over a network, but in practice, this works only for certain applications, where the size of the commands is not too large, and no large assets (textures, meshes) etc. are transmitted. There's a reason why everybody wants *direct* rendering for 3D on the local machine. Forget about running games with indirect rendering, for example.

But when it comes to 2D applications, it quickly becomes obvious that the X protocol is useless nowadays, since most application draw paths, fonts etc. on their own, and X only gets to handle window-sized pixmaps. X drawing commands are almost never used anymore, except by some ancient stuff, like xterm. In that case, that fancy "X11 transparency" will end up transmitting raw bitmaps over the wire. Just use RDP, VNC etc. instead.

One reason is that back then, many DOS versions of games only had AdLib or even just PC speaker support, while the Amiga version came with fully digitized audio.
Compare https://www.youtube.com/watch?... to https://www.youtube.com/watch?... , https://www.youtube.com/watch?... . (The sound is actually in stereo, but the Youtube videos are downmixed for some reason.) The difference can be jarring thanks to the inferior music.

As a matter of fact, the Amiga was famous for its sound (and graphics) capabilities back then, *especially* compared to DOS. (Well, until 256-color VGA became common..)

Some DOS games had digitized audio as well, but Amiga could mix 4 channels in hardware. Mixing had to be done in software in DOS, unless you had something like a GUS or an AWE32 sound card.

But you forgot to use an XML schema for validation, and XSL transformations to be able to automatically write a game out of the XML files!

But even if it consumes less RAM, browsers do a lot of I/O, because they cache all these images etc. so if your disk cache is almost nil, you will notice.

It consumes almost all of the physical memory. free -m also shows that the RAM is full, even when taking cache into account. Also, it uses about 1GB of swap.

It is definitely not a CPU limitation. CPU is almost never a bottleneck these days. The hard disk is the no.1 bottleneck by far.
Also, CPU limitations don't cause massive amounts of hard disk activity and swapping. Note that I did check if swap was in use. It was. A lot.

I actually cannot open more than 4-5 tabs on my old Thinkpad with 2 GB RAM because it will be filled quickly. This is just Chromium and icewm running, on a bare minimum Archlinux installation. More than 4-5 tabs, and disk activity skyrockets, because the disk cache is pretty much zero at this point. And this affects the system twice - first, any other I/O activity will be slower because of almost zero disk cache, and second, Chromium itself suffers, because it too does a lot of I/O operations (more reads than writes).

20+ tabs on that machine is doable, sure, if you are willing to tolerate a slideshow..

This is quickly becoming untrue. The no.1 memory hog these days is the browser. People keep 20+ tabs open, many of them filled with tons of fancy graphics and complex structures. The virtual memory WILL become active. And then everything is incredibly slow.

Also, even if you measure that your browser, OS etc. consume say 3 out of 4 GB, do not forget about disk cache. It is *crucial*. Plenty of free RAM means that a lot of files can be cached in memory, which helps immensely.

And, since RAM has become rather cheap these days, I'd try to max out my mainboard RAM capacity for one simple reason: DDR generations come and go. Today you might think "oh that is lots of RAM". Tomorrow you will be glad you got that much back then, because that DDR generation is obsolete now, and remaining chips are expensive. To get an example, just try to find DDR2 RAM to upgrade an old PC...