[openbeos] Re: Fwd: OpenBeOS suggestions (quite long)
- From: François Revol <revol@xxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Mon, 29 Jul 2002 00:34:33 +0200 (MEST)
Replies interleaved...
En réponse à "Bruno G. Albuquerque" <bga@xxxxxxxxxxxxx>:
> I am crossposting this to the openbeos and Glaslevator lists because I
>
> think this is relevant both to current and future developments. The
> original author is Marton Fabo <morton@xxxxxxxxxx> so you should
> contact him if you want to discuss it further. I will be glad to hear
> opinions about this.
>
> ----------
>
> Hi!
>
> More than a month ago, I threatened you with sending you some list of
> points I think would be important to consider or take into account
> while
> designing/building OpenBeOS. Lately, I became a bit busy, but now I
> fulfill
> that threat.
>
> Although I don't precisely know what the intent of the whole project
> is, I
> suppose that having the result become successful and usable (not just
> for
> geeks/hobbyists) is the goal, so I compiled my list with this goal in
> mind.
> Much of it is of a nature that has to be considered quite early in the
>
> design process of the relevant subsystem.
>
> So here it is, my brief points without any particular sorting, about in
>
> the
> order they came into my mind over the weeks...
>
> Integrate as many concepts into the system as possible. This means that
>
> if
> some functionality is already implemented, then have the programmers
> use
> those, instead of trying to implement the same functionality on their
> own.
> The same goes for extracting information. And not just at the level of
>
> APIs
> and libraries, but in the user space also. Hope you get the point.
>
> Investigate any existing libraries with similar (to each other)
> functionality, and picking the one considered the best for "standard"
> or
> "default" for the system, whose presence any software can count on
> (this
> idea a bit modified below). Offer the other possibilities as options,
> but
> not recommended. If you can come up with better solutions than found in
>
> any
> of the existing libraries, then go and implement it. But if not, adopt
>
> what
> is already there.
That is what we did already, and will do in the future. Take Terminal as
example, as I said in a previous mail, there are 2 Terminal-like apps on
BeBits already, and both are open-source, why would we have to write a
3rd one ? We will certainly just take one of them, or maybe merge the 2,
and just add what lacks, and we'll have a compatible Terminal, with even
more features !
That is also what we did for the kernel. We chose NewOS because it was
already quite advanced, and fitted the purpose.
Another example of reuse, I had to implement several POSIX fake funcs
in order to port some software (like setitimer() for XEmacs), and I'll
put all this into a lib so other ppl can use it, and when OBOS comes
we can reuse part of this code to implement native funcs.
>
> Closely investigate existing operating systems, and their
> functionalities.
> Integrate any good ideas, parts, steal as much as you can, if you don't
>
Hmmm, that sounds like a call for revolution :)))
Hmm talking about good things, while hacking my fake mmap(), Icame across
this:
http://www.qnx.com/developer/docs/qnx_6.1_docs/neutrino/lib_ref/m/mmap.html
It's the QNX mmap() man. QNX has some mmap() extensions which seems really
nice (and also looks like quite easy to map to *_area() calls... or even
map_physical_memory() with some help from drivers =))
Of course OBOS doesn't target RT systems (hmm, not so sure... BeOS
is pretty good at that :)), but that API exist, so why designing another ?
(/me dreams about QNX developers coming to BeOS =)
Of course the mmap64() call is pretty simple in BeOS, just one line =)))
> already have a better solution. For example, the BSDs are full of
> freely
> usable code/functionality, which you can simply use or use them as a
> starting point for a better solution. Example: NetBSD's package
> system.
>
> A well thought-out package system. The current situation with BeOS is
> miserable, at least with regards to consistency. BeBits may be a good
> source for software, but it lacks a whole lot of concepts. Again,
> NetBSD's
> package system may be a good starting point, partly because it's
> intentionally designed to be portable. I think it has some flaws yet,
> which
> you could do better with your system. This modifies a bit the idea of
> having libraries always available for any software, as they can just
> include the ones they need as their dependencies; but having preferred
>
> solutions/implementations for specific functionalities is still
> important,
> partly because consistency and homogenity among software.
>
> (Consistent) graphic interface for anything you can think of. Don't
> force
> the user to remember and use command-line tools, edit config files etc.
*But* leav the command tools as an option. To me BeOs is the best mariage
between cmdline and GUI, most operations can be done either ways, and this
is one of the things that makes me like it.
>
> Here I mainly mean configuration panels, but anything can be thought of
>
> that is part of the system, and the user has to interface with it.
>
> Implement anything you can in the form of add-ons. Don't hard-code
> anything
> that isn't absolutely necessary to be hard coded. Having a system to be
>
> modular in many aspects (in many more aspects than current systems use
>
> to
> be) is key to a great freedom, I'm sure you don't argue about this.
> BeOS is
> a good start in that direction, but this approach must be extended in
> many
> ways the BeOS didn't intend to. Apply this to things at levels as low
> as
> the VM or the executable format, or to things as high as the language
> of
> the interface.
I've already some ideas about the Media Kit also...
Just thought we could have some kind of 'auto_babelfish' devel tool,
that is not something that uses the web, but something that would
collect strings in the code, and would send them to a website, mailing
list, whatever, which would have ppl that wishes to do translation,
maintaining a db of strings already translated, and adding the new ones.
The translations would then be available as a package to update.
New apps that needs translation would use english strings until the
package manager updates the locales package.
>
> Binary compatibility with the most systems you can achieve (Linux, BSD,
>
> Windows, anything). Take already existing solutions for this. Have a
> close
> look at NetBSD from this point of view. It has binary compatibility
> with a
> great amount of systems, including, for example, Linux. The latter is
> achieved by implementing (or emulating?) some Linux system-calls, and
> mounting a file system of linux libraries "above" the normal file
> system,
> but only for linux executables. This is to avoid Linux execs trying to
>
> link
> NetBSD libraries. Consider this functionality very seriously, as it can
>
> give you a great amount of working software out-of-the-box. Even
> proprietary ones, that you can't just port, because the lack of
> sources. I
> know achieving this is a very big task, but the benefits are huge
> also.
This is called interoperability.
I know of several current projects that aim at this on certain domains...
Also, we should have a look at
http://line.sf.net
and this which someone submitted to me:
http://www.ugcs.caltech.edu/~steven/lxrun/
There is also Plex86 (learnt there used to be a BeOS version =),
unmaintained though, couldn't compile it... even with mmap() :^)
WINE that needs... mmap() hehe :-)
Also VNC, RDP ( http://rdesktop.sf.net ), ...
I've been working on VNC recently...
My final goal on the client is to make it available as a replicant,
so every app can use it to display a vnc: link =)
We would do the same with rdp:
>
> Support mutiple executable formats. This partly falls in the category
> of
> having functionality implemented in form of add-ons (so that this can
> be
> extended by thired parties, without recompiling the system and sismilar
>
> stuff). But even if support for various executable formats can't be
> implemented in this form, but have to be hard coded, provide a variety
>
> of
> choices. I mean here native support for ELF, a.out (pre-R4 stuff, if
> I'm
> not totally wrong, right?), windows format (PEF, or what the hell), and
pre-R4 was PE (the same as windows binaries). PEF is the MacOS and BeOS-ppc
format. a.out is old Linux and UNIX format.
Linux also has a thing called binary personalities, an integer in the process
context that tells the kernel to mimic another OS/file format/...
and bin formats, which acn be registered as kernel modules, like
bin_fmt_java, bin_fmt_misc (user defined ? used to run wine exes IIRC)...
>
> even Java bytecode. Again, take a look at how NetBSD does the same.
>
> Programmer interface for any adopted libraries, that fits into the Be
> API
> (where this is possible), so that the programmer doesn't have to give
> up
> the Be programming style just because using various libraries.
>
> Support multiple APIs simultaneously, for supporting different worlds
> of
> programming. Examples include the Be API, QT, Carbon, WinAPI, etc. This
No need to make Noe's boat :)))
But yeah, having available forein APIs can be nice.
(I wouldn't want WIN32 myself, but it would be really nice to have :))
>
> would make source compatibility and (im)portability much greater. Of
> course, keep a preferred one, which of course would be the (heavily
> extended) Be API. Full POSIX support also belongs to this point.
That we take care =)
>
> System (API) level support for multiple languages. This would introduce
>
> a
> unified way of choosing the language for the system and for various
> third
> party software. Of course, the language must not be hardcoded into
> localized versions of the system, but has to be switchable (on the fly,
>
> per-user etc). The API should make it mandatory to allow third-party
> localization of software, without access to the sources, and without
> the
> collaboration of the author. Adopt an existing system/implementation if
See my point above.
>
> there is one that suits the requirements.
>
> Steal hardware device drivers from existing systems. Hack together
> quick,
> experimental, unsupported drivers from any driver you have access to
> (from
> Linux, BSDs, Windows etc), just so that they work and somehow drive
> their
> respective HW, and then work them out correctly to be fully functional
This is *really* a call to rebellion :))))
Yeah, just begun a VMWare driver from the XF86 one (actually just string
substitutions for now but it's a start :D)
UDI support would help too...
>
> and
> stable.
>
> If possible, support drivers from other systems (mainly Windows) in
> binary
Wow, that would need a load of H4cK3rZ !!!
> form. If you can achieve this, you immediately have an incredible
> amount of
> supported hardware. Of course, native drivers are needed for full
> functionality and performance, and are absolutely and ultimately
> preferred.
>
> Certification system for software (and mainly drivers), just like WinXP
Hmmm, usually that involves a QA lab with a lot of ppl payed to crash the
drivers... $$$
>
> does. Correct notification and education of the user regarding the
> issues/impacts of this system and decisions made based on it. For plain
>
> software, I mean certifcation to be a quality/standards-compliance
> assurance by some third party. Essentially the same as for drivers,
> just it
> doesn't influence system stability as much.
>
> Close to the above is a system for signing drivers/software/packages by
>
> authorities the user may or may not trust, and giving a chance of not
> trusting unsigned software.
>
> Real (not just planned) support for multiple monitors (I wrote above
> that
> there won't be any particular ordering :)
>
> A concrete concept: a general interface to control and monitor the
> status
> of dialup (in general, non-presistent) connections.
>
> Networked app_server (in essence, terminal services), with already
> existing, or to be made client (possibly integrated into the app_server
Not sure that is top priority though...
>
> itself). If a new protocol/implementation, then support for dumping
> OpenGL
> and such things across the wire, for better performance (essentially,
> don't
> render on the server side and then dump the image, but dump the
> instructions, and render on client-side). This probably assumes having
To sum up,
"X11 done the good way" :)
>
> both
> the server and the client also integrated into the app_server.
>
> Correct, and worked-out support for printing. This includes such
> details
> as, for example, the possibility to choose the desired printer just in
>
> time
> of printing from within the caller application, not only in the
> printing
> preferences panel.
Shouldn't be too hard, anyone from the Print Kit ?
As last ressort, fire up the Printers prefs on the App calling the printer
setup so it can be changed.
>
> Correct support for multiple users, with permissions, policies, all the
>
> relevant stuff. Support for parallel sessions, just like X or WinXP
> does.
Huge, and very fashionable, but a must have.. GE stuff, but yeah, just
keep the provision in app_server (Be's did too, but it's not complete
enough to be usable, c.f. APP_SERVER_NAME env var)
>
> Of course, all the stuff above and below don't have to be implemented
> immediately, but the connecting parts of the system should at least be
>
> designed with these things in mind, so that implementing them later
> would
> require a minimal amount of rewriting/redesigning. Somehow like Be were
>
> aware of multi-monitor or multi-user support, but in much more aspects,
>
> including my points, and many things I couldn't think of...
>
> A much better Interface Kit. Having a layout engine, for faster
> development
> and having more homogenous, nicer software. Have sophisticated
> controls,
> steal ideas from Kai's software for example. I mean this absolutely
> seriously. Anyway, investigate the latest UI researches, articles,
> anything. Achieve to have a really sophisticated UI at the system
> lavel.
>
> A very stressed, and very complete documentation, which describes all
> the
> Concepts that live in the system. What APIs are available for various
> tasks
> the programmer may otherwise try to implement herself, by not even
> thinking
That I already did at least once :^)
> of that the desired thing is available as a system concept. This
> documentation should be easily searchable, by keywords. Bring this
BeHAppy is a nice start =)
> documentation into attention very vigorously at the beginning of the
> programmer docs, so that no programmer can overlook it. Have it in the
Maybe a "Hey, would you like to browse the docs ?" Tip of the day, the first
time the IDE is run.
>
> form
> that any updates, new, adopted concepts can be merged into even local
> copies, and have a system of notifying the programmers about adoption
> of
> such new concepts, so that they don't overlook any of them just because
>
> it
> wasn't available last time they checked.
>
> Keep as much aspects (standards) of the system in central control as
> possible (inter-app protocols, standard attribute names and sets, app
> signatures, software qualification etc). This may look a bit
> totalitarious
> from the programmer point of view, but regarding that the whole system
Things like this
http://www.b500.com/get-what.php3
should be maintained by BeUnited... anyone hear me ?
>
> has
> to operate and cooperate inside one box, under the hands of one user at
>
> a
> time, I think this is much more important for the system for being
> harmonic
> and successful. Have a well working and fast system for proposing and
> accepting new standards, so that this doesn't hold back programmers.
> Always
> keep (backward-compatible) extensibility of standards and protocols in
>
> mind, because a fast system will always have more or less wrong
> decisions.
>
> Good, searchable documentation for the package system, so that the user
>
> can
> easily find out what is available for what she wants. Have brief,
> short,
> and longer description of software, screenshots where approriate (users
>
> tend to like to *see* what they will get, before trying).
I'd add have it available as a command line tool.
Some will argue it's old fashioned, I'd say good projects should be
redid from 0 by a single command
( see
http://www.joelonsoftware.com/articles/fog0000000043.html
), which isn't doable by PackageBuilder and BeIDE projects, if they need
to be included in larger things.
I heard Be included the whole thing from kernel compile to CD cover
into a whole thing. This is what we should aim to.
This is what I always try (!) to.
>
> Never force the user to recompile the kernel or any part of the system,
>
> if
> it's not the explicit intent of the user. Particularly not for adding
> drivers of any functionality. In essence, design the whole thing as if
Hehe :)
>
> it
> were a closed project, and it has to work without the user even having
>
> acces to what is needed to recompile anything. Be modular instead.
>
> Have a software update-like interface to the package system, where
> users
> can (but only if they want to) be notified about available new versions
>
> of
> their installed packages (or anything they are interested in). Make it
>
> possible to install/update desired software over the net or off CD or
> from
> local store by a single click. Have a way to automatically
> find/get/download/install available drivers for any hardware the system
>
> may
> find, and for which there is not a driver in the base system (of course
>
> with appropriate notification and confirmation). Update notification
> for
> this kind of software too.
>
> Make updating the whole system or parts of it trivial. Of course,
> preserving all the settings. Have the system itself in (below) a
> distinct
> location (e.g. /boot/beos), under which nothing will be changed in name
>
> of
> configuration. Have a location for local (machine-specific)
> configuartion
> parameters (maybe /boot/local, or /boot/local/config (to be more
the BeOS /etc -> /boot/beos/etc works for me.
> similar to
> user-specific settings)), and have the user's settings in her home
> directory, as currently is with BeOS.
>
> As a related topic, make an infrastructure (API) of scopeable settings,
>
> that any software can use. So that for various parameters, there can be
>
> install-time defaults, local, user-specific, document-specific,
> software-specific (e.g. for non given-software-introduced settings like
>
> language), session-specific values, each of which can refer to the
> value
> from the outer scope. All of these stuff should be trivially
> programmable,
> and where appropriate (e.g. not for session-specific settings) have
> persistence. As reasonable, the respective values should be stored
> under
> /boot/beos or /boot/apps/<DEFANGED_apps-dir> (in non-changeable form),
>
> in
> /boot/local/settings or /boot/local/config/settings, in
> $HOME/config/settings etc.
>
> Allow the user to make a profile of the system (mainly regarding to
> installed packages), and apply that profile to another system.
>
> Make migrating the system (e.g. from one HDD to another, from one
> machine
> to another) trivial. Though assuming the current layout of BeOS, or
> some
> better layout, maybe along the above ideas, this would not need any
> additional effort, as dragging/dropping the system would just do it.
>
> Don't nag the user. Carry notifications for example the way WinXP does,
>
> so
> that the user can see them, but she doesn't get interrupted by them.
> Have
> this be configurable (sound notifications, logging of such things,
> etc).
> Always allow the user to turn off notifications about various things
> (right
> on the panel that does the notification, like a check box "don't warn
> anymore"). For questions she has to answer, always give a possibility
> to
> avoid further answering the same question, by assuming the same answer
>
> always. Have choosable scopes for such default answers or disabled
> notifications (for a session (as defined by the runtime of a software
> or
> the system itself), for a given document, for the current user, for the
>
> given machine). Make this whole thing a system-concept, so that any
> software can use it. Promote the usage of this mechanism by
> programmers.
There is a lib on bebits that lets progs notify users the way
*they* decide. This would be nice as system default.
(though the BAlerts with a "Don't nag" button work for me)
>
> As an addition, let me point out an article, albeit whose subject is
> linux,
> yet it contains valuable points of view; you'll know which of these can
>
> apply to OpenBeOS. I just found it pointed to by OSNews today:
>
> http://www.linuxandmain.com/modules.php?name=News&file=article&sid=145
>
> Well, I already have my stomac hurting because of that much english
> typing,
> so I'll stop now. And I also reached the end of my list on the paper...
>
> I
> hope that if you are here, this means that you at least could fight
> your
> way through my tired and maybe hardly understandable lines. I even hope
>
> that you'll consider some of them, and maybe you'll argue about some.
>
Good overall review :)
François.
I'm off too, 0h30 :)
Other related posts:
