Here are a few proposals:
Akaros integrates code from Plan9, now dual licensed.
Maybe use OS/2 as a basis. Browser qupzilla is available for it.
Oh and eComStation claim to be fully compatible with OS/2 (non free).
Not to forget Haiku, for personal use. Qupzilla is also available for it.

PS Just trying to fight insomnia

eComStation is fairly nice for an OS. I had a trial of it a while back for an old machine I was using and it worked really well. It's kinda iffy on newer hardware so unless you want problems you might want to stick to hardware from the start of the Windows XP era.

Another odd-ball OS out there is SkyOS. http://www.skyos.org/ I don't know much about it, but it seems to be either some kind of UNIX-like or another independent designed OS, similar to Haiku/BeOS. Looks promising, but progress on it seems to be about the same pace as ReactOS.

Thanks for the recommendations, but I think like Miguel de Icaza and some BSD developers I will most likely end up with a certified proprietary Unix, which has a fair amount of useful desktop applications from ISVs available. That doesn't mean, that I completely abandon Linux.

eCS with its 286 optimized 16 bit kernel and a 32 bit hybrid userland on top of it is something that just doesn't work on post-2010 64 bit PC hardware. OS/2 really is a thing from the past.

Sorry but that's not exactly right man. EComStation is a true 32-bit OS, not a hybrid 16-bit/32-bit mess like Windows 9x was. The original versions of OS/2 were 16-bit, but IBM made a clean transition to 32-bit unlike Windows did with 9x from 3.x which utilized a 32-bit user land on top of a DOS core and 16-bit kernel with 32-bit memory addressing extensions.

OS/2 never was a true 32 bit OS like NT. eCS kernel and file system drivers are 16 bit for compatibility reasons. Also there is a lot of 16 bit x86 assembler code everywhere, which no one can touch without breaking everything. This design (dating back to the IBM AT) is the main reason, why OS/2 never survived the introduction of x86-64.

1 members found this post helpful.

http://blog.martin-graesslin.com/blo...-trancparency/
I recommend to also read the re4st of the article, I find it very informative.

1 members found this post helpful.

sometimes i think Martin Graesslin is thinking the new plasma only (or what's it called)
i think wayland will need compositor support for network transparency, unless couple of them come together and make a standard (for compositors over network)

also i don't see nothing wrong with vnc

X12 if its ever made will have its own network transparency
wont be X11, but you will have X12 anyway

also what does dbus have to do with it

As he states, he thinks that network transparency belongs into the toolkit. Anyways, since he is the main developer for Kwin (and therefore also the main developer for making it a Wayland compositor) I think he knows what has to be done to be network transparent.

As he states, X11 network transparency does not work for applications that rely on DBus interfaces, since DBus itself is not network transparent.

sry didn't have time to read it thoroughly

thing is there is no definition of a "compostior"
since a window is basically a textured quad to a compositor, it can do whatever it wants with it
it can rotate it, change the perspective, wiggle it, add shadows or whatever and even map it to a 3D object
(and the client can treat it as a texture buffer and draw in it using cpu or gpu)

i was thinking like when sending a window event decide
IF CLIENT idk QT5.69 THEN SEND qt5.69 api for it
ELSE IF unknown THEN SEND damage events or full textures

and since dbus is a socket thing, why not just send it over the network
(i know its not internets capable, but routing msgs)

just a couple of thoughts

According to an fvwm developer, fvwm is unlikely to ever be ported to Wayland:

http://www.fvwmforums.org/phpBB3/vie...php?f=6&t=3010

.. so I hope the xcompositor works well.

Between that and the "oh, yeah, someday, eventually" attitude towards network transparency (which I use frequently to work around practical problems), I expect to need to hang on to Xorg for a while before making the switch.

Window Managers based on xlib don't necessarily have to be obsoleted, they just need to evolve to give the added functionality needed to the standard Wayland interfaces, controls, etc.

Isn't twm the most basic wm for x11 getting a Wayland counterpart?