[openbeos] Re: Name, Compatibility

  • From: "Yuri Titov" <yurititov@xxxxxxxxxx>
  • To: <openbeos@xxxxxxxxxxxxx>
  • Date: Tue, 4 Sep 2001 19:12:26 -0500

oh, and another thing. people are worrying too much about the name. lets get
something done then worry about the name :)

-yt

----- Original Message -----
From: "DarkWyrm" <bpmagic@xxxxxxxxxxxxxxx>
To: <openbeos@xxxxxxxxxxxxx>
Sent: Tuesday, September 04, 2001 4:56 PM
Subject: [openbeos] Re: Name, Compatibility


>
> >
> >Open Source Projects need Happy, Zealous workers. So try not to be
> >discouraging and if you think someone is of on a tangent try and think of
a
> >way for them to achieve a middle ground.
> Much agreed. Disagreeing is fine, but don't be mean about it. :)
>
> >Firstly, Name.
> >    A good name is difficult. It will also probablely come in an
unexpected
> >flash. In the mean time, we use a code name.
> >    BeOS was BuzzwordEnabledOperatingSystem
> >
> >    So my suggestion is BuzzOS or OpenBuzzOS
> >
> >    Or YAOSOS BTOIBOBNU ;)
> >        Yet Another Open Source Operating System. But This One Is Based
On
> >BeOS Not Unix.
> >        Prounounced - YASS-OS TOY-BOB-NU
> IMHO, I think what we've got is just fine, and if we come up with a better
> one down the road, great. The team is named after OpenBeOS, and part of
what
> we need right now is name recognition. That's why some commercials keep
> repeating the name of their product. Some people have heard of BeOS. If we
> change right now, we lose that. My $0.02.
>
> >Sencondly
> >    If Microsoft has acknowledged the need for interoperability so should
> >we. The FAT FS is only still around because most operating systems
support
> >it.
> >    So don't squash ideas of NFS drivers, X adaptors, and QT libraries.
It
> >is not the projects primary concern, but they are still important for end
> >users, and code & platform testing.
> >    And don't ignore the possibility of porting the code.
> >
> >    Applications are vital to an OSes success. All I run on BeOS is the
> >development kit.
> >
> >    On a QT port, don't implement the fancy features. Determine the
absolute
> >minimal support required from the OS. This should be basic of the App/GUI
> >Kit. Write to this, develop you testing on top. This will give the
App/GUI
> >Kit team a set of requirements.
> Other stuff isn't bad, but we really should keep focused on what needs
done
> in the short run and the
not-short-run-but-it's-too-short-to-be-in-the-long
> run. BTW, we've got QT, courtesy of TrollTech. Don't know how good it is,
> though.
>
> --DarkWyrm
>
>


Other related posts: