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 400629
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: Legacy architecture == bad?
by cycoj on Tue 22nd Dec 2009 01:28 UTC in reply to "RE: Legacy architecture == bad?"
Member since:

"I hear that argument quite often, Unix/Linux is based on an architecture which was designed ~40 years ago, therefore system x which was designed from scratch is more modern (which somewhat == better). What people tend to forget is that the people who actually invented and designed the Unix architecture were probably some of the smartest computer engineers of all times. Now if some "random" guys sit down and make a new operating system "from scratch" why would it be necessarily be better?
Secondly Unix is one of the few OS which was actually designed after some laid out principles most other systems seem more like they are implemented after some random ideas. This is not to say that there aren't better designs around (Plan9 anyone?).
Third, you write that there is lots of duplication between the three layers in Unix (base,X,WM) which causes slowness, security issues etc. do you have any evidence to back up?

Yes. I have a good one! my Ubuntu Linux 9.10 and FreeBSD 8.0 that uses X ;)
Window responsiviness with Haiku app_server is amazing! (except by firefox maybe. In time: Megan Fox >>>>>>>> Firefox ;) )

I wish people would stop bashing X. The architecture and design of X is almost never the cause of performance bottlenecks. Sure under Xfree86 the code rotted, but since the split off Xorg has been making great strides. X runs and runs fast on hardware ranging from servers to phones or PDAs, it really isn't the problem.

E.g. in your comparison you're saying yourself that firefox is as slow on Haiku, so I'd say you're looking at performance of the apps not X. Also are you comparing the performance of something like KDE or Gnome with all the wizbang enabled to Haiku?, hardly a fair comparison.

"Again I fail to see how the second follows from the first. If the legacy is very well designed from a security point of view, it will actually be better for a secure system. Also, security is actually very hard to do, people spend their research careers about this. So creating a secure design is actually not easy.

Just to point out, I'm not saying that Haiku lacks in any of these points. I simply take issue with the premises.

Well, for default, Haiku keeps all ports closed. I'm not an expert in security, but seems very safe for me
Well I pointed out that I was not talking about Haiku, but there is a lot more to make a system secure than simply keeping all ports closed by default.

Reply Parent Score: 3

silix Member since:

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 ), 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...

(*): ,, - 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 ( ) 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