but I don’t know any use-cases for it. Having separate PC for each user is fine, PC are cheap nowadays. Can someone tell real world use cases of multiuser GUI sessions?
Please don’t think that with a “rich 1st world country mindset”. One PC per person may not be affordable at all for some people with economic hardships. There are families in other countries in the world that barely have one computer for all the family. There, you would like to have one account for the mother and another for the father for things of their jobs, and another one(s) for their son(s) or daughter(s) to do homework. THere you have a use case.
Here’s another: you want to use another separate account for high privilege tasks, while leaving your main one you use daily as an unprivileged user for security and privacy reasons, specially with the dangers of the web. Or for maintenance reasons.
Also you would want to have more than one (unprivileged) account (besides the privileged one) in case you want to completely isolate files and mails of one account from another for whatever reason (you don’t want to mix things up…).
Or your company that uses Haiku wants to use the same computer with Joe in morning shift and Mary in afternoon shift.
One thing I think almost all OS’s get wrong is valuing system protection more than user data protection. It’s easy to reinstall the system, but losing my data is the worse thing that can happen on a PC. An ideal system would satisfy the following:
admin privileges for system configuration and installing system packages (ie. I dont want my child to corrupt printer settings or re partition a disk). A user should also be able to install user packages without requiring an admin. Therefore, packages must be classified as system and user.
separate home directories so that each user can have their own settings and file protection. This also allows for a sandbox user when you wish to test new apps (I dont want unauthorised apps from accessing some files).
I wonder if there’d be some way to leverage the packagefs system to maintain separately accessible disk space, set up at login. No separate user IDs like the ordinary multiple user system, everything still runs as “root”, but depending on who you identify yourself as at login, the other users’ files just aren’t there.
Take the case of a virus. If system files are infected, you may not able to save user files that are not. So, both are important. In our case packagefs take care of this part where most OS fail.
Actually, you can already install packages in your home if you put them in /boot/home/config/packages.
That would satisfy the user part.
I agree, that if you add several users, the shared area is necessary even if it is forgotten in most systems.
I would see in fact two areas,
in the first we let people decide about life of files, hoping it won’t end as a mess for things that are permanent i.e. family chores schedule :D,
in the second, smaller, we fix life of files to a duration to deterrminate and automatically wipe them after that. You know, for the “Give me the link, I’ll check later.” or “Send it to me, I’ll do asap.” kind of situation.
Maybe a plugin for FilWip could do the trick.
So, all you really need is a partition with two folders and the right permissions on files.
Finally, all we would need are separated home directories and a “guest” account.
You can always recover system and user data by using live USB. Creating Haiku live USB and reinstalling system takes less than minute on fast disk. Infecting packaged system files is also more difficult and easier to discover.
I use “data” folder in root of Haiku volume for this purpose.
Even if considering multiple GUI sessions, what should be done with Registrar? Currently Registrar do not allow to run more than one instance of single-launch application like Tracker or Deskbar. Should Registrar be adjusted to allow launch second instance if session is different or separate Registrar process should be running per each session. If second, how do discover Registrar port of current session? Currently connection to Registrar is established by global port name.
Having multiple GUI sessions may be also useful for testing purposes, because it allows to implement nested app_server that run in a window without libbe_test.so and separate test_app_server.
Yes, we’d have to solve all these issues. Probably it will have to be some sort of “hybrid” approach, given that launch_daemon has both a “root” process, and a “user” process, the same may need to be true of Registrar. And we can change the port discovery method to something else, as it’s private API.
Single-launch applications should obviously be per-user, there’s not much point to the flag otherwise, though.
Well, several system daemons probably use it too. What happens if an user tries to start their own media_server, for example? Or net_server?
Some of these we will want to duplicate per user, but some not. That is, if we allow multiple users logged in at the same time at all.
Maybe the “root” user should be global, and anything that’s run there would be “globally single launch”. While things run by an user would be more namespaced. Then, your users start to look more like FreeBSD jails and less like UNIX users.
Another question will be where to store session id? In environment variable? In kernel process info? In root Registrar team list? Session id is needed to decide on what desktop application should be displayed when started from Terminal.
Whatever started the Terminal (i.e. the user’s launch_daemon) should be the determining factor in that. An environment variable sounds OK to me; though maybe a “sessions API” makes some kind of sense…
I have an idea to introduce sessions in Registrar. Each session save own application list, clipboard etc. When session started, launch_daemon should start session tasks like Tracker and Deskbar. Registrar will store session id for each registered BApplication and be able to get session by team_id. New API will be introduced in BRoster for creating/destroying/enumerating sessions. Sessions are organized in a tree, user session can lookup root session applications by signature. app_server can be run in a window of another app_server in separate session without using libbe_test.
Terminal is a bit of problem because GUI process is started by bash that is non GUI process and it is not present in Registrar. Registrar will not know what session should be assigned.
Applications are started by bash, not Terminal. Terminal is just input-output system for command line programs. bash is not listed in Registrar. Session id in environment variables seems to be best solution for command line programs, Linux does similar thing.
I guess if the media_server is per session… the that means they can plug in a USB DAC for a second seat and change to that in the media preflet and be good to go? Would a second media_server default to no output if there is only one device? Or if they were connected remotely audio could automatically be routed to the remote session… or perhaps not say for instance someone had a Headless TuneTracker system they would probably not want local audio disabled since that is driving thier station and potentially also not want it rerouted if they already have a solution for monitoring audio otherwise?
A bit of background on how Terminal is handled in UNIX and why we got there and why this distinction between login and non-login shells and all that: https://www.linusakesson.net/programming/tty/
Whatever we decide to do, we have to consider how to integrate it with the UNIX way, especially if we want remote desktop to work relatively transparently (something like ssh -X would be nice, where you can essentially just use another computer’s app_server for display)
I think that X11 is a bad architecture, current remote app_server is much better because client is simple and more efficient implementation is possible. Running app_server client on different PC would be difficult to implement because app_server use shared memory. It will also be slow on connections with big latency.