Make a limited XP account without losing settings?
in [Design]
|
From: Grant on 27 Jul 2010 05:56 On Mon, 26 Jul 2010 19:46:59 -0700, "Joel Koltner" <zapwireDASHgroups(a)yahoo.com> wrote: >"Grant" <omg(a)grrr.id.au> wrote in message >news:6kfs46p65dc6m9c9kq3b404mivsctfgd7a(a)4ax.com... >> This is a difference between Linux and windows. Under Linux, people >> compile their applications and have control over the app's runtime >> resource allocation. >> >> If you're running some commercial binary, you're not fully in control >> of your own system. > >I'd wager that for everyone who compiles a *nix application from source these >days, there are at least 99 who just installed a binary via Synaptic, RPMs, >Yum, or some other package manager... are they "not fully in control" of their >systems? No, they're trusting the source of said rpm... Grant.
From: Nobody on 27 Jul 2010 06:36 On Mon, 26 Jul 2010 14:03:24 -0700, Joerg wrote: > From a serious CAD user it can be expected that he or she understands > the basics of file management. In fact, gEDA was written completely > Linux-centric, ports to Windows have largely failed because some not so > compatible code must have been employed (in laymen's terms). Yet even > gEDA does what every CAD does, store libraries in program directories. > Meaning user libs and non-custom libs get splintered up. What's wrong > with allowing write access to the lib directory? Two things, mainly. First, your custom versions get trashed when the installation is updated. Second, what happens when two users both want to put different versions of the same custom library in that directory? I can only assume that you don't have much experience with multi-user systems. Otherwise, it should be obvious why you don't let users write to system directories. Oh, and /usr might be read-only during normal use (where read-only can mean anything from "mount ... -o ro /usr" to being a read-only NFS share to even having the write-protect jumper fitted to the drive). > I don't want an OS to tell me what I can't and cannot do, just like I > don't want a car to decide when to shift :-) The OS doesn't tell you what to do. The OS simply just ensures that the administrator can not only tell you what to do, but can even make it such that you cannot do otherwise.
From: Nobody on 27 Jul 2010 06:46 On Mon, 26 Jul 2010 16:23:37 -0700, Dave Platt wrote: > Voila. Now, when logged in under the proper user-ID, the user now has > the ability to alter files in the gEDA library/share directory. Other > users cannot, as they aren't members of the proper group. > > As you say, "On their own risk", but I see no reason why it would not > work. The main problem with group-writable directories are: 1. Concurrency. Fred decides to replace some file, and first deletes the original. Which is a nuisance for Joe who was just about to load that file. On Unix, multi-user doesn't just mean being able to stop the kids from trashing your documents when they use the PC later. Having a dozen people all logged into the same system (and running GUI applications on it) is very much a real-world use case. 2. People creating their own subdirectories, and not giving other members of the group write permission. Files aren't a problem; anyone with write permission on the directory can delete a file regardless of its permissions. But subdirectories cannot be deleted unless they're empty.
From: Anssi Saari on 27 Jul 2010 06:57 "Joel Koltner" <zapwireDASHgroups(a)yahoo.com> writes: > I'd wager that for everyone who compiles a *nix application from > source these days, there are at least 99 who just installed a binary > via Synaptic, RPMs, Yum, or some other package manager... are they > "not fully in control" of their systems? I suppose not, since they are limited to software available via the package manager. It's like the fast food of software, more interesting stuff needs more effort to get.
From: Nobody on 27 Jul 2010 06:59
On Mon, 26 Jul 2010 13:38:24 -0700, Joel Koltner wrote: > At least your average Windows user understands that "program files" > probably contains programs and "documents and settings" probably > contains application setting. /usr? Unix system resources? What's > that? /var? Variable? Huh? And what's this /etc directory think where > all the "odds and ends" seem to end up? The Unix file structure is based upon the way that filesystems are mounted at "mount points", rather than the DOS/Windows system of "drives". Frequently, /usr, /var, /tmp, and /usr/local are distinct filesystems. On a network, each server often mounts /usr from a central NFS fileserver. This will typically be read-only, so even someone with "root" access on a client system will be unable to modify it. Even on a stand-alone system, /usr may be a separate drive (on an internet-facing server, this drive may be read-only in case someone manages to hack the system). /var has to be writable; it typically contains log files, mail spools, etc. On a network, /var may be on the local disc, or a central NFS fileserver may have a separate export for each workstation's local /var. /tmp also has to be writable. Unlike /var, it doesn't have to be preserved across reboots, so it could even be a RAM disc. But it's more likely to be on a local disc, and may be erased upon reboot (to avoid it filling up with stale temporary files). /usr/local may also be a separate filesystem. The "local" refers to the fact that it's for use by the local administration; on a clean installation, it will be empty. It allows the IT department to install software without having to worry about it getting trashed if they upgrade or re-install the OS. /bin, /sbin and /lib typically contain low-level utilities (and their associated dynamic libraries), such as those which are needed to boot the system and enable networking, so that /usr can be mounted via NFS. Normal binaries and libraries are in /usr/bin, /usr/sbin and /usr/lib. |