OSNews

I think it's is going to be added in R2. R1 is designed to backwards compatible with the last release of BeOS, and introducing multi user support would doubtlessly break a lot of stuff.

Back in the days, PhosphorOS introduced basic multi user support. Also an (officially unreleased) ZETA 1.51 also supported multi-user support. I cannot recall experiencing incompatibilities with these implementations.

Note: PhosphorOS' implementation was not really secure: hitting control-alt-delete, killing the login task, and then clicking restart desktop gave you a desktop as the default 'baron' user. But this was experimental, and besides, PhosphorOS was a BeOS distro, so based on closed source software. (I think it was Dan0 based)

Was it ctri+alt+delete? That sounds like a Windows shortcut. BeOS never had an inbuilt task manager.

Dano (Dan0 doesn't exist, Dano0 does, Dano was the designation, Dano0 was part of the build name, as was Maui0 for R5 and Genki0 for R4.5) source was leaked. Yellow tab had it. This is all pretty clear.

Actually, the ALT-CTRL-DEL is a BIOS shortkey to reboot. However, most operating systems override this shortcut.

And about the build-in task manager: this is it: http://www.guidebookgallery.org/pics/gui/system/managers/tasks/beos...
When the Tracker process wasn't running, it would show an extra button "Restart Desktop", which was the PhosphurOS exploit to gain access without password.

In BeOS, ctrl+alt+delete would indeed bring up a modal window showing running teams (with the option to kill them), as well as the option to restart the desktop (aka Tracker) if it wasn't running.

Techinically the multiuser approach to Zeta 1.5 was full of holes. Just some simlinks and access checks.

Edited 2012-08-31 11:09 UTC

Security is a process.
Has no architecture.
Single user or maybe not,
difference makes none.

Could you please explain how a single user OS is a security nightmare these days?

Edited 2012-08-29 15:36 UTC

Because if any user is root, then any user can give any other user access to everything on the system without as much as an exploit. Completely by accident.

The multi-user concept is not the only way to provide security. An operating system is not inherently insecure because it does not provide multi-user support.

Here is an hypothetical operating system: It does not have a multi-user implementation. However, privileged operations can only be performed by passing security mechanisms like fingerprint or retina scans. Does that make it more insecure than a multi-user operating system?

Multi-user systems have their own issues. Think privilege escalation, confused deputy problem etc...

Computer security is a complex thing and there is no -one way- of dealing with it.

In a typical Ubuntu installation, you are the only user and can pass your credentials to the apps that need higher privileges.

A monouser OS with such behavior is equally secure than a multiuser OS.

In any Ubuntu installation, there are several users like root (yes, despite it not having its own login), dbus and nobody in addition to the end user's own account. A single user system, by definition, does not have that kind of privilege separation.

Oh I get it, it's "check your root privileges" all over again.

You don't need a multi-user scenario to prevent things like that, you need something like sudo/UAC, a special passworded command that allows you to do things which can affect the actual system.

It is the risks associated with running everything with the same privileges. And having no per user structure to keep files and preferences separate.

I am really looking forwards to the next Haiku alpha / beta but compared other operating systems there are important missing features.

Haiku is firmly focused on the end user desktop, I don't know about you but I've never seen the need to have separate accounts on our machines here at home.

doesn't Haiku already do this for the Hybrid? So, let's assume 64bit would be entirely Gcc4 (because, why wouldn't it?) does that mean 3 sets of libraries? Gcc2.x 32bit, gcc4.x 32bit, gcc4.x 64bit??? This seems quite an excessive amount of binaries! But I'm guessing it would be needed to support all 3 architectures.

Edit: I think my main point here is that Gcc2.x is necessary to support legacy BeOS closed source apps (the original goal of Haiku back when it was called Open BeOS) but gcc4 is required to support some of the newer stuff (hence hybrid) and that addind a new architecture (64bit) will double the required base libraries (if not more of the OS level executables)

Edited 2012-08-30 08:50 UTC

x86_64 is gcc4 only, gcc2 is for x86 only.



Yes, each application needs to be packaged into 3 binaries, one for x86 gcc2, one for x86 gcc4, and a third for x86_64.

Right now it is difficult enough to maintain separate x86 gcc2 and gcc4 packages, x86_64 will add a 3rd. This is a good opportunity for the package manager and IDEs to make this easier by automatically generating "Fat" binaries that run on all architectures.

However, this is a problem that must not be solved immediately because the official Haiku R1 release will be x86 gcc2h (32-bit). Official x86_64 support will come in R2.

Agreed. There is probably no viable port of GCC 2.95 for 64bit. If there is, I see absolutely zero reason to use it for 64bit support. Like I said "why would you?"