Axel Dörfler wrote:
I see your point, but if not to protect data, then what other real purpose exists behind a desktop operating system with a multi user environment ? A multiuser system in the context you are in describing is essentially what a mainframe/terminal arrangement is. I don't really envision many Haiku users "being desktop focused" having multi user concurrent resource access being a very prominent usage scenario " though I could be wrong there".Sean Collins <SMC.Collins@xxxxxxxxxxx> wrote:Honestly this could easily be leveraged by the existing boot loader very simply. If the drive manager application had some more functionality. you could control each drives access from a simple run time loader that is used for multi boot now.Security is not really an aspect of multi-user capability, it's an aspect of the operating system itself; it doesn't help you at all when you lose your data because of some sort of malware, but the other user on the machine did not. What really helps you if you don't lose your data in the first place.In any case, a multi-boot solution to multi-user is a very poor and powerless implementation of multi-user. Multi-user also means to be able to have more than one concurrent user, not just to share one computer in a round robin fashion.Bye, Axel.
Having used several X-windows like clients across a network, I wouldn't really advocate for it unless the network was 100mb or better bi directional throughput and then it only really works well if data is being moved locally and not across a distance of more then a few miles. Most networks are great at RX speeds, not so good at TX speeds.
However I sometimes service customers who are upwards of 1000+ miles away via remote desktop , X and logmein services. these all suffer from the same issue, you always pay a penalty in loop time and its not a small penalty either. I have routinely seen lag times of 200+m sec on a short neighborhood hop inside of 50 miles and far in excess of 1sec on longer runs. Factor in wireless latency's and it gets even more horrific.Just controlling one of my machine across the building from another machine induces huge amounts of data transfer and machine slowdown. I recently watched a very good presentation on the issue with this. you have 2 viable options.Option one is to send all the viewable desktop/application data application across the network, option 2 is to transfer state&position data across the network. For option 2 to work however requires a great deal of similarity between both machines. for instance it would be very unlikely that this would be feasible in a haiku/linux access scenario, likely better in terms of haiku, but how do you deal with the mouse control ?
I can't even imagine the issue that would result in 2 keyboards and two monitors and 2 mouses on the same machine. IMHO it would make more sense to create a virtualized secondary OS instance versus trying to manage all the overhead of 2 users sharing the same hardware at the same time. even with the very preemptive design focus of haiku your still going to face allot of lag time if both users are accessing the drive and requesting large chunks of data simultaneously.
then there is the issue of security "which is the last rationalization standpoint of a multiuser system" and it doesn't really help there if the attacker is fairly talented.
for most of the x-windows like remote away from hope usage scenarios wouldn't it make more sense to just develop a client/host app similar to what logmein offers? your going to pay the penalty regardless of what you do and you depending on allot of compatibility to hope that you could avoid sending the on screen drawing info. something which may not be guaranteable if there are various versions of applications, screen resolutions, screen sizes etc ad nausea, simple machine to machine interoperability will become extremely problematic given the nature of FOSS software and the LAX treatment of compliance that seems to permeate the developer landscape.
I don't really plan to reply to this topic again as I felt I have said my piece here. Plus its dragging things further off topic. but from a engineering standpoint I can't find a reason to bolt on this widget because it doesn't fill a need. If its something developers want to work on for the fun of it sure, but would it be possible to keep a multiuser free tree as well ?
At the end I can only try to advocate from the user perspective and from my personal experiences. Obviously some opinions vary here, but to me this look suspiciously like feature envy and thats not always a good thing.
Regards Sean
