Haiku’s Axel Dorfler has stated that Haiku’s networking stack is more or less complete. “the basic networking infrastructure should be more or less complete now. Also, when booted, and an interface is up, the stack should also respond to ARP requests. However, that it is more or less complete doesn’t necessarily mean it will work fine – when implementing the protocols, we’ll definitely find some rough or even missing edges, I’m sure.” In addition, a week ago, the latest Haiku newsletter was released.
Another step closer for Haiku. Another step closer to tripple booting Mac OS X, eComstation (OS/2) and Haiku on an intelMac for me.
Just a minor clarification, this isn’t actually stating that the network stack is anywhere complete, but rather that just enough of the lowest layers of it are complete such that people can begin work on ipv4/ipv6/udp/tcp protocol modules. There’s still quite a bit remaining to do.
great news. in a perfect world axel dörfler would be cloned. oops, I mean replicated of course.
networking would definately be a big step towards Haiku R1.
Axel Dörfler = lean mean coding machine!
That guy has done wonders for Haiku. I just don’t want to see him burn himself out. I hope he takes regular vacations throughout the year.
You almost get the impression coding = vacation for him
Have there been any attempts to get the BeOS source code released by the Japanese company who came into possession of it, by buying Palmsource, not so long ago?
Browser: Mozilla/4.51 (compatible; Opera 3.62; EPOC; 640×480)
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)?
This was ported from BSD’s stack right? If so, which version?
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.
What ever happened to the Haiku intern?
<insert Clinton joke here>
Be licensed out to several companies. One of which was the Zeta. Then Be sold to Palm. Zeta exists because Palm couldn’t/wouldn’t nullify the license agreements.
Will the hardware work ?
No.
Making an Os is half the battle. Writing drivers for the hardware is the other half.
Need some alternative to x windows.
Maybe Axel needs to call the boys at React Os. Then you might be able to use windows drivers. They are everywhere.
>> 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
In fact, anevilyak is right (as almost always :-)) – only the basic architecture of the networking stack is done. The real work (ie. TCP/IP implementation) is still missing.
As you can easily see, I can’t do wonders either 🙂
And I definitely won’t burn out before Haiku R1 beta 2 or so