OSNews

You almost get the impression coding = vacation for him

I don't believe so, but since Haiku has come this far does it really matter anymore?

Wasn't the BeOS source purchased by Zeta?

No. By Palm.

No. Palm bought it years ago from Be Inc., then didn't Palm sell it off to Zeta? Or at least sold distribution rights to Zeta. Otherwise how does zeta sell a completed version of "Dano" (BeOS r6 beta)?

No, I believe the BSD port was shelved due to the modifications that would need to be made in order to port it. (FreeBSD was the one being considered)

It will be used as a reference, however, IIRC.

>> Will the hardware work ?

Most of the "standard" hardware should work.

>> Need some alternative to x windows.

Haiku's appserver is far more better than X-Windows and API is _EASY_. X-Windows API is unusable and not worth learning for me.

>> Maybe Axel needs to call the boys at React Os. Then you might be able to use windows drivers. They are everywhere.

Windows drivers are only partial solution, because you get some overhead in translation layer.

"Haiku's appserver is far more better than X-Windows and API is _EASY_. X-Windows API is unusable and not worth learning for me."

Ok, time to run violently off topic.

X doesn't have an API, it has a protocol. The closest most people come to this is the XLib library, the "standard" library for writing X applications. XLib has a very nasty API that's true, but it's not intended that you should have to interact with it very closely. Normally, when writing an X app, you use a toolkit (GTK+ etc.) as was always intended.

Anyway, result is that the "X-Windows API" isn't unusable, you probably use it quite regularly, you just don't have to worry about how exactly you do it. There are attempts to improve low level access to the X protocol (xcb for example,) and while these should help toolkit writers to write good libraries, they won't make things different for those happy to use the toolkits, which is almost everyone else.

AppServer is different to X, as the toolkit APIs are all very entangled with the lower level stuff, so you don't have to think about which you are using. That's a slightly false way of thinking about it though, as under BeOS you don't generally use the interfaces that would compare to XLib, those are nicely wrapped up for you in pretty C++ objects.

Cons:
- Patent and copyright issues
- Distribution issues - user has to download
- Installer bloat - user has to install
- Documentation bloat
-- user has to know the difference
- opaque binary blobs, unmaintainable
- Windows bugs and exploits may apply
- Windows driver framework bloat added
to kernel, gfx server, media server, ...
- hardware makers don't learn to support open source
- inertia, status quo, Microsoft monopoly prolonged

Pros:
- *cheap* commodity hardware
from vendors who don't trust you

- winmodems work (yay!)

I don't think its feasible to make a driver framework that works with "every" alternative OS, given that operating systems can be very different, and be written in all kinds of languages. (yeah, really) It's not all C and Unix-clones. There could, however, be a lot more sharing of information, documentation, reverse-engineered knowledge and whatever, instead of only relying on some Linux driver, which may not always be enough to understand a piece of hardware.

There should be a hardware/device driver library with links to all available code (in every OS out there) and all available documentation. That would help the alternative OS makers. This probably exists in some form already.

Edited 2006-07-23 17:38