[openbeos] Re: libscreensaver.so Proof of Concept
- From: "Cedric Degea" <cdegea@xxxxxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Sat, 08 Sep 2001 01:02:25 +0200
>>even if the arguments come directly from Be, Inc ?
>
>I was always shocked how sensible the BeOS community and
>Be Inc. itself reacted about criticism the last 5 years. And
>somehow it's pleasing to see today how right all that critics
>has been, as some internals about BeOS come to light here.
>On the other hand, it would be even more pleasent if I would
>have been wrong. I just hope the OpenBeOS community can
>learn from this, that it will not repeat Be Inc's failure to listen.
I think I get your point.. Be was the friendliest company I've
ever know, but there's a bit more they could have done yet..
(context: I've had semi-short experience with the C= Scene,
but know just liek everyone how "friendly" the email addies *@apple
and *@micro$oft are).
My (short, don't worry I'll try not to be a pain :-) take on
the recent talks about the ""ugly BeOs internals": we have a
--really stupid-- TV advertisement here that was going on in the
last few years, about a yogurt whose "benefits inside the body
are visible from the outside" (follows a panoramic of a breath-taking
good looking naked lady eating a yogurt, and all the usual marketing
crap :-). I believe this holds true for Windows, the 25Mlocs
in Win32 style reflect to the user experience. I also believe
this "universal physics constant" applies to BeOS, unless
it's an alien OS as bedope once suggested. Hence the obvious
conclusion: the Be engineers are perfectionists, in other
words the recent discussion makes me respect the good folks
at Be more than it makes me run away from my computer screaming
(and actually i've never been so active with my BeOS partition(s)).
My 2 dinars, as usual.
>>- cedric (on the "competing" project but wishing that this
>
>I don't think that both projects compete that much. Most of
>the high level code should be shareable, and many of the
>middle level should be, too. When time comes, both projects
>should cooperate.
You couldn't invoke this point at a better moment, probably.
The heck with my "lurking mode", I'll first talk a bit about
this to the OpenBeOS team before being silent: see at the bottom
of this mail. No rocket science or smart deductions, but just
all arguments grouped in one or two paragraphs.
>>be Open (!) to discussion and constructive criticism from
>>knoledgeable people, folks)
>
>Even from the unknowledgeable people! Just because
>someone is well known, his opinion doesn't count more than
>others. We already had a period where EVERY word from
>a Be Engineer was treated as pure truth, just because he
>was a Be Engineer.
>
>Even me is sometimes wrong. :-)
well, dunno, as long as I don't make others angry... that's ok :-)
Anyway, $cat __openletter_to_openbeos.html, mode="sort of",
context="doing this w/o agreement from the rest of the BlueOS team,
this is a non-finalized draft":
<h2>Meta</h2>
This is an open letter to the OpenBeOS team (!) in the "let's not
duplicate too much work if we can" spirit. If not useful right now we
hope
it triggers some thinking at least later... The OpenBeOS/BlueOS "schism"
stems from a different philosphy choice regarding
interoperability/binary compatibility, and a differnt choice of kernel.
But beside the kernel and the framebuffer subsystem, much of the
high-level code that's gonna be written by the members of both groups
(BFile, BNetEndpoint, BString, BMessage, BMessageRunner, high-
level BView subclasses like BButton, BListView, the userland apps like
preferences/* and tons of other things) could be totally similar if
we ever choosed so, since it's independant from the lower level
implementation details. Only some licence issues remain (MIT vs Closed)
but it would be a shame to not investigate whether they're a show
stopper or not.
<h2>Draft</h2>
[snip a part that's too early/ugly yet]
As I said before, before even "officially" kicking off, both concepts
should be "validated".
Form my (limited) understanding, the proof of concepts would be,
respectively:
For OpenBeOS: a proof-of-concept thread that mimics an app_server side
("phantom"?) BWindow thread and succesfuly manages
to cheat the application-side thread into believing it's running as
usual. Otherwise it could be a show stopper if something that
much central is not accessible to Rev.Eng.
For BlueOS: a proof of concept that it's possible to leverage XFree from
a heavily MThreaded environment, or it could very well
be a major show-stopper if something that paramount doens't work.
If only one of them groups has a skilled enough member to come up with a
working prof of concept in bits concrete code and all, then
logically the other group should merge efforts.
If both do then both are free to start working, accept code submissions
at any level from less-than-guru-level hackers (or hacker wannabes
like me :-), and even "compete", but both should consider doing so for
not too long.. and maybe merging later.
If none do then we're doomed /or/ have to pray and hope for Palm to
smell the elegance..
Again, and that's the point of this message I want to get emphasize, in
all cases the upper parts (kits that would have to be done
indentically by both groups, contrarily to the kernel and framebuffer
code) will be the one that the dev community can unite on easily
(barring licence considerations.. closed source? OpenTrakcer licence?
BSD?), so hopefully both groups focus on the difficult stuff first in
the coming weeks, and later on manage to find a way to share work on the
kits, rather than duplicate it.
So eventually having two competing concepts is not such a waste, though
still quite abit of work will be lost at the end.. Let's do this as
constructively as possible, this is not about individuual interests
folks. This is all for BeOS. Maybe we could write a uique FAQ on the
topic on only have specifics on our respective web sites for example..
We hope that the reaction to this letter is not "well duh you stupid
twharts you split from us, not us from you" :-) because BlueOS history
goes way back then at the time Be officially announced they were hiring
Barant investment bank (way before the Palm take over) and
because our intent is not aggressive nor to moan. If this text makes you
unat ease then just ignore us and keep up the good coding, thank
you. We feel strongly compelled to at least try our best to discuss this
important issue but don't want to force that discussion on anyone.
EOF
(note: the conclusion was written at a time where more or less
constructive
criticism was flying to our heads, I would remove much of the verbosity
if writing this these days, as minds seem more positive now :-)...
--
http://cdegea.free.fr/ | BeDev E-16870
"God exists, and she loves Bill" -- BMessage
Other related posts:
