Linked by bcavally on Mon 21st Dec 2009 17:18 UTC
BeOS & Derivatives Today there are many operating systems available. Every vendor or community round it tries to make it as good as possible. Having different goals, different legacy and different cultures, they succeed in it more or less. We (end users) end up with big selection of operating systems, but for us the operating systems are usually compromise of the features that we would like to have. So is there an operating system that would fit all the needs of the end user? Is is the BeOS clone Haiku?
Thread beginning with comment 400711
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: Legacy architecture == bad?
by silix on Tue 22nd Dec 2009 20:20 UTC in reply to "RE[2]: Legacy architecture == bad?"
silix
Member since:
2006-03-01

I wish people would stop bashing X.

won't happen.
X is an overly complex piece of code resulting from anachronistic concepts and superseded assumptions,no more holding true for the majority of the 21st century desktops - which aren't dumb text terminals connected to a mainframe updating the screen for timesharing users, any more
users expect rich, visually appealing AND responsive local UI's and the ability to leverage their teraflop-capable GPU to offload graphic computations (which is only logical), and rarely (if ever) use desktop remoting (which can be supported anyway by an add on optional service - instead of basing the local GUI stack's design on network transparency, which is a wrong choice to do in this day and age)
besides, when applications and toolkits actually check whether they are runing locally or over the network, (and use different code paths for either case), network transparency becomes somewhat of a chimera and a GUI stack based on it a suboptimal compromise design;

but there's much more to X apart from network transparency... core fonts and their outmoded non -standard format (kept around since the X server is intended to render text in place and on behalf of applications, that could do so equally well on their own - besides, the presence of application belonging text strings in a central place actually constitutes a security and privacy liability), badly thought drag and drop / clipboard protocols (when initiating a DnD operation, just a pointer to the "data provider" is set - which leaves the operation pending, if the pointed client application is then terminated or crashes in the meantime - moreover, why the GUI server should take are of DnD or clipboards is beyond reason), the authentication protocol (X being a server listening on sockets, in the unfortunate event it crashes, all connections are dropped - and as of now client application hang too), and an inconsistent coordinate system (best explained in http://www.std.org/~msm/common/WhyX.pdf ), holding on multiple communicating processes to separate "mechanism from policy" (isn't the above x server based drag and drop protocol a "policy", btw ?), instead of more modern interface based plugins (not that the system is still very usable if compiz crashes, anyway)

The architecture and design of X is almost never the cause of performance bottlenecks.

of course not, since an architecture requiring Window Manager/Application ->(Kernel) -> X server (and back) round trips, is always more efficient than one where no round trip or complex interaction is required - and a system doing marshaling over sockets isn't three times slower than on being able of lightweight procedure calls or the like (*) - oh wait...

(*): http://www.cs.washington.edu/homes/tom/pubs/lrpc.pdf , http://plan99.net/~mike/dissertation.pdf, http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.51.7045 - for comparison, the NT kernel being originally born as a desktop microkernel, supports a similar mechanism, QuickLPC

Sure under Xfree86 the code rotted, but since the split off Xorg has been making great strides.

other GUI's had solved the window visibility and redraw problem, or supported application side rendering, or multihead, long before the XFixes, RENDER, or Xinerama (respectively) extensions got deployed, 3d based compositing with redirected direct (NOT accelerated indirect) rendering came to linux after Vista was released ( http://hoegsberg.blogspot.com/2007/08/redirected-direct-rendering.h... ) and several years after OS X quartz extreme
progress in catching up with what others already had for years is still progress, i suppose...

Edited 2009-12-22 20:31 UTC

Reply Parent Score: 2