On 5/16/19 9:05 PM, James Huddle wrote:
First of all, I must say that it is with genuine gratitude that I read your
responses!
Mov
Probably the same reason that you would say "...I might trigger other
people to say some rude things..." Often I feel that by merely stating
my opinion, here, I have opened the door to the proverbial darkroom.
Sorry! That, and a multi-user system has been the heart and cornerstone
of Unix & co. for MILLENNIA. That's fine. But my laptop is not a 1985 VAX.
I just think that pushing the idea forward of using the most popular
multiuser OS in history - in single-user mode - might meet with a little
friction.
I think this is where you are fatally confused.
2) Also, what is a "user"?
Good question. I am a user. Someone who has hacked into my multi-user
system as a different user is a user. And apparently, so is the cups
daemon?
You are correct on the surface and very misled as to the underlying concept.
In Unixish parlance,
"single user" = a system running with no resource restrictions
and all but the absolutely essential services and processes stopped
"multi user" = a system operating with normal division of privilege and
resources and all normal services available.
A system in "single user" state is normally only accessed by one
person, for a short time, to perform vital maintenance.
In that state a mistake can destroy the system - even to make
the system unrecoverable, a "brick"
A "user" in the context of [multiprocess] computing is a label for
a set of privileges [access, execute, etc.] & resources [storage, etc.]
It can be assigned to a person, a functionality, a condition, or many
other concepts. This restriction is vital for normal operation.
Why?
No program can be guaranteed to be perfect, and no person can be guaranteed
to never make a mistake. By restricting what can be done by a process or
a person in a given situation, the consequences of an error, a bug,
or a deliberate intrusion can be minimized.
In order to be useful, your laptop must perform many tasks invisibly and
concurrently. To promote reliable operation, each task [process, thread,
etc]
is assigned resources and privileges. We hope that the set assigned to
each is sufficient but does not allow destruction [overwriting, renaming,
etc.] of resources necessary to other tasks or exposure of secrets.
The CUPS daemon can delete files. Do you want it to be able to delete
ANY file? It is given an identity [set of resources and privileges] to
print and otherwise manage ONLY the files YOU give it.
You can delete files. Do you want to be able to accidentally delete ANY
file? Or do you want to be able to write-protect some of them?
A prime example of a "single user" system according to your definition
is MSDOS. No restrictions on anything. How reliable is/was it?
A server may ordinarily have no people sitting at a console connected
to the machine. It may have hundreds or thousands of different identities
requesting service, none of which should be able to affect any other.
So it, by custom parlance, has hundreds of users.
You probably don't want to run your laptop in Unixish "single user"
since most of the services (graphics, networking, Bluetooth, etc.)
are not available and a simple typing error can erase every file on
the system.
I hope this brings you to an understanding of what the convention
of "single user" and "multi user" mean and why running, for instance,
your laptop in "single user" mode would make it useless for you.
geoff steckel
