Why do people switch to Linux 13490

On Monday 31 October 2005 10:14, T.G. Reaper stood up and spoke the following words to the mbuttes incomp.os.linux.advocacy...:

The above was not intended as criticism towards you. It was intended as advice. ;-)

I remember from when I ran NT that running a defragmentation session - which required several pbuttes - not only took a long time but also used up about 90% of my CPU cycles. It also seemed to come to a halt once the screensaver kicks in, so you need to disable the screensaver before starting the defragmentation.

Hardly userfriendly, wouldn't you say?

Exactly... But not so far above...

Ehm... How will you implement an ACL if your filesystem does not support ACL's? How exactly do you run a GNU-Linux application on Windows if you don't have something likecygwininstalled?

ACL's are ACL's. Please don't turn them into something else.

Contradiction in terms. I'm sure you can see that?

There may be another security system intact, but the ACL's aren't.

And they are. As different as Mac OS X is from UNIX - and no, I'm not saying this to trollfeed Oxford. He's in mykillfileanyway.

Yes, it is. You are confusing certain restrictions in respect to what an unprivileged user can or cannot do when Windows *is* installed on avfatwith the concept of ACL's.

Your comment is flawed, as it's you who are confusing things, not me.

They may be two separate subsystems, but there is only one Windows-supported filesystem that uses ACL's. vfatdoes not use ACL's and therefore a Windows installation on avfatdoes not feature ACL's.

The second subsystem you speak of and which according to you would be present - and I'm not saying that it isn't - does not make use of ACL's - for the simple reason that ACL's rely on the underlying filesystem - *and* is not mentioned in the list you pasted above.

Such a security model would not be any better - andmayeven be more lax - than on a GNU-Linux system with all permissions set to read, write and execute for each and every directory and file. Yet, as mentioned above, such a security system is not mentioned in your list.

I'm not the one who is confused about them, *you* are!

Because this security precaution is not mentioned in your comparative list with VMS, and even if it would be, the only difference between a regular user and an Administrator would be that the latter has the power to do things like power down the machine.

True, but then again GNU-Linux - as said by another poster in this thread - has always relied on the user-group-others permission masks - which may not be as fine-grained as ACL's but which surely are a *very* efficient security layout - and on its UID checking.

Two inconsistencies here:

(1) You are butterting that the security subsystem is based on ACL's, and thus following the logic, when ACL's are absent, the security system would fail.

(2) You are saying that ACL's are used in a filesystem that does not support ACL's. So where do you intend to store the ACL's then, if the filesystem doesn't support them?

My definition of a multi-user system is that it is a system which allows multiple users to log in and simultaneously make use of the CPU and the system's memory for launching processes - as opposed to a file- and printserver - and that these users can do so from multiple remote terminals, either via serial consoles or via terminal emulators on other workstations or so-called thin clients over the network - or in other words: they don't need to be at the local console.

In this regard, also please take notice of the fact that a thin client for a Windows Terminal Server is not the same thing as a thin client for a UNIX system.

According to my information, a thin client for Windows terminal server does have some basic operating system functionality in hardware - I was told it's a version of Windows CE - while a thin client for UNIX systems only has the electronics needed to maintain a network connection and to transfer keyboard information to and monitor output from the main computer.

P.S. - Technical description of the concept "local console": On microcomputer systems, the local console comprises of the local video connector, the local keyboard connector and the local mouse connector.

On many minicomputer systems, the local console is a dedicated serial connector with a so-called dumb terminal attached to it - a device resembling a PC in appearance but without a CPU or memory - but separate from other serial connectors with dumb terminals on them. As such, it was only possible to gain root access on the local console, while the local console in turn did allow for unprivileged user logins.

-- With kind regards,

*Aragorn* (Registered GNU-Linux user #223157)