Daniel Switkin, a long time BeOS developer and former Be Inc. employee, has submitted an editorial on “Writing A BeOS Replacement“. It aims to bring together the various efforts out there and define a plan which has the greatest chance of success. Click Read More to see the entire article from Daniel.
A few words before we begin:
1. This is not a half-hour brainstorm. I read FAQs, I researched, I thought about it, I wrote it, I put it away, and I rewrote it. Please show me the same courtesy before clicking the Post Comment button.
2. Yes, I am a former Be employee.
3. No, that does not make me right or my opinion more important.
INTRODUCTION
I became a BeOS developer around 1997. I used to boot DR8.2 off a Zip disk in the public labs at school, because I didn’t have a BeBox or PowerMac. By the time R3 came out and I could install it on my PC, I was hooked. I wrote Anime, GIFTranslator, and ImageViewer, among others. When I graduated, I applied to Be and got a job. I worked as a DTS Engineer for about nine months. Then I moved to Tascam, where they were making a pro audio device running BeOS on an embedded PC. I worked on that for two and half years until it shipped recently.
All that is to say, I lament the death of BeOS as much as anyone. I’ve used it every day for four years as my primary, if not my only OS, and I don’t see another platform I’d like to move to. I’m also saddened at the demise of Be Inc., as some of my friends lost their jobs, and I’d guess most of us lost money in Be stock. So I understand the desire to recreate the operating system. I really get it, and I’m tempted to help.
GOALS
Just as a good engineer resists the temptation to bang out code right away, and thinks about design first, I’d like to step back and think about the goals of such a project before getting into the implementation.
Some or all of these would seem to be desirable:
– a large user base (comparable to BeOS at its peak, or larger)
– a strong developer community
– a wide array of applications (perhaps commercial in the long run)
– strong hardware compatibility
– press attention/coverage
– hardware vendor support
I want to make clear that these are my assumptions for the rest of the article. I have no interest in and no right to tell people what to do with their time. If you’re only interested in a hobby OS, for example, please ignore what follows. If you specifically want the challenge of writing an OS from the ground up, I wish you good luck. I’m also not trying to support or recommend one BeOS replacement over another, as I’m not affiliated with any of them.
MAKING IT HAPPEN
So with these goals in mind, here are my opinions (nothing more, nothing less) on how to achieve them:
1. Depending on how you count, there are at least four different efforts to make some kind of open-sourced BeOS replacement. As many people have pointed out, this needlessly divides talent and manpower among parallel, if not competing, projects. But it also does something much worse: it’s the format wars all over. Beta vs. VHS. Minidisc vs. DAT vs. DCC. Not to mention the disaster that is the writable DVD war. In every one of these cases, customer adoption was greatly slowed down, and enormous time, effort, and money was wasted. In our case, users and developers will take a wait-and-see approach until a winner emerges. We need a single platform with a single binary format that everyone can get behind. Let’s learn a lesson from history, and build one BeOS replacement together.
2. Let’s talk about hardware support, as this was one of BeOS’s greatest failings. Without full featured drivers for a large variety of current and future hardware, this effort is doomed to the same fate. I believe it is unrealistic, to say the least, that the relatively small number of people working on BeOS replacements could hope to create the needed quantity of drivers. Not only because of the manpower required, but also due to the lack of funds it would take to purchase documentation under NDA from some of the leading companies. Additionally, even if you could manage binary compatibility with existing Be Inc. drivers, that only gets you support for hardware which is already outdated today, much less when the first BeOS replacement ships.
I think the most viable solution is to base a BeOS clone on another open source kernel, probably Linux. Consider:
– Even if you could raise the money needed to buy NVidia documentation, and NVidia was willing to sell it to you, you still couldn’t write a driver of the same quality and completeness in your spare time as their own engineers who do this for a living. In addition, you’d need to undertake this huge effort from scratch, and maintain it, whereas their Linux drivers are available today and will be maintained for free.
– On day one, without typing a keystroke, you have a booting kernel, filesystems, a network stack, a huge complement of drivers, a shell, a compiler (more on this later), and tons of command line apps. And all of that is written, maintained, and tested by other people for you. The size of your task is enormously smaller, which means the likelihood of finishing is much greater. And you could always reimplement any of these components you weren’t happy with in later versions.
– Unless you as a developer want the challenge of writing a kernel from scratch, it’s important to realize that users don’t pick a platform based on the kernel. Look at how many people ran MacOS 9 and earlier. Cooperative multitasking in the 21st century – are you kidding me? I don’t want to debate whether the BeOS kernel was better than Linux, or whether NewOS is better than both. The point is, Linux has gotten good enough to use as a base, and lots of knowledgeable people continue to improve it. The hardware support it brings (especially from hardware vendors themselves) more than outweighs any disadvantages.
3. In the past I was on the fence as to binary compatibility with R5, but I’m now firmly against it. The original argument was that many popular BeOS applications were closed source, and would therefore be lost without binary compatibility. That’s a very good point, made by Erik Jakowatz and others. But in recent months, many abandoned-yet-popular apps have been donated to the community. Among these are Gobe Productive, Postmaster, ArtPaint, and Pe, and this trend seems to be growing. Not to mention that the most important application a desktop platform needs, a web browser, is already open source in the form of Mozilla. (NetPositive trails too far behind current web standards to be usable much longer, and the code would be too hard to rejuvinate even if it was available).
Now consider the disadvantages of binary compatibility:
– The BeOS APIs are showing their age. There are design flaws, naming inconsistencies, outdated implementations, etc. For example, pointers are commonly used where references would be better. You SetEnabled() but you MakeFocus(). BFont does not derive from BArchivable. BWindow and BApplication both have pulse functionality, so why isn’t it in their common base class, BLooper? And what exactly does BView::SetDiskMode() do? (Hint: it’s not in the Be Book) The freedom to make these changes while retaining 99% source compatibility is well worth it, not to mention not having to deal with maintaining virtual function ordering, padding to maintain object size, etc. There are also BeOS classes which do not have enough reserved space for fragile base class protection – this is a good chance to fix them.
– Binary compatibility ties you to gcc 2.9.x, since the 3.x series tool chain broke compatibility for C++. So first of all, you’re stuck with a compiler that will not evolve or get bug fixes. It will not generate optimizations for the Pentium 4 or future CPUs. But worse than that, it’s buggy. As I recall, turning on -march=pentiumpro will generate wrong floating point code in some cases. Using -O3 often produces slower code than -O2. And the STL implementation is horrible. Bitset is broken. Using += on a string trashes memory. Calling operator== to compare a string to “” returns the wrong result. OpenBeOS proposes to use STLport instead, but I don’t see how this can be done and maintain binary compatibility. The inline nature of STL means that all the header code of the R5 STL has been compiled into existing applications, yet still depends on libstdc++.r4.so. So you can’t change the contents of this library, and you can’t remove the old STL code from the apps out there. Would you simply ship this library in binary form only, then have a new name for the STLport lib? If someone knows a way to make this work, I’d be interested.
– How will you achieve binary compatibility with Be Inc. apps that use unpublished APIs? Perhaps you can reverse engineer the magic flag which Workspaces passes to the app_server in its constructor (the entire contents are drawn by the server into an empty view). But what about kernel support for bdb? What about DriveSetup? What about the dozens of private header files that were in the BeOS source tree which could be used anywhere? As a data point, consider that the OpenBeOS team tried to reverse engineer the protocol between the app_server and input_server, and gave up. All of the extra effort it takes to remain binary compatible will be wasted when the important apps fail to run.
– Conversely, many of the Be Inc. apps that would run aren’t worth it. Take some of the preferences apps for example: Fonts, Menu, Mouse, etc. First, they’re all out of date. Second, they either save their settings in obscure ways that would be inconvenient to use, or they interact in private ways with the system and aren’t usable (how does the Network panel restart the net_server?). Very few of them would be hard to rewrite. Plus apps like BeMail, CodyCam, Pulse, and Magnify are already open source, and of course Tracker and Deskbar. The only significant app that came with R5 that I would miss is BeIDE, which I admit I like alot.
I believe that in order to attract quality developers and to get them to build large, full-featured applications, you must provide modern development tools and a well-documented, clean API. Being permanently stuck in 1999 does not get you there.
4. I think source management and licensing are important. I think any project would greatly benefit from using Perforce, which is free for open source projects. (I don’t know anyone who switched from cvs and wants to go back). But whichever source management tool you choose, the source needs to be available to the public. Not necessarily with write permissions, mind you, but at least in read-only form. I won’t pretend to have the experience managing large projects to tell you how this should be done. But I feel that letting anyone check code in on one extreme is just as bad as not showing the code to anyone outside your group on the other extreme. The most successful projects out there (Apache, the Linux kernel, etc.) seem to have a model where contributions are encouraged, but checkins are closely scrutinized for quality.
Licensing seems to have divided the largest two projects, OpenBeOS and BlueEyedOS. I’m happy to see that both reject the GPL as an option, due to its viral qualities and the fact that it discourages commercial development and contributions. OpenBeOS has in a noble gesture gone with MIT, also known as the “truly free” license. I admire this, and have no problem with it personally, but as Michael Phipps points out, it provides no protection for the authors in the form of requiring changes to be submitted. BlueEyedOS has adopted an as-yet-unnamed license due to concerns about code forking and commercialism. Again, I understand and can sympathize, but I think the fact that the code isn’t available to the public feels closed to many people. What I haven’t heard is a strong objection to the LGPL license from either side, or for that matter the Mozilla license. Both reject the viral aspect of GPL, and while LGPL requires all changes to be submitted, Mozilla only requires changes to existing files to be released, thus allowing proprietary extensions. Perhaps the two sides could consider one of these as a middle ground, where the source is available but also well managed.
As for code forking, I don’t know if it is absolutely preventable if you wish to be open source. However, many successful projects out there don’t suffer this problem. Perhaps the best defense against it is to keep the project active and open to input, so that it neither stagnates nor causes excess disagreement (obviously you can’t please everyone all the time). It’s also possible that a project of a certain size and complexity becomes pointless to fork, since it’s just too hard to take it in another direction without a large team. Given the dwindling number of BeOS enthusiasts out there, this may not come up.
5. I understand that the number of people who have joined these projects and the work they’ve done already is cause for optimism. But I prefer to be more realistic about how hard this task is. Take the app_server, for example. I worked at Be, and I’ve seen the code, but I am not remotely qualified to rewrite it. I would guess that maybe ten Be employees are. Yes, it’s that hard. My advice, and I don’t like to say it, is to consider not supporting certain features of both the app_server and BeOS in general, at least in the first version. For example, BWindowScreen and BDirectWindow probably don’t make sense. Maybe drop 15 and 16 bit graphics mode support (code size can be seen as colorspaces ^ 2, since a bitmap in one colorspace must be able to draw into a bitmap of any other colorspace). I agree, it’s a compromise, but v1.0 will always be just over the horizon if it must contain everything. As interest in BeOS and the community both shrink, time to release becomes more and more important (many people think it is already too late).
CONCLUSION
Writing a BeOS replacement is a huge task. But it’s only worth doing if you plan a strategy that gets you to your goals. If you make the same mistakes as Be Inc. then you’ve just wasted several years of effort. There needs to be one united project that developers and users can get behind. Hardware support is critical to making the platform succeed, and that means leveraging all the work that has gone into Linux. Binary compatibility sounds tempting but ultimately has too many downsides. The source code needs to be available but well maintained. And lastly, some pieces may need to get left out in order to succeed.
In closing, let me put my money where my mouth is. If we as a community can work these issues out, I will donate the source of GIFTranslator and ImageViewer to the new OS. I will also recompile Anime and my other apps for the new platform, and encourage other developers to do the same. For those unwilling to open source their work or recompile, we could set up a service to rebuild their apps and make binary-only releases, guaranteeing the privacy of their source code.
I’m eager to hear your thoughts. If you don’t want to comment below, you can write privately at [email protected].
A fine article Daniel. I agree that uisng an extant core (such as Linux) would be an easier solution than reinventing everything. Michael Phipps and his team are walking down a really difficult path. I respect them taking the hard road though. It reminds me of an old saying, “A little adversity is good for a man. Kites rise against, not with, the wind.” I wish them luck.
Dave Owen was right on target with the positives of BeOS. It was easy to install, incredibly responsive, booted fast and, if it had a driver for a particular card, it just worked. The file system was pretty much bulletproof too. Heck I even liked the UI. All in all, it was the most transparent OS I’ve used because I didn’t have to manage it constantly.
If using a linux kernel compromises the low latency, responsiveness, small footprint, and excellent multi-media performance of it then i’d say dream what others think is impossible:
Stick with OBOS and rewrite the kernel and/or keep bugging palmsource.
Daniel never mentions it by name, but Cosmoe seems to follow his recommendations quite closely. As some here have noted, one of the problems with Linux on the desktop is X. For years now, the primary lure of X has been the body of applications built for it rather than the merits of X itself. Sound familiar?
Since a BeOS clone with source compatibility will start life with a pretty decent body of apps, it’s free to cast off the heavy yoke of X for a new architecture.
It’s easy to applaud the innovation and performance of a new kernel that is in use by only by only a handful of people. Once the number of people grows into the tens or hundreds of thousands, the immaturity of those efforts will become clearer. Except that the number will never grow to those levels, becuase the hardware support won’t be there.<p>
Not to say that projects like NewOS lack merit—I think they’re absolutely essential, and I hope one day to see the new open-source BeOS ported to them when they’re ready. But to get started—to get traction—an approach such as Daniel suggests and Cosmoe implements, is better.
If you use linux kernal as base, you always can substitute yet missing
app with Linux one, running under one of countless toolkits.
(someone here already wrote about “gaps” and how linux kernel help to fill it)
And i really don’t see any reason for developers to write apps specifically for LinBe API. Inspite how nice it will be.
Until it goes messy and primitive and “mono-threaded”.
So what is the sense to create LinBe? Just to let OpenTracker work on Linux?
I guess most people here would build their house on quicksand if it was faster or more convenient – just remember your house will sink after a little while.
Presumably OBOS will have a better base to expand upon because it is designed, not /grown/ like large parts of linux are (NOTE depending on who you ask linux is either a very solid design or not designed at all). If the design is decent then flaws will be much easier to locate and rectify.
Just another opinion in the never-ending thread!
A lot of folks here are confusing Linux the kernel with GNU/Linux the OS.
From a user and mostly the developer standpoint, a well-made BeOS clone based on the Linux kernel will be almost indistinguishable from BeOS R5. Using Linux as a kernel will not draw all the 1337 h4x3uRz to OBOS, it will not give us the X11 toolkit cruft, it will not turn OBOS into YAWM, it will not force you to compile kernels all the time. It will, however, take a huge pile of work off the Kernel and Network teams and let us focus on what made BeOS BeOS.
Excuse my lack of insight, this is an enduser speaking…
What does it take to change kernels?
I guess that the app_server, networking, media kit and, loosely as an add-on, the filesystem have ties to the kernel. Maybe other aspects as well.
Suppose, the OBOS development is progressing favourably. All, except the kernel which as a result of complexity or lack of knowledge/experience just won’t reach maturity in time. Is it possible to have another look at the Linux (or BSD etc.) kernel instead or would that mean to scrap all the above mentioned modules as they tie in too deeply?
Maybe the B.E.OS guys would even be so gracious to donate their at that time thoroughly tuned Linux kernel.
I’d really love to see all the OSBOS projects work together on the kits where possible and then, putting them under their respective license, tune them according to their project’s demands. If changing kernels turns out to be not an impossibly huge task, everyone can have a look and pick and choose between the offerings.
Last comment:
I keep reading about “big egos” standing in the way. IMO this is bull*. The leaders of every project have been thinking about the situation, about the goal of their project and how it is achived best. They picked their way after carefully considering the alternatives and worked many many hours toward that.
Who would demand to throw all that away and follow another way they have rationally dismissed a long time ago?
So the answer is not to merge all projects, but to work together where possible, alter common code where needed and code only what is absolutely necessary project-specific from scratch.
Hopefully beunited.org will help with that. I’d really love to sponsor a weekend conference where all the different project leaders can meet and compare notes… but alas, I don’t have the money… :
save yourself the trouble and move over to linuxland right away, cause it won’t happend.
I’m saying this cause when I see the blind hope you have, I can only see you getting hurt in the end. Reminds me of the hope you have of getting back together with a girl after she brakes up with you.
Blind hope? The more doomsayers tell me it can’t/won’t be done, the more determined I am to do my part to help. While I’m not an active member of any of the 4 projects to clone the OS, I’m still developing software, and doing my part to bring a future to the OS. Mabey this is what the trolls want, mabey they just want to get us fired up and ‘prove them wrong’ because they really want to see a new BeOS. And mabey I’m just over-analyzing things again… drat this over active imagination.
I’d be happy if a girl broke up with me. That would imply that I had been involved in some sort of relationship to begin with. And that, my friend, would be a welcome change of pace for this geek.
http://www.unstrung.com/document.asp?doc_id=21627
“Palm Has Visions of Sugarplums”
It mentions that Palm’s CEO said they may need minority investors for the spinoff of palm os. It also cites a wall st. journal rumor that sony is one of the interested parties. Sounds familiar to the register.co.uk rumor of way back that sony would take over Be.
It is also interesting also because of Sony’s vision for the next playstation and proliferation of cell (toshiba, ibm, sony chip) based devices.
now putting these tid bits together to claim that beos could be back is way out there but YC may be right. We might see beos from palmsource yet.
Using Linux as a kernel will not draw all the 1337 h4x3uRz to OBOS, it will not give us the X11 toolkit cruft, it will not turn OBOS into YAWM, it will not force you to compile kernels all the time. It will, however, take a huge pile of work off the Kernel and Network teams and let us focus on what made BeOS BeOS.
Why do you use the future tense? B.E. OS is already doing exactly that, they utilize the Linux kernel in theri effort towards a BeOS clone (or so they think). So get your lazy ass over to B.E. OS and contribute to that project. Just leave OpenBeOS to do its thing.
And if you were right (which you certainly believe you are), then B.E. OS will succeed and OpenBeOS will fail, and it will be the icing on your cake of satisfaction.
So get your lazy ass over to B.E. OS and contribute to that project.
I am an application developer, not an OS developer. Give me an alpha copy of B.E.OS so I can write software for it
I posted earl;ier about an evolving process and sicne so many mistake Linux The Kernel for GNU/Linux and are jsut prejudice d against it and X, I have questions abotu a direct approach.
HURD and Fresco (Berlin) are here now, modern, and lack what peiople hate about linux and X. They are just not far enough along for use now, but so are NewOS and your appserver. They are even further behind then HURD and Fresco.
Why use NewOS The Kernel over HURD The Kernel. ive been following OBOS very closely (checking the news page every day) and reading the IRC discussions. You talk about it beong the closest in design to the BeOS kernel. I feel HURD The Kernel takes the BeOS philosophy a bit further with translators. They are a perfect lower level counter part to the kits. The work being done on the port from Mach to L4 would help improve the speed.
Like I noted earlier, for Fresco, you can write to it in any language thanks to Corba. You would be able to accelerate it with a video card like Quartz Extreme. I think someone mentioned X drivers being used within GGI so that would mean you could write a compatible driver API with X for Fresco to get the acceleration and card support. For when those developing Fresco for an X replacement and not a BeOS clone get enough momentum, they can improve the APIs since I bet tehre could be a lot of improvement in the model.
Any comments on why not HURD or Fresco
Note: HURD does not mean having to include the load of GNU. I actually feel that if possible to not even support the Unix like file structure. Instead the APIs come in 3 varieties:
-C Based Unix Port (Virtual File system that provides Unix structure)
-C Base Native API (Native C apps, No Virtual File System)
-C++ Based Native API (For Native apps)
Sony is also the fastest growing PC maker now according to C/Net (please note, I said fastest growing, not the top dog – Dell). Sony makes the coolest Palm handhelds. Hmmm.
Just read the article. (Thanks
Sony makes sense as minority investor.
If you think about it, (The state current OS market, the MSFT case, PalmSoure’s current product line, PalmSourse’s profitability in the future, the BeOS engineers at Palm, the fact that Palm does not want to sell or license the unfinished DANO to anyone, the viability of a finished BeOS desktop and BeIA on TabletPC like devices in the future etc…) it just make sense to expect BeOS to return.
ciao
yc
lichtgestalt: So the answer is not to merge all projects, but to work together where possible, alter common code where needed and code only what is absolutely necessary project-specific from scratch.
mario: So get your lazy ass over to B.E. OS and contribute to that project. Just leave OpenBeOS to do its thing.
And if you were right (which you certainly believe you are), then B.E. OS will succeed and OpenBeOS will fail, and it will be the icing on your cake of satisfaction.
One of the points of this discussion is that if the projects don’t unite, there’s a good chance that none of them *individually* will be able to get into a usable state in a reasonable amount of time.
Can B.E.OS (or whatever it’s to be called) reach critical mass with the current number of devs working on the project? If not, where will new devs come from?
Here’s an analogy: When you call Ben & Jerry’s to complain that your Cherry Garcia didn’t taste right, they make the wise assumption that it probably didn’t taste right for a whole bunch of people but that you were the only one motivated enough to actually pick up the phone.
Daniel took the time to pick up the phone.
for the simple reason that the people who think Linux kernel stinks are not working on B.E. OS, as opposed to those who think that Linux kenrel is the cat’s ass and so they devote their time to B.E. OS.
And if the fact that OpenBeOS utilizes a kernel they like more, NewOS, attracts more committed and enthusiastic developer and other key people to that project, then OpenBeOS wins, no matter what any smart guy has to say about Linux kernel’s readiness or the fact that projects are not united. My experience is that fewer passionate people can achieve more and better results than a larger but unmotivated group. And right now, OpenBeOS is larger and more vibrant than B.E. OS. Could it be the Linux kernel pukeworthiness?
“I am an application developer, not an OS developer. Give me an alpha copy of B.E.OS so I can write software for it”
B.E.OS __ IS __ source compatible with BeOS.
IF you want REALLY to help us, write (under BeOS) test code and don’t ask about which class you could test,
2 tests for a class from 2 different is sometimes not enough. We need :
– basic tests
– bounds tests
– stress tests
Your test must be able to diagnostic if it fails
(and explains why).
Regards,
Guillaume
A very very refreshing article. Kudos to Daniel.
First of all, while we can still see new apps popping at bebits and newbies actively posting installation problems, BeOS is definitely *not* dead.
IMO OBOS should drop binary compatibility and move on to gcc 3.x . BeOS was meant to be a modern OS, so having unable to harness today’s (and future) processing power simply denies the point. My suggestion of a workaround is having BeOS 5 PE on the new OpenBeOS, as some “classic environment” feature (ala MacOS X). And of course, fix the flaws/bugs in BeOS along the way.
And definitely not linux. As said by many, BeOS is about the Be in the OS. And the GPL virus issue too.
I dont think that neither OBOS nor B.E.OS would finally regain most of the BeOS user-base. Having two products that acts the same way, ppl would be tempted to choose based not on what kernel theyre running. They would look on speed, stability and hardware compatibility. I see OBOS will gain on stability, while B.E.OS on hware compatibility.
Come on guys, we need an OS here … (an OS. Not a myriad of BeOS-like distro ala Linux). BeOS users were always seen as united and friendly. We are a family. Having two competing BeOS will just divide the community. We are sick off standard wars, that’s why we stick to BeOS .
i am garapheane.
stew: “I had the luck of meeting you in person once, if you remember a rainy day in Santa Cruz (Hey, can I get copies of the pictures you took?
”
Hey there! Send me a private mail…
stew: “It (Linux) will save us a lot of trouble and deliver not only things we aren’t even remotely working on right now (NTFS, USB, IEE1394, RAID, PPC support, ALSA, fork()) but is in fully tested production quality, constant updates and has support from hardware vendors.”
Exactly.
stew: “One last question I have seen on why all the Ex-Be engineers are so quiet: It’s because you take everything they say too seriously. Really. Stop treating them like gods, start treating them like normal people.”
Amen.
C: “Sorry? Viral? What’s wrong with protecting your own code? If I want my code to be free (or closed or whatver), thant I have every right to protect my work.”
Nothing is wrong with protecting your own code. In fact, I like the LGPL license a lot. What I meant by viral, and this is an intentional design point, is the fact that anything which links against GPL’ed code must be GPL’ed itself. For example, we at TEAC wanted to use cdrecord as a library in our project. But that would have required GPL’ing our entire source, which is unreasonable. As a result, we had to use something else, and the community lost out on our contributions (which we would have gladly made under LGPL).
mk: “This is the reality, Be broke binary compatibility when Intel moved from PE to ELF executable format.”
Oops, you’re right. I forgot about changing from Metrowerks to gcc on Intel. My mistake.
Chris Herborth: “The biggest challenge here would be to re-use the X drivers without requiring X, and allowing things that X has big problems with (direct framebuffer access and OpenGL). I have no idea if this is even possible.”
I haven’t researched it either, but I agree that would be the goal.
Ores: “The prime example is to not use gpl yet suggest using linux.”
I was suggesting drawing a line between things linked into the kernel which you must GPL, and having a different license for the rest of your code. I’d also like to repeat that Linux is not the only possibility here – a BSD flavor could also work. The main thing is to leverage an existing code base to bring hardware support and greatly shrink the size of your task.
axeld: “I would like very much to join with BlueEyedOS to reduce the efforts both of us are trying to achieve.”
I agree that a minimum both teams should share all the upper-level code. But it’s still a shame to fragment the few remaining users between multiple efforts. Look how tedious it is now to provide net_server and BONE binaries of the same app. It would be ideal (although unrealistic) to have one platform for all users and developers to support.
axeld: “We will switch to 2.95.3, so we will have a much better and bug-free compiler than BeOS ever had.”
That’s still not a path forward though (does it even get you Pentium 3 optimizations?). At some point you’ll have to break binary compatibility and switch to gcc 3, so why not do it now?
Great article, Daniel. Michael Phipps makes a good response. I wonder though whether he is underestimating the complexity of real world hardware compatibility. Certainly there are indeed a limited number of graphics chipsets and many devices are now USB. You might be able to get a system running with minimal hardware, but that’s just the start. There’s a whole world of exotic and esoteric devices any one of which would be a show stopper for a user wanting to switch who needs that device. An O/S doesn’t live in isolation, it needs to talk to the world. And doubly so for a ‘media’ O/S.
Firewire. USB 2. Serial ATA. UltraSCSI. FibreChannel. Tape drives (Travan, DDS, 8mm, DLT). Soundcards. Audio I/O boards (MIDI, analog & digital, SPIDF, Dolby digital). Mp3 players. Mice. Graphics tablets. Printers (HP & postscript). Scanners (flatbeds, slides, business card). 3d graphics chips. Video I/O boards (composite, S-video, RGB, firewire, serial digital). PDA cradles (Palm, WinCE, EPOC). NICs (10/100/1000), ATM, 802.11[a|b|g]. Bluetooth. IrDA. CD burners, DVD players, DVD burners (+/-/R/W).
Many of these devices come in consumer, prosumer and professionsal versions. Often several competing manufacturers have different chipsets. Many manufacturers provide application software for their devices as well as windows drivers. And more are being developed all the time.
Leveraging an existing base of device drivers is crucial. Its the only hope for coming close to covering a significant subset of the devices that people need. Perhaps that means Linux kernel, perhaps BSD kernel or perhaps some sort of driver compatibility layer. Whichever approach is taken, the goal should be to free up more developer hours to work on building the best user experience, instead of sinking time into supporting hardware.
Though I do agree with most of the points you raise, such as dropping binary compatability and analyzing what works and what needs to be fixed in the BeOS API, I cannot agree to using the Linux kernel for the new system.
First, the Linux kernel is still monolithic, no matter which way you slice it. It was ‘obsolete’ from an operating system technology standpoint the day it was created. Altho a good number of people and uncounted man hours have been spent trying to overcome some of the inherent problems with a monolithic design, the Linux kernel still has a long way to go to reach the morderness of a true microkernel like Mach, QNX Nutrino, or others.
Second, your drives argument, though it makes sense, neglects one main factor. To use the majority of those drivers which users want (ie sound, video), the project would also have to use some of the worst parts of Linux, like the X server. X is another dated technology whos time has come to discarde. It is one of the technologies that BeOS was trying to do away with in order to modernize personal computing. I think using components such as this would be a huge step backwards.
> At some point you’ll have to break binary compatibility and switch to gcc 3, so why not do it now?
EXACTLY. Gcc 3 should be used NOW. Not “when and if…”.
>j-lo “the project would also have to use some of the worst parts of Linux, like the X server. X is another dated technology whos time has come to discarde
Your post has already been answered on the B.E. OS FAQ sheet. Third question from the bottom, here’s a snip “…it means that BlueEyedOS will not use the XServer anymore!”
Just thought you should know.
Why do everyone put demands on OpenBeOS. They have put out a very clear and detailed roadmap for the next few months that thay will follow, no matter what you think. Still you demand this and that should be changed (even you Euginia ). If you want to influence the project join it. Be there when decisions are made, back your claims up with proof and maybe they choose your route.
Put up or shut up.
(Wonder if Linus heard the same thing back then?)
Bill Davenport: “Reasons why I dislike Linux:”
I agree with every one of these. I think many if not all could be addressed though, and frankly I wouldn’t want to use the result if they couldn’t.
stew: “I also trust Daniel’s opinion on that topic (Linux for multimedia), he should know what a system need for multimedia applications – remember, he works at Tascam.”
I have to confess that I have no done any research as to how suitable the current state of Linux is for these applications. All of our audio happens in hardware, not on the host CPU.
obi: “See also “overdesigning”, and “worse is better”, and “biting off more than you can chew”. This also has an effect on mindshare: if your project continues to progress, but at glacial speeds, you will have alot of trouble attracting developers.”
This is exactly how I would describe writing an entire OS from scratch. It’s too big a task to have a good chance of succeeding, and will take far too long.
Oliver Crow: (listed about a million pieces of hardware)
Right, there’s just so much stuff out there. I’ve spent four years compromising about what hardware I can use to run BeOS, and I’m tired of it (and I think a lot of people are). One friend of mine switched to a Mac because “everything just works”. Linux doesn’t have quite that level of support, and it would take work to make it automatic and user-friendly, but it’s miles better than where a new project from scratch would get you.
Hi all,
Why you don’t consider of the evolution aspect?
Show me one kernel, which went through more updates than linux for last 5 years ?
The updates for 2.6 are pretty significant (For performance and standards).
What can be improoved:
The BeOS is not fully posix compliant (it’s big weakness). Standard LinuxThreads packge is good enough (not perfect). NPTL will be much better. The Kernel kit for B.E.OS or any other replacement of BeOS, should be wrapped from POSIX.
When you wanna do it by reverse, it’ll be necessary somehow fix the posix compatibility. And this is much more painfull then wrap BeOS system calls from POSIX.
Drivers:
all drivers should be distributed as modules, I don’t see any problem why we can’t realease Stable kernel for B.E.OS every half year with full set of modules. It should be good enough for standard users. Non standard users may compile linux kernel kernel and whole system as they want from sources.
(Geeks will be always geeks
) )
The Be Framework must be updated, at least I’m missing parts for distributed computing. One of the best way how to solve it, it’s write NSPROXY class with all dependencies from GNUStep in C++ (More transparent solution than CORBA).
Binary compatibility. It’s totaly useless !!!!!!!!
Why you wanna keep this, all system are evolving.
What you will do when you will need switch to 64bit architecture ?? (It will be here very soon.)
Martin
First, the Linux kernel is still monolithic, no matter which way you slice it. It was ‘obsolete’ from an operating system technology standpoint the day it was created. Altho a good number of people and uncounted man hours have been spent trying to overcome some of the inherent problems with a monolithic design, the Linux kernel still has a long way to go to reach the morderness of a true microkernel like Mach, QNX Nutrino, or others.
That has got to be the most entertaining comment I’ve seen in a long time! How do did you come up with that???!! All I can do is: LOL! You and YC should team up and do some sort of stage act. It will be hillarious!
Thanks for the laughs…
-fooks
All this talk and discussion on monolithic has drove me nuts. So I’ve done some digging. Here are the results.
These quotes are taken from an article from http://www.openna.com about the differences between monolithic and modular kernels.
This article starts buy stating ” to explain a little bit what a Monolithic kernel is and why we recommend you install your Linux Kernel as a Monolithic kernel, instead of the common Modularized Linux Kernel that comes with many Linux distributions.
“Modularized Kernels allow small pieces of compiled code, which reside under the /lib/modules/2.4.x-x/kernel directory to be inserted into or removed from the running kernel and a Monolithic Kernel contains the drivers/features into its compiled code.”
So Modular is “dynamic” code and monolithic is static code.
Read for yourself:
http://www.openna.com/community/articles/general/monolithic-kernel-…
You are comparing apples to oranges here. First of all, QNX’s kernel is designed for the embedded space, something Linux (and BeOS) weren’t. QNX doesn’t make a great desktop OS for exactly this reason (tho I like QNX). As for Mach, it is unsutiable as a kernel by itself. It really deals with just very low level stuff. That’s why it needs more on top (ala Darwin).
Linux does not require an X Server for it’s GUI. BEOS doesn’t use one, neither does Cosmoe.
Still, as I’ve said many times before, BSD would be a better kernel anyway (especially from a commercial point of view).
FYI, Martin Handl is a B.E.OS member working on the kernel_kernel and is testing it with Gcc3.2 and NPTL.
Results look promising.
Because a BeOS-like is a huge task,on B.E.OS, we choosed to choose what people called the “easy way”, in order to not be stuck in front of a kernel crash. To make OpenTracker work, we (OpenBeOS, B.E.OS, …) need a rock stable low layer (kernel, drivers, app_server…), it takes time.
We are far from an ISO you could boot but I’m convinced that it will appear. Seeing the activity in this ‘thread’, we could think about binary release of our working binaries.
Regards,
Guillaume
That has got to be the most entertaining comment I’ve seen in a long time! How do did you come up with that???!! All I can do is: LOL! You and YC should team up and do some sort of stage act. It will be hillarious!
Thanks for the laughs
And that was really fscking constructive
Here’s an interesting idea: Why not let the obos team work the way they want.
I constantly notice pressure for them to switch over to linux and drop newOs, but havent noticed the same for BlueEyedOs to drop the linux kernel and switch to say… bsd, i almost feel that linux zealots want obos to either fail or switch to their camp.
and PS: the beos kernel is a microkernel.
The Linux kernel is a big mess right now. On the 2.5
task list is a reorganization of the drivers tree;
it’s been in the planning stages for over 6 months. Basically, the Linux folks have finally seen the light and realize that modularity is a good thing.
IMHO, Linux 2.5 is the first real efforts at revision of their vision. But, I’ll believe it when I see it. And if Linux pulls it off, it still won’t be as simple and modular as Be’s kernel. That’s why I believe in the OBOS approach of using NewOS as a base.
But, IMHO, the real problem with Linux is that
the developers have a complete disconnect between
kernel space and user space. Linux kernel folks seem to think that user-land issues are not their problem.
For example, Audio on Linux is OSS or Alsa at the kernel level, and Arts, ESD, etc. at the user-level. Then their are millions of half finished media players which need to have plugins to support several kernel level and user level drivers. None of the systems works well.
What happens when B.E.OS gets a working BeOS API tacked onto Linux. It’s highly likely that the
kernel will need to be patched. I highly doubt that
Linus Torvalds will roll their patches into the main tree. So, basically, the B.E. OS kernel will be a fork. Forks need to be maintained. The Linux kernel is not easy to maintain. Do you see where I’m going?
Anyhow, the BeOS system was not like GNU/Linux. The key to BeOS is that it was a coherent system where the kernel was kept light and clean and provided the necessary interfaces to a single API (OK, Posix API too.) Running the BeOS API on Linux just opens a pandora’s box of options and kernel problems. Sure, Linux latency might sometimes be better than BeOS. Sure, Linux has a fancy new threading model. The question at the end of the day is “Can the whole works provide a good user experience a la BeOS?”. I think that RedHat 8.0 Beta, Cosmoe, and B.E.O.S. prove how difficult it is.
Think about it this way. Linux may have better latency, but how does it apply to XMMS for example. The Linux scheduler is written with server tasks in mind. Also, the whole priority scheme is a mess. To get real-time priorities, which are needed for low-latency akin to BeOS, one must use esoteric Posix
calls. It’s really a kludge. BeOS has a simple 0-120 priority scale that works great!
And what about Posix compliance? While BeOS
had Posix compliance, its design prevented complete compliance (at least easily, as not all was done). That is a good thing. A lot of Posix standards are based on 20+ year old technology. The BeOS’ IPC and messaging schemes are much more advanced than Posix’s IPC and Signals mechanisms. Although I am not a kernel programer (I wish that I could contribute better to OBOS), at least with OBOS,
kernel development doesn’t seem like esoteric rocket science. It’s better to have a clean slate and tack on the extra needed stuff like signals and Curses for cross platform compatibility. (This is the beauty of having a highly modular, almost micro,
kernel.)
Just my two cents. Keep the faith OBOS developers!
We would prefer to write or listen to somebody. But since nobody can claim what they wrote then nobody wrote it. I can’t see the wind but I can see the effects of the wind.
Take owenership of your words or they will be lost in the wind.
Why Linux kernel ??
1 year ago we had good discussion in ML, I suggest to try BSD kernel. There are no bariers, at the end to use a BSD kernel.
It has only two low level condition, and i’m pushhing is as much i can. “all system calls must be a POSIX compatible”.
Our kernel server server has not full POSIX compatibility,
because there is no real POSIX implementation of MSG QUEUES for LINUX, I really hope that this problem will solved with NPTL with good performance.
Problem 2: App server must be written on something standard.
Honestly there is only one standard now.(X-Window).
For linux we can also use FB, but from some sorces
it’s still slow.
With X & Posix basic B.E.OS can run everywhere.
Later when we will have another capatibility for 2d rendering , we can use FB or something else , something what will be good enough, it will cost just rewrite parts of the APP server. (propably not, when we’ll be able smartly put some standard 2d rendering library(Poscript,PDF) depend on X drivers (it’s big chalenge))
But it’s future.
For now we deside that linux kernel is good (enough drivers & support). And I guess it will be good enogh for long time.
Nobody pushing OBOS Team to change their kernel.
You can try, but i guees the will ingnore you.
It’s their choice from beginnig.
But All rendering stuff & App server(partly) can be shared.
As i now we are using same code writenn by Frans Van Nispen.
And for whole comunity: it should be very good to merge all energy to write Be Framework & App server first. (This can be usable for all BeOS clones) and then continue on separare ways with kernel. And time will show who had true.
Martin
POSIX can be 20+ years old but it’s STANDRAD a lot of peoples using it.
More people than me can say, that not full compliance of POSIX was big fault of Be.
I wrapped a Be kernel API to POSIX , and it was PAIN, becasue documentation is not good enough. And in many ways is not keepeng POSIX (different behavior). Be kernel API is not world class API. And it’s not just my thought.
There is one good thing on Be API (TEAMS).
There will be no patches to 2.6 kernel.
Kernel Server is separate thin layer, which is used just for translating BeOS system calls to POSIX. That’s all. No big maitenance.
Martin
and PS: the beos kernel is a microkernel.
It might have been a microkernel once, but it sucked so bad (like most microkernels) they had to resort to moving the whole networking stack inside the kernel, just to get decent TCP/IP performance! And yes, BeOS networking really sucked in the pre-BONE days. To summarize: a kernel which includes a complete networking stack is not a microkernel by my definition!
-fooks
I’m really wondering what is happening with existing original BeOS source code.
As insiders permanently throw out sentences like “It will never happen because it happens never” about opensourcing of any part if BeOS code, i’m going in little paranoia about it.
There are 2.5 possible reasons (in addition of existence third-party licensed code)
1) YC’s expectations have some ground about PalmBe.
(personally i don’t believe in it)
2) Code is polluted with copyright violations. GPL or sem other stealed code. Sad suspect, but i tend to believe in it more and more
3)2.5. Fearless leaders just wish that world forget about BeOS. Like it wasn’t at all. In bussiness world (in difference from engineering world) it is bad bad bad track record for JLG, Sacoman and others VIP’s. So they dream about real final BeOS funerals.
Daniel wrote: “That’s still not a path forward though (does it even get you Pentium 3 optimizations?). At some point you’ll have to break binary compatibility and switch to gcc 3, so why not do it now?”
Because we won’t drop binary compatibility. When we switch to gcc 3, we will still have the possibility to run the old applications – we’ll keep the gcc 2.95 libraries around (if you wish to do it).
I would keep b/c if it were just to not to have to install another OS – I want to update to OpenBeOS 😉
It might have been a microkernel once, but it sucked so bad (like most microkernels) they had to resort to moving the whole networking stack inside the kernel, just to get decent TCP/IP performance! And yes, BeOS networking really sucked in the pre-BONE days. To summarize: a kernel which includes a complete networking stack is not a microkernel by my definition!
That’s really [!censored!], by your definition linux isn’t a monolithic kernel either because the graphic sever (X) is outside the kernel!
By the way, BeOs was able to handle several videos streams in realtime (and this actually created a “niche” for BeOS in the market), can Linux????? does the linux kernel have multimedia streaming capabilities???? And what about the multithreading diferences between the two kernels???
MP: I think that hardware support is far less of an issue going forward than it was for Be. Compare the state of hardware now to 5 years ago. Parallel and serial are dying, USB is now. USB has standard APIs for printers, scanners, keyboards, mice, joysticks, etc.
I have to disagree. Consider the Epson line of printers, for example. In recent memory, they have had at least two formulations of four color inks, two of six color dye-based inks, one six color pigment-based set, and one seven color pigment-based set. For each of these six sets of ink, they have a unique color table for each of the Epson papers (full gloss, pearl, matte, plain, etc.). They may even have different color mappings based on dpi or droplet size. That’s one reason why Epson printers have such great output. There is no generic USB driver that could possibly account for all this, not to mention borderless printing, roll printing with automatic cutters, and so on.
MP: How many video chipsets are there? You can count them on one hand (by family, not permutation).
Ok, let’s say you don’t count anyone outside NVidia, ATI, and Matrox. Sure, that narrows it down. But consider what a full-featured driver requires today. Back in the day, you only had to worry about 2D support. On BeOS, that meant four colorspaces (8, 15, 16, 32 bit), accelerated rectangles and screen-to-screen blitting, and maybe overlays if you’re lucky. Let me estimate that for one knowledgable person, working full time, with documentation, this is a three month task for production-quality code. That’s if the docs are complete and correct, and you have a variety of hardware to test with. (Leo, Trey, or RJS: feel free to correct me here)
Now think about what a modern graphics card can do. It needs a full OpenGL driver (forgetting Direct3D of course) with support for everything from vertex shaders to hardware transform and lighting. It probably has DVD-playback assist in one form or another. Most support dual head, S-Video output, etc. I’m not a video card driver writer, so I can’t speak authoritatively on this point, but my gut tells me the task is now far, far greater than it used to be.
MP: We would need to make many changes to Linux to make it Be-like. Many, many. I have spent enough time in that code to know that it isn’t a place that I would volunteer to be.
I’ll defer to your expertise, as I haven’t investigated this. Clearly it’s hard, but not impossible.
MP: Interestingly enough, no one has ever said that they don’t think that we will do as well as Linux. Just that we are wasting time. This is a slower route. But I think a rewarding route overall.
I don’t doubt the talent and energy of the people on the various teams out there. However, I think that doing it from scratch is so much slower that the end result is just too far away. And it sacrifices any chance of getting support from hardware companies themselves, which is a huge loss. And it puts you in a situation where every command line app you might want has to be ported, rather than recompiled, which means maintaining your changes in the future. It’s the difference between being a niche OS (which is fine if that’s the goal) and piggybacking on the success and acceptance of a mainstream product.
MP: If we are binary compatible to the BeBook’s specs, we should support nearly everything out there.
Maybe, but I’m not convinced. Try running “objdump –syms” on some Be Inc. apps (or even Postmaster), and grep for “_k”. That’s the standard prefix for undocumented kernel calls, which would be a can of worms to support. Plus the Be Book has many omissions, and doesn’t document the edge cases.
MP: Yes, it has “stuck” us with GCC 2.95.3. That hasn’t been a major point of pain, either, since most of us are developing on BeOS.
Sure, it works for getting things up and running now. But how can you hand your developers a compiler in 2003 which dates back to 1999? As Eugenia and others have mentioned, why not just jump now if you’ll have to eventually?
MP: Licensing is a tough call. Let me say this – I have had more hate mail and more “praise mail” over this one thing than
any other. It is the worst thing in the world – no matter what you choose, you are wrong
I can only imagine, and I don’t envy you having to choose and defend your position. As I said in a previous post, I personally would work under almost any license. My major concern was trying to find a middle ground with the BlueEyedOS folks.
Again I should repeat that these are only my opinions, and that I’m not choosing sides among the various efforts. If the philosophical differences are too great, then separate projects it is. But I think having multiple incompatible BeOS clones considerably weakens the appeal of the final product. I don’t think users want to worry about which flavor or distribution to choose (as in the Linux and BSD cases), whether or not a binary or package is available in their format, etc.
Thank you Daniel for your comments. It takes a lot of thinking and continuous reviewing to navigate a difficult course. This is not a once and done discussion as I see it.
Defining the attractive characteristics of BeOS is important. We don’t want to create a stranger.
Using any kernel is fine with me as long as it supports or improves the essential characteristics of the BeOS expenience. My general feeling is that the Linux kernel is a bit off the mark but I am not speaking with much factual support. I find that one of the things I mention frequently is the fast boot time so it is important to me I guess.
Binary compatibility could be important. Losing those hundreds of apps even if smallish ones is a loss. Many will not be replaced or it will take a long time. I think the plan to keep BC is sound but it may not be realistic. I really can’t make a call there.
It seems like this will probably boil down to 2 efforts and that may be ok. One would surely be better but that is unlikely based on human nature.
What I would wonder about would be getting Palm to help out along the road. Maybe just the app server could be begged away from them as long as we are doing our own kernel work. There may be possibilities down the road.
Thanks again for the throughtful comments and I hope you can continue your involvement going forward.
What I loved about BeOS was:
a) It seemed to combine the MacOS with Unix. It had a decent user interface and a terminal for running shell scripts and GNU tools.
b) The responive feel of the UI
c) The file system and queries
d) The kits for developers to create great software, they weren’t perfect, but that comes with time.
e) Fast boot times
What I didn’t like about BeOS:
a) Hardware support
b) Hardware accelerated 3D
c) Lack of applications
d) Complete POSIX compliance
The main competitor for a new BeOS that I see is MacOS X. It has:
a) Hardware support, not hard when you control the platform
b) Accelerated OpenGL
c) Applications, not as many as Windows, but enough for the end user
d) POSIX compliance
e) It looks good
f) Coacoa is supposed to really nice to develop for
What it lacks:
a) Responsive user interface
b) Correct me if I’m wrong, but it doesn’t have the journaling file system or queries
Rebuilding BeOS with Linux kernel advantages:
a) Hardware support
b) Development community
c) Name recognition
d) Less time to market
e) More stablilty
Disadvantages of Linux kernel:
a) Possibility of being thought of as just another distribution
b) Maintaining a fork of the main tree
Advantages of not using Linux kernel:
a) More BeOS like kernel
b) Not affiliated with misconceptions about the Linux kernel or the just plain hatred some people have for linux
c) Possible binary compatibility
Disadvantages of not using Linux kernel:
a) Longer time to market
b) Less mature product
c) Little hardware support
This is by no means a complete list but it gets the general point across.
Considering all of the above points, here is my opinion:
1) Use the linux kernel with the new O(1) scheduler and pre-emptive patches as the base.
2) Install the hooks needed for BFS and restructure the file system layout to more human readable i.e.: /Applications, /System, /Users, etc.
3) Rebuild all the BeOS servers to run on top of the linux kernel.
Basically build a new operating system. MacOS X uses Mach and FreeBSD for it’s kernel, but it is a lot different then the different BSD distributions. That because it is it’s own OS. I think that you could do the same with BeOS and Linux.
Just my two cents.
Hey folks, what’s this constant whinig about whether BeOS is dead or not? Does it matter at all? What if it’s dead, and it has to be resurrected? What if it’s just sleeping, and it has to be woken up? What if it’s fully alive, just it’s stuck at its current state, and needs help to go on? Does it matter how you call the situation, and does it influence how you or me will behave from now on, regarding BeOS?
Looks like this article may break the OS news comments record. Proof that BeOS still rules!
ciao
yc
Since it’s now clear that everyone’s not going to go for the common good and accept compermise maybe we could at least agree on a common api based on the BeOS api and the BeBook. This wouldn’t do anything for binaries but at least developers could write code to cross compile.
Maybe it could be sorta a media version of POSIX…a standard interface that multiple OSes could aim for.
Is this really asking too much?
Douglas Lockamy
what i see here is that some people want a be-like os… wiht a 3d accelrated pdf based “quartz like” thingie … all on a linux kernel..
well then.. why doesnt someon take initiative and start a project …
instead of wasting ur time arguing.. do soemthing about it .. time to take initiative i say!
Because there already is, as far as I understand it, such a project? B.E.OS.
I think this would be wrong approach.
What drivers are important to start with :
PCI bus, IDE, keyboard, mice, framebuffer – they are already in NewOS (framebuffer may be not complete yet) kernel.
Those huge and complex video drivers that Daniel is talking about are not in the linux kernel. They are in the X server and the best of them are distributed as binary only.
Audio drivers? They were not part of kernel as of 2.2 and only some of them made to 2.4.
Network drivers – that’s very important but ethernet chipsets are not as complex as video ones.
PCMCIA – it’s the whole separate package, it was modified from Linux version in original BeOS and so it can be ported the same way to OBOS.
What’s left ? SCSI (standard – no need Linux to port), USB, Firewire, printer? Some obscure hardware ?
The ultimate goal is to have hardware manufacturers to write drivers for your system. For this you need a good development platform and nice readable API. devfs that BeOS and NewOS have is much easier to work with than ever changing Linux kernel.
> Looks like this article may break the OS news comments record.
Very unlikely.
The records are:
1. 300 comments
2. 281 comments
3. 266 comments
> I think this would be wrong approach.
> What drivers are important to start with :
> PCI bus, IDE, keyboard, mice, framebuffer
This must be part of the kernel , how else you wanna type ??
Except frame buffer these are in kernel form version 1.0
> – they are already in NewOS (framebuffer may be not complete yet) kernel.
Exactly as in Linux.
> Those huge and complex video drivers that Daniel is talking about are not in the linux kernel.
> They are in the X server and the best of them are distributed as binary only.
But they are in now.
Linux Advantage
> Audio drivers? They were not part of kernel as of 2.2 and only some of them made to 2.4.
> everything is in ALSA and it’s part of kernel 2.5 (not stable yet , but it’ll come).
Linux Advantage
> PCMCIA – it’s the whole separate package, it was modified from Linux
> version in original BeOS and so it can be ported the same way to OBOS.
Linux Advantage
> What’s left ? SCSI (standard – no need Linux to port), USB, Firewire, printer? Some obscure hardware ?
I guess it’s also important.
>The ultimate goal is to have hardware manufacturers to write drivers for your system.
>For this you need a good development platform and nice readable API.
>devfs that BeOS and NewOS have is much easier to work with than ever changing Linux kernel.
———————————————————————- ————————-
Please don’t get me wrong.
But real question is.
What we need first ??.
It’s stable Be Framework (2d Window GUI). All of us need it !!!
Then lets talk about low level features. It can be implemented by many ways.
On many kernels.
But for App developer we must provide one perfect thing :
“Hi level Object oriented framework 100% compatible wih BeOS”.
Later extended for new stuff.
This framework can be developed on BeOS PE,Linux,BSD or whatever.
None of BeOS clones has this job done.
And from my perpective this is bigest fault.
Because with 2d GUI we could easily got a lot of developers.
And things will go much easier.
A really don’t wanna change anybody’s mind about Mach, OBOS, Linux kernel,
because as I wrote. At the end APP server + 2GUI should be easily
ported to any platform.
My IDEA was write APP server over Display PDF or DisplayPoscript library.
And this lib is only ONE (i’m saying again only ONE) thing which must be ported to
other platform. Then we can easily share APP server & Frans Controls.
My goal: 2D must be much much faster than any available Desktop.
That is for 2D.
For 3D nobody want use anything else than OpenGL.
Or Anybody aimed for DirectX ???? Really big Challenge :o)
OpenGL code is Standard and how it’ll be implemented is on particular clone.
The same with AUDIO.
B.O.OS choosed reuse this stuff from Linux.
OBOS must implement all of them.
But Everybody has a choice.
And no one should ignore shared goals.
I hope that this is ground point now.
And competent persons (project managers) start do some actions
(At least intensive communications). What we can have done together.
Martin
>>Very unlikely.
>>The records are:
>>1. 300 comments
>>2. 281 comments
>>3. 266 comments
Hmmm, well, what about the top 5 or the top 10?
ciao
yc
Consider the Epson line of printers, for example. In recent memory, they have had at least two formulations of four color inks, two of six color dye-based inks, one six color pigment-based set, and one seven color pigment-based set.
Most new color ink-jet printers can connect to a digital camera and print pictures from it. This is possible because the pictures are transfered in sRGB color and translated to the wahtever inks the printer uses internaly.
As for the video drivers – the DRI interface is not tied to the X Windows system. The current implementation is tied to X, but accordingly to DRI FAQ it is posible with some effort to separate the two. The DRI can be used directly by the inbterface kit (ala Windows Longhorn and OSX Jaguar) and this will also give you accelerated 3D. Then it will be a no-brainer to port DRI Linux drivers to OBOS. The only exception are the NVidia drivers which do not use DRI. It might be possible to port the NVidia kernel module and object files from linux – this was recently done with BSD.
That’s really [!censored!], by your definition linux isn’t a monolithic kernel either because the graphic sever (X) is outside the kernel!
You’re contradicting yourself! Read the above sentence again, and you’ll see that it makes no sense at all. By my definition a microkernel should do only very basic things like memory management and message passing. That’s where the “micro” comes from. Networking and graphics are already not considered basic. They are considered essential though, but they do not belong in a microkernel. Putting them there defeats the whole perceived advantage of having a microkernel! It also demonstrates the inherent weakness of microkernel design, namely that message passing becomes awkward and slow very fast.
BeOS was moving towards the monolithic + dynamic extensions (sort of like Linux + modules). BONE, the new networking stack was put inside the kernel. This allowed BeOS to reach network speeds that were considered normal on Linux and BSD. Read that last sentence again. Yes, the sacred microkernel design proved to be horrible in the real world! The “Big Mess” that Andrew Tanenbaum used to describe Linux has proved to be the most pragmatic one in real life. AST believes (believed? I should ask him
that monolithic designs have very poor structure and are thus pretty much unmanagable. Linux has proven him wrong! And indeed, the biggest cluster at the VU (where AST lectures) is running: Linux! 🙂
-fooks
By the way, BeOs was able to handle several videos streams in realtime (and this actually created a “niche” for BeOS in the market), can Linux?????
Linux handles multiple simultaneous video streams just fine!
I could start about 30 of those silly BeOS demo movies before my old Athlon box started slowing down (UP system)
Linux also does multiple simultaneous mp3 files just fine! (That other famous benchmark). It even does them in reverse with AlsaPlayer. It is also not crippleware and comes with full source code.
does the linux kernel have multimedia streaming capabilities????
What do you mean by this? I don’t think there is such a thing as “multimedia streaming capabalities” inside the BeOS kernel.
And what about the multithreading diferences between the two kernels???
I ported multithreaded applications from BeOS to Linux with little modifications. And in all cases performance even increased on Linux, because the underlying infrastructure (networking, VM/Cache) are much better in Linux. That was 3 years ago. I think the latest Linux absolutely smokes BeOS when it comes to multithreading. Read the NPTL thread? If I remember BeOS could only manage about 4.096 threads systemwide (much less per Team!). Ah yes, now I remember, it was dependant on the amount of RAM you had. We all know BeOS choked at anything above 1GB RAM! In contrast, Linux can do more than 100.000 threads today! There is really no comparison to be made since the BeOS kernel is dead, while the Linux kernel is evolving rapidly.
-fooks
Oh yes, I know “Linux 2.5 will have…, Linux 2.6 will certainly be able to…, NPTL will be much better…, this patch, that patch will make Linux really fly…”. Sure, sure. Very convincing. Yeah. So, we are to expect that Linux will be, maybeh, a good enough kernel, developed in a haphazard, berzerk way where every moron can stick their shit into it (even Linus Torvalds calls his Linux kernel developer colleagues morons, so I am just quoting Linus), a kernel that has huge problems with large I/O and storage -today-, a kernel that is developed without CVS!? (yep, that’s why you can’t simply use your browser to navigate the source tree.. cuz there ain’t any source tree that can be navigated. Download the whole tarball, unpack it and puke)
In addtion, reading the last 2 posts by two B.E. OS developers makes me wonder in how good of a state B.E. OS really is. Comments like “Nobody pushing OBOS Team to change their kernel.” are utterly silly to say the least.
I would not, furthermore, feel that a B.E. OS developer should brag about having “PCI bus, IDE, keyboard, mice, (and no) framebuffer” support, coz’ that’s really expected from Linux.
Anyway, the driver argument seems to be losing it’s edge, and the Linux kernel has still to catch up with NewOS on other fronts. Sure, sure, there are all thoselow latency, high octane, super-duper patches that will certainly make it into Linux by 2005. Or 2006. Either way, I think the B.E. OS people should just leave the OpenBeOS people alone because I don’t see them being very helpful. In fact, nobody mentioned that OpenBeOS sourcecode is freely available, so the B.E. OS people can, if they want to, use it freely (collaboration?), but the B.E. OS source is not avaiable at all (no collaboration?). I think this is at least a little bit noteworthy.
I really wanted to respect B.E. OS, I realy wanted to say “let’s al get along” and I thought that this would be possible, but the stubborn insistence of the B.E. OS members in this thread is starting to change my miind, and I find myself wishing that they simply fail, as a matter of principle. Of course, an opensource project can never really fail.
> By my definition a microkernel should do only very basic
> things like memory management and message passing.
> That’s where the “micro” comes from. Networking and
> graphics are already not considered basic. They are
> considered essential though, but they do not belong in
> a microkernel. Putting them there defeats the whole
> perceived advantage of having a microkernel!
Agreed.
> BeOS was moving towards the monolithic + dynamic extensions
> (sort of like Linux + modules). BONE, the new networking
> stack was put inside the kernel.
No.
BONE, and BTW OpenBeOS new network stack follow same design,
is made of one driver (/dev/net/api) and many kernelland modules
(add-ons/kernel/network/*), on-demand loaded by the driver
or the other kernelland modules.
The BeOS “static” kernel don’t even know what’s a network stack,
a socket, a protocol… nothing.
With the exception of file descriptors select() support, which
is mostly use on socket-kind file descriptors…
> This allowed BeOS to reach network speeds that were
> considered normal on Linux and BSD.
No, it’s a far better design, using less inter-processes messaging, less userland <-> kernelland switches and a great iovec-like net data packets handling which increased performance.
Don’t confuse putting into KERNELLAND (address space)
and putting into KERNEL. That’s not the same.
With monolithic kernels, it’s often the same however.
With modular ones, it’s not.
With dynamicly modular ones, it’s even… well, dynamicly better.
And BeOS kernel is the later.
As will be OBOS kernel. It’s already implemented for the kernelland modules support part, but still lack fully dynamic drivers support…)
However, I don’t consider BeOS kernel as micro-kernel. Nor did former Be kernel engineers, IIRC.
> The “Big Mess” that Andrew Tanenbaum used to describe Linux
> has proved to be the most pragmatic one in real life.
I’ll have said “proved to be pragmatic one”.
“Most” implies there no other better way of doing.
As there’s always, as History/Evolution tell us.
It just take time… so many time!
> Linux has proven him wrong! And indeed,
> the biggest cluster at the VU (where AST lectures) is
> running: Linux! 🙂
That’s hardly a point, as I guess the biggest or oldest cluster in the World could be still running on very old OS technologies, but who knows?
-Philippe, OBOS Network team leader.
fooks wrote:
> There is really no comparison to be made since the BeOS
> kernel is dead, while the Linux kernel is evolving rapidly.
Agreed.
So, why do make/reply to such comparaison yourself?
-Philippe
I wrote everything in good mind.
And it’s useless respond to unconstructive posts like Mario wrote.
I can easy proof that Linux Kernel outperformed BeOS kernel in Threading & Memory Manegment. On same hardware.
And anybody can do it. Just try Raise 200 threads with simple memory alocations aka 50 KB, and join them. That should by enough as proof.
Martin
And it’s useless respond to unconstructive posts like Mario wrote.
Agreed 🙂
-fooks
So, why do make/reply to such comparaison yourself?
The original author asked comparative questions. I simply answered.
-fooks
greetings,
while the reasoning is fine i would like to point out that with OSKit ( http://www.cs.utah.edu/flux/oskit/ ) available it is possible to use Linux device drivers without using Linux.
bengt
No, it’s a far better design, using less inter-processes messaging, less userland <-> kernelland switches and a great iovec-like net data packets handling which increased performance.
This was assumed yes
Don’t confuse putting into KERNELLAND (address space)
and putting into KERNEL. That’s not the same.
With monolithic kernels, it’s often the same however.
With modular ones, it’s not.
See, for me it is the same. When you move something into kernelland (read kernel address space) you create the same structure as in monolithic kernels. True microkernels don’t allow this. You can still do message passing between kernel tasks, but that I would consider that syntactic sugar. But ok, we agree that BeOS cannot be considered a (true) microkernel.
I’ll have said “proved to be pragmatic one”.
“Most” implies there no other better way of doing.
With “most” I mean “most of the two” monolithic or micro.
That’s hardly a point, as I guess the biggest or oldest cluster in the World could be still running on very old OS technologies, but who knows?
The point I was trying to make was that AST tried to shoot down, dismiss, Linux 10 years earlier, but today he himself uses it, indirectly. That’s kind of ironic no?
http://www.cs.vu.nl/das2/das2-machine.html
-fooks
If anyone’s still reading this thread after 164 msgs…
I’ve only seen the ‘Personal’ edition that came on the cover of a CD and booting from a floppy ain’t possible now my floppy drive is stuffed…
Anyway, good luck to all the projects. A few points to consider on the “it’s the apps stupid” type taunts in an effort to break critics out of the ‘hobby OS’ mindset. (Assuming any of you give a damn about ‘critical acceptance’!!)
(a) The projects mightn’t agree on infrastructure due to design philosophies, licensing etc but I think that having source compatibility through a common API/libraries is a must. You might have 4 separate projects, but the ability to port end apps seamlessly should be high on the priorities.
(b) To facilitate this, try to agree on a software delivery mechanism. I think I spied something in the BeOS version I played with. Perhaps portage from gentoo or similar?? At least then apps can be easily maintained between the projects. I’ve heard it said that the BSD folks (Net/Free/Open) would all have much rather had a common ports tree and let the differences in the 3 be only the plumbing.
(c) Provide support for common toolkits. If not X11 in a window then maybe beg someone to port the Gtk, Qt toolkits.
I think some of these are being ported to non X11 systems such as Quartz (OSX). Otherwise, even having a Windows free machine, the dual boot thing will probably continue for many.
(d) Java. Don’t be put off by its detractors. Once a JVM is ported, many additional apps become evident. And if B*OS ever wants a server presence, Java is a key player…
(e) XUL (Mozilla). Possibly leading nowhere, but hear me out. At least you’ll have a reasonable browser. Performance of the early versions of XUL reminded me of pre-Hotspot Java (barely bearable). But XUL apps are slowly appearing in a trickle.
(f) Toolkit vs OS/kernel separation. If the “let’s base it on Linux kernel” faction makes progress, what’s to stop it being available as a module for other unices? i.e. how portable to *BSD could it be supposing a file system was portable?
I used to think that the OSkit could be the solution. I even suggested it on the benews forums in late 2000, because the OSkit website claimed it’d be easy to integrate in a existing OS.
But since then I’ve downloaded the sources once (around march this year) and read some more documentation and I found they didn’t support the complete range of drivers (not even close). I’m sure eventually it could be very usefull for beginning OS’s, but, for the time being, it isn’t the Holy Grail it promises to be(come).
Fellows,
after reading Daniel’s excellent comments, I would like to add a few myself. But first let me give you some background information about me. I used to work for Be as well, first in Paris as DTS engineer, later on in Menlo Park as PM. Nowadays I work as PM for a large European PC OEM, which some of you might remember from involvements in BeOS in 1999.
First I would like to congratulate all those who have been involved in the OpenBeOS or other projects with the goal of recreating BeOS. Approximately a year ago, when I first read about these efforts I didn’t believe that anybody would get to where they are today! This is really quite an achievemment, considering the discipline and knowledge required. After all it’s boring to just recreate as opposed to creating somethingg new and original …
Just out of pure interest, how other people are doing, who basically started the same effort for AMIGA OS, you might want to take a look at http://www.aros.org and see how far they have come. Judge for yourself. This might give a hint about OBOS future.
I do aggree with Daniel’s comments on binary compatibility. I also would prefer thinking ahead instead of recreating R5 from scratch. By the time the R1 hits the street a lot of things will be outdated and in order to survive and stay attractive a little bit more than a dated OS is required, however since the decision is done, I don’t like the idea to argue this over again … but there are quite some chunks of work in R1 which will probably never be used extensively, since a redesign or rewrite will follow in the long run anyway. The media kit comes to my mind …
Regarding BeIDE, yes I also liked it, but there are a lot of better IDEs around nowadays. If OBOS wants to succeed, thhis is the place where effort should be put. In order to atttract enough developers a good toolchain and a good IDE is needed. Unfortunately this is something, which seems to be missing from everybodys list of to do items. Yes, I know it’s really a huge effort, but the benefits are really worth the work. After all, one of the reasons why BeOS failed is the lack of applications (commercial quality applications) … think about it!
Finally I would like to add, that I’m really scared by Sony! Not because they are the fastest growing PC builder (I didn’t even bother to verify this claim), but because of their strategy and the assests at hand … market leader in consumer electronics, owner of a huge amount of content, willingness to loose big money in order to reach targets …
But YES, I woould love to see a PS2 port …
Cheers,
Marcus “rossi” Jacob
An IDE is a [seasoned Beers cringe :] “third party opportunity”. Best candidate would be Codeliege, here: http://www.codeliege.com/index.php
first lets clarify some things.
B.E.OS is a good proof of concept and theyre goal is to implement the beos api (amongst other things) on top of the linux kernel.
I do not see a problem with it.
as for OBOS im all with it.
Its a nice project, a good idea wich goes beyond just compatability with beos r5.
And aside from all the crap these guys have to take here they are doing a good job .
And THEY ARE DOING it for FREE!
and where is Yellowtab in all of this .
Well YT is beta releasing their distro it will also be a great boost for the community and for people who want to try something good fast and different.
I’d like to know what most of the people posting total FUD here are doing. since if they arent helping out why are you complaining.
Sure the tasks that the different teams are facing is no small task . but they are doing it and you .. well you seem to complain.
what am i doing.. what i can ..
im a crypto analyst not a coder…
and I have to second that wich one person said about linus torvalds.
the beos demo video thing, was done on a dual 266 p-pro …
at running i can on my box have 8 divx movies running at the same time .. without crapping out on a single p3 433 with 392 mb ram.. the movies.. ? 600mb giove or take a few megs..
Won’t editorialise here, have better to do (like coding, hey you all, just stop buzzing and start coding, on whichever project, but just CODE instead of lamenting yourself).
The linux patch that says runs about 100000 threads I don’t think the kernel was running all 100000 at once…
IIRC it had launched and destroyed 100000 threads _in_ the 2 seconds, with _only_ 50 threads running concurently each time.
A whole lot different than launching 100000 threads at once :^)
So stop FUD-ing please.
About the 4096 threads limit in BeOS, well this is _not_ fixed in the kernel, since the max-threads number varies with the amount of RAM, so I guess one could have a boot parameter (though I didn’t find any).
Ok, I stop here, as I’ve lots of code to do and many other things, so buzz if you want, but I’ll work.
not concurrent, as each thread is destroyed before launching another, but still not bad, on my “poor” K6-2 350
#include <OS.h>
#include <stdio.h>
int32 mythreadfunc(void *arg)
{
return B_OK;
}
int main(int argc, char **argv)
{
thread_id id;
int count;
status_t st;
if (argc < 2) {
printf(“usage: %s nthreads
“, argv[0]);
return 1;
}
count = atoi(argv[1]);
printf (“launching %d threads…
“, count);
for (; count; count–) {
id = spawn_thread(mythreadfunc, “a thread”, B_LOW_PRIORITY, NULL);
if (id > B_OK) {
resume_thread(id);
kill_thread(id);
wait_for_thread(id, &st);
} else {
printf (“failed to launch a thread: 0x%08lx (left %d)
“, id, count);
// return 2;
}
}
}
[revol@patrick /boot/home/devel]$ time ./testthreads 2000
launching 2000 threads…
real 0m1.154s
user 0m0.040s
sys 0m0.641s
So the only alternatives for BeOS are to run on all the PC hardware out there, or else be reduced to “hobby OS” status?
No. I disagree, not with Daniel’s logic, but with his premise. I see this “all or nothing” thinking as the biggest single problem in the Be community. IMO, we are not destined to be a mass marketing juggernaut . . . and neither are we relegated to the “hobbyist OS” scrap heap.
IMO we are shooting at a moving target . . . as mass marketing is “melting down” all around us (not my original thought) . . . and new integrated motherboards invite us to “point and laugh” at much of the current hardware BeOS never supported. Well, thank goodness for that:-)
Linux? First, thanks to you Linux for the many ways we benefit from open source. Linux as marketing example? No thanks . . . you missed your window . . . and it was an outdated “mass marketing” window anyway . . . now you are being propped up by a some large always-late-to-the-party corporations . . . which gives you some staying power . . . that’s about it. Linux as kernel? BeOS right now supports the hardware I need . . . far more than is widely perceived . . . so the driver argument is pretty much bogus for me.
When you get really really old like me you realize often the truth is found in the middle, by people who keep plugging away. Very seldom is the actual outcome one of the “all or nothing” alternatives we romanticize about.
I find BeOS right now runs on a very exciting subset of new x86 hardware . . . and certainly I will migrate to OBOS as it continues to develop.
YC . . . why should I trust PalmSource based on their behavior so far? First they suffocate their hostage . . . now they try to collect a second ransom.
What do you mean by this? I don’t think there is such a thing as “multimedia streaming capabalities” inside the BeOS kernel.
Sorry (damn typos), it was data-streaming capabilities (BStream class in BeOS), although i just noticed that there are other OSes with this (XP):
http://www.extremetech.com/article2/0,3973,12576,00.asp
(at the bottom of the article)
I find BeOS right now runs on a very exciting subset of new x86 hardware . . . and certainly I will migrate to OBOS as it
continues to develop.
There’s hardware that it runs on, then there’s hardware that you plug into it to extend its uses. I think you’re forgetting the latter. It’s when you start to consider the latter that things begin to look bleak.
Why waste your time? Put your skills to use building something people will actually pay for and use. Unless, of course, developing successors to BeOS is your hobby. In that case, more power to you.
Gnome KDE X all absolutly 100% satisfaction not guaranteed illigal in 43 states, no refund, dead man walking on the green mile SUCK!
the native BeOS GUI is far superior, it makes sense it comes with a nice Posix terminal you boot into it really fast, there is no debate what to use, your apps work nicely. there is no stupid login when you boot up, Remember folks BeOS was built as the Multimedia OS
its primary design, light efficient way to play and design multimedia. The BeBox was designed around this, and it still does a good job even today,
this idea is shit
>>YC . . . why should I trust PalmSource based on their
>>behavior so far? First they suffocate their hostage . . .
>>now they try to collect a second ransom.
Ask yourself one question.
Would it Be a good idea (profitable) for PalmSource to have a finished BeOS in the market at this time?
Consider the market situation.
The MSFT antitrust case etc…
The fact that PalmSource is still part of Palm Inc.
What the core business of Palm Inc. is…
yc
There have been some comments about establishing a non profit corp status in the US. This is nice for contributions but not a requirement if I understand thinks.
I am wondering if there is a method to mail in contributions to either OBEOS or BEUNITED in the US.
PayPal will not work for everyone and I have not been able to find an address for contributions.
There may be a good reason for this but if I am just missing an address please post it.
*** Ben
BeOS is dead. I love the little operating system. It’s an amazing OS, but we need to move on. I agree that when an actual alpha is realized it will be outdated. We should take the best parts of Be and apply them to another operating system like freeBSD. Plus freeBSD has the advantage of not having to mess with the GNU.
> BeOS is dead.
[revol@patrick /boot/home/devel]$ date
Thu Sep 26 23:52:02 CEST 2002
[revol@patrick /boot/home/devel]$ uptime
BeOS System was booted 14 hours, 24 minutes, 43 seconds ago.
looks to me it’s still breathing :^)
btw… FreeBSD has a gnu/ folder AFAIK.
and GNU is not a mess, again stop the FUD please.
Of course BeOS is dead, and we *are* moving on: OpenBeOS, Blue Eyed OS, Cosmoe, Leonardo…
It just so happens that BeOS and BeOS PE are still necessary and useful links to the future that many of us desire.
I wished we could win more ex-Be-employes to help us working on a new OS.
And the NDA?