[openbeos] Re: BFS and encryption.
- From: "Michael Phipps" <mphipps1@xxxxxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Wed, 31 Oct 2001 22:23:52 -0500
>>Why do you recommend us to break binary compatibility now?
>
>As I said, because I'd rather do the weed out applications
>now than later, because you will surely piss off more
>developers when BeOS has gained more support than it has
>now. Now it's at the bottom, so it's opportune to do it.
>Again, this is from a marketing angle, not a development
>angle.
I can really see both sides of this.
Think for a moment about how many apps we will lose. Do you really
think that even 10% of the developers are still around? Sure, we have
new ones. But most source code isn't released. I am writing this on Postmaster.
I do *NOT* want to lose that. Nor Productive. Nor a dozen other apps.
Not without a better reason that "we may have to some time in the
future". Personally, I always thought that there has to be a better way
to do loading of different pieces than one size fits all.
>The problem is that if you do it later, it is _us_ who sit
>there with the problem of annoyed developers. _us_ in
>anyone wanting to market the [x]BeOS. If you don't have
>such plans with OpenBeOS, then good luck. ;)
We don't want to annoy anyone. That is the issue at hand. If we didn't
care about annoying people, we would go with GCC3 because it is
cooler and we are all, face it, techies. The fact is, we don't want to annoy
ourselves by having *NO* apps. The whole POINT of making OBOS
instead of "radical, cool OS that I designed all by my self" is to have
community
and apps. Why walk away from half of that for no solid reason at this point?
I would MUCH rather try to recruit and sell when I can point to 4000 apps than
when I can point to 4.
>>The server apps of cause need to be rewritten, but this
>is >part
>>of replacing the whole kit, and not breaking anything.
>
>Well, I was talking more about the kernel, but as it's
>based on NewOS right now, the point is moot. If we talk
>about the BeOS kernel it's a different issue, but then
>again, this doesn't belong here. My mistake, I admit.
Everyone assumes that a new kernel means that all backward
compatability is broken. This is only even close to true for
device drivers (and not even 100% true there). In fact, the
kernel is the 1 piece that we could build with GCC3 and maybe get
away with it, since it is C and not C++.
Loaders, linkers, compilers and kernels are the toughest things in
computing to write, IMHO. Many people have opinions that are not
based on an expertise in these things. Be careful of who you listen to.
Other related posts:
