[openbeos] Re: B_USER_DATA_DIRECTORY?

Wow, didn't original intend on writing something this long. You could skip all but my summary in the last paragraph.

Maybe I don't fully understand the file system that BeOS uses but it appears to just be a basic system that needs to be extended or changed. As it is, BeOS only nicely supports a single local user setup. There needs to be a folder for each user so they can each have their own desktop, BeOS menu, screen saver, etc. configurations. As far as I can tell this should be simple to do since BeOS already maps /boot/home/Desktop/ as the root (and then hides /boot/home/Desktop/ from the user, didn't you make a complaint about Unix hiding stuff). Actually, the GUI won't even let you access /boot/home/Desktop, while the CLI does. I don't want to mess up my system but there's a test I'd like to try. Tracker doesn't show a Desktop folder. So a user might at some point create a Desktop folder under home (possibly to start backing up files because they're going to format and reinstall). BeOS says the folder already exists, do you want to replace. A user might think, "what? there's no Desktop folder there." And click replace. Anyway, all that would need to be done is map /boot/users/CurrentUser/home/Desktop/ as the root. For backward compatibility, a symlink /boot/home/ could be added that links to /boot/users/CurrentUser/home/.

I do like the idea of creating a top level user directory. It could contain symlinks to each user directory on all mounted partition and drives. Hmm, people could keep their user directory on a usb memory stick. /system and /dev already exist so there's not much to say about those. Likewise, a top level apps directory could display a listing of apps for each mounted partition/drive. However, duplicate names would probably make this a bad idea. A top level home symlink would be nice. I have a symlink on my desktop to home. Isn't desktop supposed to be the same as root. Why does my home symlink and my other files show up under root from the GUI but not the CLI? Seems like BeOS is doing it's own share of hiding and providing two views of the file system.

Beyond this is security issues, which I think is a large part of that GE document (it just doesn't address it as security issues). System files and other critical files should definitely be protected. A GUI solution that involves holding shift if the user tries to modify a critical file isn't going to cut it. Currently, there's nothing in BeOS that'll keep a program from severely messing up the system. A user should never be logged in as administrator except when they need to be (which isn't very often).

Outside of protecting /boot/beos, /dev, and the user folders, I don't see any reason the restrict user from creating folders and files wherever they want (aside from the fact that they could create a rather disorganized clutter of files, but then they could also end up doing that in their user directory.

Remote logins is definitely another important issue to consider. The current setup is fine (except for security). I don't see a need for creating home directories for remote logins. The root folder could be created anywhere and symlinks can be used to link the remote user to resources at different locations on the computer. However, the server has to implement a system wide security to make remote access secure. A simpler alternative would be to not allow the user to create or copy symlinks. However, there's still the issue of forgetting you have a symlink to critical file or files you don't want shared. BeOS really needs a good security system implemented.

I don't see what your issue is with partition. They're conceptually the same as drives. You don't seem clear as to what you think should happen. It seems like you think all the top level folders of each partition/drive should be right under root. Partitions and drives show up as folders on the desktop. If this is implemented as I understand you, there would be quite as mess of folders on the desktop when partitions or drives or added. Of course, there would be a bigger issue of duplicate folder names.

I'm not really familiar with the terms virtual root and mounted root. They actually sound like two terms for the same thing. In any case, I don't see any references to root in the GE document. Which suggests to me the document implies no change to how root is handled.


Well, to summarize, we need separate user folders and a good security system implemented. Maybe, create a top level user folder. Don't hide /boot/home/Desktop (or anything for that matter). Everything else if good.



Later,
Scott MacMaster


----- Original Message ----- From: "Jonas Sundström" <jonas@xxxxxxxxxxx>
To: <openbeos@xxxxxxxxxxxxx>
Sent: Wednesday, September 29, 2004 5:01 PM
Subject: [openbeos] Re: B_USER_DATA_DIRECTORY?


"Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx> wrote:
...

> You should definitely look at http://glasselevator.sf.net. ;)

Okay, I've read it now, and I must disagree
with it almost in its entirety :)
... 
the RFC in this form is useless and will never
be accepted.


(for reference)
http://glasselevator.sourceforge.net/
cgi-bin//display_rfc.cgi?show=0003

Yeah, that proposal shows a lack of understanding
of the BeOS design and why it's a good thing.

Replacing the virtual root with a mounted root
is a step backwards.

The desktop is the GUI equivalent of the CLI root
known as "/". Tracker simply hides the root folders
that are mainly there to allow Unix/Posix apps
to run without too much re-writing.

The CLI shows your BeOS partition as /boot
just above "/", in the same way Tracker displays
your Boot volume directly on top of your desktop.
Same thing.

Perhaps in the future we won't need (to think about)
partitions, but in the present, and as long as we want
to dual-boot we have to live with partitions, and the
BeOS way of presenting partitions,
(in both the CLI as well as in the GUI env),
is more noobfriendly than the conglomeration
technique used by, for example, Linux.

(FWIW, the virtual root does not preclude the
mounting of additional partitions as subfolders
anywhere in the tree - as is common in the Unixes,
for when you need or want to give parts of the
fs tree separate quotas, access permissions,
I/O characteristics, etc.)

Unix also has the problem that you would want to
hide as much as possible from the user (in order to
be userfriendly), while still showing everything to
applications, without the applications themselves
revealing the smoke and mirrors. A common API
like Gnome or KDE could do this, but with Unix
desktop GUI APIs being so fragemented
you're bound to get a mixed user experience.

In BeOS, applications use the Open/Save -panels
of the BeOS API, in league with Tracker,
and indeed implemented in libtracker.so, so all
apps show the BeOS world the way Tracker does,
whereas ported Unix applications sometimes
trip up and display the root and places like /tmp,
which aren't meaningful to most users most of the time.

Anyway.

/Jonas Sundström.           www.kirilla.com






Other related posts: