[openbeos] My Big, Fat Catch-up Email
- From: "Erik Jakowatz" <erik@xxxxxxxxxxxxxx>
- To: "open beos" <openbeos@xxxxxxxxxxxxx>
- Date: Tue, 11 Sep 2001 23:18:34 -0700
I'm done doing piece-meal replies to stuff that's 10 days old. I'll
just do my catch up and try to grab everything that I need to reply to
in a single mail -- and beg your forgiveness up front for its length and
redundancy. =P
On Helmar's Final Word: guys, we gotta get real here. Do you *want*
GeForce3 drivers? Nvidia doesn't seem too friendly to the idea of
giving specs to opensource folks for the purpose of implementing
drivers. No, they like to keep that stuff in-house or under strict NDA
with another *company*. This is gonna be the case for a *lot* of
hardware. If nothing else, hardware companies are going to want to see
that somebody is willing to run the risk of supporting the OS
commercially before they'll invest in writing the drivers themselves.
Unless we want this to wind up being a massive act of geekly
self-flagellation with no real future, somebody is going to have to
market/promote/commercialize this thing. People have said it before,
but it apparently bears saying again: Linux, that shining triumph of
opensource, would not be enjoying anything like it's current hardware
and software support without the *major* efforts to commercialize it
that have been made by Red Hat, etc. To believe otherwise is, frankly,
to live in fantasy-land. Although I think Helmar's statement that
"OpenBeOS == Death" is a bit extreme, I must agree in the strongest
possible terms that for *any* implementation of BeOS to go anywhere,
someone will eventually have to support it commercially, and Helmar &
Co. have got the credentials and the passion for the OS to make it
happen. If Helmar & Co. and/or Palm can make this happen in the near
future, we can count ourselves as being very lucky. I don't know a damn
thing about marketing, but I'm smart enough to know that without it,
we're doomed to eventual irrelevance -- and that's not something I'm
interested in wasting my time on.
On the existence of OpenBeOS: if Helmar & Co. (or somebody else) can't
cut a deal with Palm to continue development of the existing codebase,
we have no choice for the future of the OS other than an opensource
implementation. The existing development and user communities are not
going to hang around while the OS slips further and further into
obsolesence. Yes, a few of the total diehards will keep using it until
it's just plain ridiculous to continue, but the majority of folks will
bailout if nothing happens to update the OS itself. Extensions are
great, and I hope people keep making them, but without continued
development, BeOS will be like Latin: interesting to a few, and dead
for everybody else. As far as OpenBeOS being "a very different OS", it
will only be as different as we make it. We're commited to the goal of
reimplementing the OS in a way that is _at_the_very_least_ source
compatible with R5. If in the course of doing this we add some extra
nifty bells and whistles, I don't think anyone will complain -- we would
simply be jumping ahead to R6, that's all. =)
On "a million different projects": There are not, to my knowledge, "a
million different projects all trying to achieve the same goal". To my
knowledge, there is OpenBeOS, BlueOS and the "Phoenix Group" (for lack
of a better label) -- each of which is currently taking a very different
approach to ensuring the continued development of BeOS. If the Phoenix
Group is successful, I have the distinct feeling that OpenBeOS and
BlueOS will soon find themselves irrelevant to the majority of folks in
the dev and user communities -- in fact, I think most of the devs in
those efforts will lend their support to the Phoenix Group rather than
messing about out in the weeds. And if they aren't successful, I'm
betting whichever reimplementation effort takes the clear lead, the
other will soon either join forces or fade into obscurity. Any way you
slice it, we'll probably end up with one clear effort leading the way
before very long.
On starting from scratch: Neither OpenBeOS nor BlueOS is proposing we
start from scratch. OpenBeOS aims to make its work drop-in replacements
for existing OS systems. Both projects will be heavily leveraging
existing opensource resources in their efforts. Witness OpenBeOS's use
of NewOS and BlueOS's use of the Linux kernel. As far as ruining
NewOS's chances of success, I'm not under the impression that Travis had
"success" in those terms in mind for the project (feel free to correct
me if I'm wrong, Travis).
On blowing off a possible deal with Palm: Nobody's blowing off
anything. You may be familiar with the Boy Scouts motto: "Be
Prepared." That's all we're doing -- being prepared for the most
unpleasant of many possible outcomes of the Palm negotiations. Any deal
the Phoenix Group makes with them changes the landscape drastically, and
everything will have to be reconsidered, whether we like it or not.
Nobody's trying to antagonize Palm or anybody else -- we're just trying
to keep the OS alive, which is what all of us want, right? There are, I
think, a few extra-enthusiastic members of the OpenBeOS effort who are
pretty solidly in the "opensource or die" camp, but I don't get the
impression that this represents the majority (or even a large minority)
of the team. By and large, we're open to the realities of the
situation, and are quite pragmatic about how to achieve our primary goal
-- BeOS's continued growth and existence. We are *not* the enemy of the
Phoenix Group, and the Phoenix Group is *not* our enemy: there will
always be those who think that commerical considerations are totally
unnecessary, may even believe that they constitute selling out, but
cooler and more realistic heads will prevail (hopefully). What we all
really want (whether we individually realize/admit it or not) is for the
OS to be commercially viable, because that's how BeOS will get to be all
we want it to be -- whether it's a Palm deal or OpenBeOS or BlueOS that
gets us there will be, in the end, beside the point.
On moving to GCC 3.0: From what I've seen GCC 3.0 is not really ready
for prime time yet. Yes, it's got oodles of cool new stuff, but now is
not the time -- we have to keep the developer and user communities
hanging in there, and heaping a (mostly) unneccessary binary
compatibility break on top of everything that's happened so far would be
tantamount to shooting ourselves in the head. Once we've gotten ver.
1.0 accomplished and regained dev and user confidence, *then* we can
talk about GCC 3.0. It's not like it's going anywhere. =)
On using a Qt/GTK/whatever port: Ports of this software would be/are
undeniably cool, and I whole-heartedly encourage non-OpenBeOS team
members to pursue this as a worthy and very useful accomplishment. They
do not, however, get us any closer to our goal. What, exactly, would a
"native" Qt port sit on top of? The interface kit? We'd have an
extension then, not a replacement. BDirectWindow, or maybe
BWindowScreen? That *might* have some merit, but I would submit that
the work necessary to a) make Qt work with either of those classes and
b) write a BeAPI compatibility layer on top of Qt will, in the end, be
at least as much as just writing the stuff from scratch. You would
still have the problems of actually making apps use that instead of
using the pre-existing libs, providing classes that aren't widgets but
are still part of libbe, and dealing with the fact that Qt is designed
(as I understand it) to be used in a synchronous fashion, necessitating
a lot of work to get it wrapped around BeOS's multithreading paradigm.
In short, using Qt in this capacity *seems* like a tempting shortcut to
the holy land, but that shortcut is only surface deep. On a related
point, the Interface Kit team *has* its requirements: the BeBook! =)
On just moving to AtheOS: This is a very tempting thing to do, and you
can't discount Kurt's ability as an engineer -- he's obviously quite
talented. He is also, unfortunately, not interested in the idea of
AtheOS being made into a full-fledged opensource BeOS clone. He has
different ideas for his OS -- that's his perogative, and I can respect
that. Some people have called for forking the code, which brings us to
the next issue: although BeOS and AtheOS are quite similar conceptually
and architecturally, they are not the same, and important things to hang
onto from BeOS (like existing apps and drivers) just aren't going to
drop in. A significant amount of re-engineering would be necessary, and
I'm not convinced that we'd really save much time going that route.
This sort of falls into the same category as the Qt port suggestions:
looks like a good shortcut, but odds are it won't be in the end. All
this is not to say that we can't get a lot of great implementation ideas
from AtheOS -- we can and absolutely should examine it quite closely for
whatever insights we can gain. One last thing: some people suggest
bailing out on BeOS altogether and just becoming AtheOS users. All I
can say to that is BeOS as it exists is far more complete and polished
as an operating system. Personally, I'd wait until AtheOS has gained
that level before bailing out -- you'll only lose functionality before
then.
On adding multi-user capabilities: In my mind, there are two ways to
define "multi-user". First, is the classic *nix concept of multiple,
simultaneous users which we all know and love (sorta). Second, is a
system which allows for multiple single users (if that makes any sense)
where each user has his/her own home directory and, consequently,
his/her own settings, etc, and where users are prevented from stomping
on other users' home dirs and on the system as a whole (unless they have
root/admin priviledges). The first definition belongs, I think, to the
realm of servers, which BeOS is not and, IMO, should not aspire to
become. After all, we have a perfectly usable and well-supported
opensource server already in existence -- Linux. Although people gripe
about the quality of the Linux desktop experience, I don't think there
are many folks outside of Redmond who will seriously bash it as a
server. To me, Linux and BeOS are the ultimate combination: BeOS on
the desktop, Linux in the server closet. I would personally love to see
the second definition of "multi-user" implemented in OpenBeOS. It's
more of a "multi-configuration" scheme, really. I think it's do-able in
a reasonable time frame and desirable. The *nix definition will be very
difficult to implement (for reasons discussed elsewhere, track them down
if you're really interested), and not all that desirable. This is not
to say that BeOS shouldn't be used as the light-weight (in the best
sense of the phrase) server that it is already capable of being. But it
shouldn't be forced into becoming the heavy-duty, industrial-strength,
multi-user server that Linux is a great example of; there's really no
defensible point to it.
On BeOS design flaws: I'm neither surprised nor dismayed to learn of
the glaring problems that JBQ has so kindly pointed out for us. It is,
unfortunately, the lot of shipping software to have these sorts of
issues. My primary work at the day job is maintaining a fairly popular
and commercially successful Palm app, which is an absolute horror
design- & code-wise. The best we as engineers can hope to do is avoid
problems when possible, and fix them when we can. Regardless, I'm in
BeOS 99% of the time at home (and that's no exaggeration) simply because
it's more responsive and stable than Windows. I've never been the type
to monkey with alternate OSs just for the fun of it (I have *never*
installed a Linux distro, for instance), and before R3 shipped, I was a
die-hard Windows user and developer. In spite of its flaws, BeOS still
offers the best overall desktop experience. I am, however, very
grateful for what JBQ and Manuel and others are revealing; it will only
help us in the long run, whether we end up going the distance with
OpenBeOS or working on Phoenix Group code.
On BeOS development: I don't remember who suggested that developing for
Windows and Mac is easier than developing for BeOS, but I actually
laughed out loud at that. =) I haven't developed for the Mac, but I've
done *plenty* of development for Windows using the raw Win32 API,
Borland's OWL and VCL (Delphi/C++ Builder), and some MFC, and unless I'm
seriously missing the boat, none of these is as easy, sensible and just
downright elegant as the BeAPI. When I got to BMessage in the BeBook (I
basically read it from cover to cover), I knew I'd found the holy land.
;)
In conclusion: our absolute best bet by a very long way for the
continued viable survival of BeOS is Palm licensing to the Phoenix
Group. There is simply no two ways about it -- working from the
existing codebase will save us *months* or even years of design and
implementation work. Sure, we've got an awful lot laid out for us in
the BeBook and Be Newsletters, etc., but that just can't touch having
the source. And even *if* Palm were to just release the source (c'mon,
do you *really* believe they'll do that?), we'd still need marketing
muscle to keep things moving. There's a very good argument to be made
that Be's marketing is what killed them -- they did a great job of
evangelising to the devs, but most everybody I've talked to about what
I'm doing with my free time hasn't got clue one about BeOS. And these
are folks that are in the industry, following the trends, reading the
magazines, using alternate OSs, etc., etc. I've said it before, and
I'll say it again: I'm 100% commited to doing *whatever* it takes to
keep BeOS alive and thriving. My involvement with OpenBeOS is
predicated on the possibility that Palm will *not* cut a deal and will
*not* release the source to the masses -- but I sure would *love* to be
proved wrong on that count. Keep your eye on the prize people -- it's all
about the BeOS, and that's the bottom line.
e
Data is not information, and information is not knowledge: knowledge is not
understanding, and understanding is not wisdom.
- Philip Adams
Other related posts:
- » [openbeos] My Big, Fat Catch-up Email
