ZETA's Multiuser Previewed
Linked by Thom Holwerda on Thu 14th Sep 2006 16:05 UTC, submitted by sogabe
Zeta IsComputerOn.com takes a first look at the ZETA's multiuser capabilities currently under development. This is "a first beta, usable but still incomplete and with bugs" reports ICO. The article uses screenshots to show what multiuser looks like in ZETA, and describes how to create user accounts, as well as some of the existing problems with the implementation which, hopefully, will be fixed before release. As Magnussoft told us a few days ago, multiuser support will be available as an update to the upcoming ZETA 1.21, but no release date is mentioned.
E-mail Print r 3   26 Comment(s) http://osne.ws/c7y
Thread beginning with comment 162386
To read all comments associated with this story, please click here.
MUS implementations on BeOS
by looncraz on Thu 14th Sep 2006 18:10 UTC
looncraz
Member since:
2005-07-24

As the creator of three full ground-up MUS systems for BeOS, I can tell yellowTAB right here how to rid their file-copy time.

On PhOS, my BeOS derivitive, the last version of MUS would create a user in about 2 seconds.. just as soon as you typed in and accepted a user name, while you were being prompted to choose a password for the newely created account.

yellowTAB, take note... All I did to make 2 seconds is create a blank-user with basic startup instructions to do a first-time-user-run initialization on log-in. Meaning, don't set the thing up yet, the settings you want to keep system-wide need to be linked (when linking is compatible) or copied and kept in sync, or simply moved, if possible.

My last released MUS did not change the USER ID or any priveleges, however my upcoming LoonTracker (OpenTracker replacement, ground-up rewrite, 45% complete to stage 1) will have integrated support and respect for user priveleges, and has the ability to lock files or folders so that user a can read it, but not write it, user b can do NOTHING with it at all, even see it, user c can read it, system can do anything.

Another important inclusion for a solid MUS setup would be an on-access-attempt method of file cloning for certain important files. That is, when a file, or that file's node, has been opened, a copy is made of the old version, changes are allowed to be made while the old version is compressed in memory, if size allows, and if the changes made are out of line with system expectations (say the file should contain text data, but now is binary, or the inverse) the system would alert the user as to the unrecognized/improper modifications to a protected file, and the user could choose to accept those changes, deny them entirely, or TRY THEM, meaning we make an archival of the buffered file.

Of course, that last part is not entirely needed, should one simply go deeper into the code..say.. the kernel, and make some changes. A possible advantage yellowTAB may have. If so, Multi User should be pretty solid if done correctly.

Oh well, if I like the screens of the MU-including Zeta, I may just pick up a copy and give it a fresh Desktop option :-)

--The loon

Reply Score: 1

Ronald Vos Member since:
2005-07-06

looncraz: just curious, but with your tracker rewrite, which seems aimed at implementing true user seperation in vintage BeOS, would dropping to shell not negate it?

Reply Parent Score: 1