Make a limited XP account without losing settings?
in [Design]
|
From: Grant on 27 Jul 2010 07:10 On Tue, 27 Jul 2010 11:46:01 +0100, Nobody <nobody(a)nowhere.com> wrote: >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. > Except for /tmp wit hsticky bit ;) Grant.
From: Grant on 27 Jul 2010 07:15 On Tue, 27 Jul 2010 11:59:18 +0100, Nobody <nobody(a)nowhere.com> wrote: >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. Yes, you say that much clearer than I did, thanks :) Grant.
From: Joerg on 27 Jul 2010 12:11 Grant wrote: > On Mon, 26 Jul 2010 16:48:31 -0700, Joerg <invalid(a)invalid.invalid> wrote: > >> Grant wrote: >>> On Mon, 26 Jul 2010 14:03:24 -0700, Joerg <invalid(a)invalid.invalid> wrote: >>> >>>> Joel Koltner wrote: >>>>> "Grant" <omg(a)grrr.id.au> wrote in message >>> ... >>> >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. >>> Well that's plain stupid. >>> >> Care to explain why? > > Linux is multi-user, there's system wide rules need to be followed so > that the system can protect the users from themselves and other users. > > Even when there's only one user account, that user is isolated from > damaging the OS, simply by not allowing the user to write anywhere they > please ;) > > If you install and run a CAD program under your user area, you may > do anything you like, as it has no impact on the system (apart from > using resources). Stuff in your own area follows your rules. > Usually I do that. I have a directory "Programs", then sub-directories "Electric", "Editors", Utilities" and so on. Works fine. But occasionally programs come with a crippled installer and will only install under the Windows default "Program Files". > But I'm guessing you CAD app didn't come as source, therefore you > had no choice as to where it was compiled to run. and which directories > it uses for data files. > > This is a difference between Linux and windows. Under Linux, people > compile their applications and have control over the app's runtime > resource allocation. > I know, and that's another reason why I prefer Windows. I do analog and RF engineering. So I neither have the inclination nor the time to piece together this, that and the other thing, re-write stuff here and there, and then compile. Even Windows (usually) lets you decide where to put a program. Unless the program installer is written very restrictively which sometimes is the case with CAD. > If you're running some commercial binary, you're not fully in control > of your own system. > Question is: Do I want to be? > Under unix or linux there's three places you might add an application, > in the system area for all users, under /usr/local, again for all users, > or create a ~/bin and run the app from user area. Most Linux apps > distributed as source give you that choice, which is setup as a normal > part of compiling the app for your machine. > With a properly configured installer I can write it to just about anywhere on Windows. Unfortunately one must live with the installer the CAD company furnishes. > The reason for compiling apps is that a machine might be big or little > ended CPU, different system libraries, shell, *BSD, Linux or Solaris! I don't want to compile :-) >> >>>> Meaning user libs and non-custom libs get splintered up. What's wrong >>>> with allowing write access to the lib directory? >>> Question is, which lib directory. >>> >>> The proper place for writable system libraries is /var/lib/$appname :) >>> >>> For example, my Slackware-11 box has: >>> >>> grant(a)deltree:~$ ls /var/lib >>> arpd/ bsdgames/ elm/ logrotate/ misc/ mysql/ nfs/ rpm/ stunnel/ xdm/ xkb/ >>> >>> The program may create its own directory there and allow user access >>> and writing. It's difficult to find an exception to the standard >>> unix rules for basic layout (Sorry, I forget the exact name, >>> hierarchical file system or similar) that's been around for a >>> decade or more. >>> >>> Simple, no? >>> >> All I can say is that I asked in the gEDA group why I can't have the std >> libs and mine in one default place and the answer was pretty much, well, >> that I can't easily do that. And that I should just log in sudo. > > That's the windows solution, run as admin all the time. We don't do > that with Linux, it's bad for many reasons. And, by saying log in > sudo, sounds like that *ubuntu windows wannabe nonsense? Indicates > you don't compile the app (I guess it's commercial binary), thus have > no control over where it wants to keep things. This was said by hardcore Linux users. And yes, I am using Ubuntu. >> But it didn't matter anymore anyhow because gschem bungles refdeses upon >> auto-annotate. That's a big no-no in CAD. > > I'm still trying to pick a freebie circuit and PCB CAD, only single > sided and two-layer through hole plated required. The eagle size > limit (80x100mm) is a wee bit small. No budget for CAD 'cos only > hobby level that might grow, into something. And, I'm on low income, > retired, sorta. Well, since you know Linux well you might want to look into gEDA then. It's ok for digital stuff, just IMHO not for hardcore RF and analog. There is a good newsgroup for it: gmane.comp.cad.geda.user Another open source CAD that I think is even better is Kicad, which AFAIR comes in Windows and Linux installer versions. So you don't have to compile anything. >> >>> Users may have private libraries under /home/username/whatever >>>> 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 :-) >>> There are standards out there that define a framework for these things, >>> of course it is not rigid, as there's no Linux Incorporated controlling >>> this stuff. Each application author has a choice of what standards to >>> follow. A high end CAD system should follow the standard patterns for >>> flexible target OS. (I haven't used CAD for 17 years, no idea what's >>> what these days). >>> >> Well, I live with CAD for 24 years now :-) > > Last I worked in design, it was maybe 15-20% CAD for schematic and PCB, > then software to define the product, often variations on same hardware > for different product end applications. Then there was another product > 30-40k lines of assembler that I worked on, off and on for nine years > until the hardware was no longer produced. Started on cp/m box with 8" > floppies and ended on a win3 box with hard drive and 3.5" floppies... Wow, last time I saw 8" floppies was on a Racal Redac CAD system that ran on a VAX. But I couldn't get reasonable time-slots on it so drew my (large) schematic by hand. >> >>> It's not about deciding when to shift, more about expecting the shift >>> to have a standard H plus extras (reverse and fifth) pattern (or paddles, >>> or gated semi-auto) and be roughly in the same spot (or two), within >>> reach of the driver. >>> >>> You know, standards, so many to choose from ;) >>> >> I don't care which place they are in, or which side the steering wheel >> is on. As long as there is no automatic transmission. > > Fair enough :) My current car is auto, first time, I think I prefer > manuals, that annoying delay, waiting for the transmission to decide > it's time to shift... > Wait until the road ices up, that when the "fun" begins in an automatic :-) -- Regards, Joerg http://www.analogconsultants.com/ "gmail" domain blocked because of excessive spam. Use another domain or send PM.
From: Joerg on 27 Jul 2010 12:17 Nobody wrote: > 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 am the only user here. My wife doesn't do CAD and the Shepherd, the Rottie and the Labrador show no interest in computers at all. Unless it makes a cat sound :-) Trashing is a sign of very poor program design, a warning sign that lots of other things may be wrong with that CAD as well. Whenever I updated Cadsoft Eagle it never trashed anything. Golden rule in CAD: _Never_ alter a stock library. You must make your own. Mine always start with "j" and there are no others like that. > 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. > Well, that's where XP falls somewhat short of expectations. So does Linux, IMHO. NT4 was better in that respect. -- Regards, Joerg http://www.analogconsultants.com/ "gmail" domain blocked because of excessive spam. Use another domain or send PM.
From: Joel Koltner on 27 Jul 2010 13:36
Thanks Mr. Nobody -- while I do use Linux a bit here and there, I'm not experienced enough to know what the thinking was behind the way the file structure is built and I appreciate your explanation there. Today's "average Linux user" -- who's just installing, e.g., Ubuntu on a single machine that's typically only used by a few people at most -- is likely to be a little overwhelmed by all the "large scale" thinking that went into *NIX's design -- particularly when coming form a Windows background, which started as a single-user system and tends to kick and scream a bit when dragged into a multi-user scenario (particularly simultaneous multiple users via, e.g., Windows Terminal Server). I think I slightly prefer the "one big directory structure" approach of *NIX rather than a bunch of drive letters, although I can see pros and cons of each. It's rather annoying that under, e.g., GNOME, sure, you can use the file explorer to wander around a Samba-based network, but if you open up, say, \\MyServer\\SomeShare\foo.txt, when you then turn around and fire up OpenOffice Writer the actual Unix path is now something like ~/.gvfs/MyServer/SomeShare/foo.txt -- few applications will let you type in, e.g., smb://MyServer/SomeShare/foo.txt directly. Most annoying... :-( ---Joel |