[openbeos] Fwd: OpenBeOS suggestions (quite long)

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.

Closely investigate existing operating systems, and their 
functionalities. 
Integrate any good ideas, parts, steal as much as you can, if you don't 
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. 
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.

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.

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 
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 
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.

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 
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 
and 
stable.

If possible, support drivers from other systems (mainly Windows) in 
binary 
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 
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 
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 
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.

Correct support for multiple users, with permissions, policies, all the 
relevant stuff. Support for parallel sessions, just like X or WinXP 
does.

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 
of that the desired thing is available as a system concept. This 
documentation should be easily searchable, by keywords. Bring this 
documentation into attention very vigorously at the beginning of the 
programmer docs, so that no programmer can overlook it. Have it in the 
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 
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).

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 
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 
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.

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.

nah, logging off
mortee

----------

-Bruno


--
Fortune Cookie Says:

Excellent day for drinking heavily.  Spike office water cooler.

Other related posts: