Ralph Shumaker wrote:
DJA wrote:
Ralph Shumaker wrote:
DJA wrote:
But have you looked at what the corresponding GID actually is for a
given user created with the GUI tool? I prefer the UID and GID
(numerical values) to match.
what does
$ ls -lan /home/
show?
I'm not around that PC. But I did confirm that both the files owner and
group displayed correctly in each user's home directory. Just looking
on my own PC here, where I used the GUI tool to set up the users, the
first user "rafael" has matching UID and GID (500). The second user has
matching also (501). After that, I set up a special group (502). In
hindsight, I probably should have set it up with an unusually high GID.
But I didn't. Much, much later (very recently), I added a third user.
He got UID 502 and GID 503, but only because they each were the next in
line respectively.
04:47:55 $ ls -lan /home/
total 20
drwxr-xr-x 5 0 0 4096 Oct 27 09:58 .
drwxr-xr-x 24 1000 0 4096 Nov 12 20:42 ..
drwx------ 19 501 501 4096 Jan 13 2005 dick
drwx------ 21 502 503 4096 Nov 12 02:19 gvl
drwx------ 52 500 500 4096 Nov 15 04:35 rafael
04:48:05 $
Yes. gvl has a UID matching SpecialGroup's GID. Why wouldn't gvl have a
UID of 502 and a GID of 502? Because SpecialGroup already has a GID of
502. I would have set gvl's UID/GID to 504/504.
Which is why I don't like the GUI tool's automatic numbering scheme.
BTW, I don't ever remember having this problem with RH9 and earlier.
And what is the reasoning behind partitioning, anyway? Either I
never understood this, or I have just plain forgotten.
May I assume that when you an installation, you just let the installer
make partitioning decisions for you?
My reasoning? Stuff tends to fill all available space. That includes
hard drives. Every new incarnation of most any Linux distribution
seems to need more and more space on the root partition. I never throw
stuff away so my /home partition is never big enough [1].
And inevitably I make at least one partition way too big at the same
time I make another, more important, partition way too small. Of
course, were I a fortune teller, I could avoid such mistakes, but as
I'm not, LVM is the next best thing.
Nothing you stated here seems to argue against one big partition (aside
from swap). You answer a question I did not ask. You answered: "What
is your reasoning behind partition sizes?" I was not asking about the
reason for sizing the chunks, but rather the reason for chunking it in
the first place.
It's far easier to re-install when I can reformat all partition except
those I don't want to format. For a really simple setup, I have a
separate /home partition. When I want to upgrade my distro (e.g. FC1 ->
FC4), I tell the installer to format all partitions except /home. That
way I still have all my users' stuff - including a reference to their
respective UID/GID.
If I have some apps I installed to /usr/local, I can tell the installer
not to format /home and /usr/local.
If you have only one big partition then
o If your partition gets messed up bad, you lose *everything*[1].
o If your / (root) partition gets messed up bad, you lose
*everything*[1].
o When you do upgrades of your distro, you have to restore *all* data
and /home directories if you reformat [2].
o It's more difficult to reallocate space from over-allocated
directories to under-allocated directories (e.g. you just ran
out of space in /tmp because the latest distro upgrade needed
five more gigabytes in /usr ).
My partitioning scheme looks like this on one box:
[<user>@proteus /]$ df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda2 24770936 8403868 15108780 36% /
/dev/sda1 124427 53095 64908 45% /boot
none 777364 0 777364 0% /dev/shm
/dev/mapper/LVM_data1-lvm_home
35092160 16320072 16989512 49% /home
/dev/mapper/LVM_system-lvm_spare
1104624 34192 1014320 4% /spare
/dev/mapper/LVM_system-lvm_tmp
4128448 41428 3877308 2% /tmp
/dev/mapper/LVM_data1-lvm_usrlocal
35591840 15070752 18713116 45% /usr/local
/dev/mapper/LVM_system-lvm_var
1032088 477220 502440 49% /var
seven:/home 240362656 54266192 173886664 24%
/var/nfsmounts/sevenhome
[<user>@proteus /]$
Is there any advantage to using TB and FF over mozilla?
Personal taste I guess. I think both FF and TB are much more
extensible through the dozens of extensions available for each.
Extensions seem to work better than Plug-ins for Mozilla. And Mozilla
Mail is not, as far as I know, extensible at all.
Please cite examples. Extensible? I guess I assumed Extensible==Plugins.
Extensions are new to Firefox and Thunderbird. They are like plug-ins in
that they extend the capability of the app, but how they differ
technically from plug-ins I don't know.
Two of my favorite extensions to FF are SessionSaver and NoScript.
SessionSaver does just that, saves the state of FF, so that when it is
next run, it is in the exact state as when when you last used it. All
tabs, window positions, histories, script policies, etc. are restored. I
currently have 39 tabs open. If FF crashes, those will all be restored
when FF is run again.
NoScript uses policies to block or allow JavaScript. You can tell it to
allow some, all, or no scripts. You can temporarily run certain scripts
(i.e. for current session only). It works much like the Cookie Manager.
I don't currently have any extensions running in Thunderbird.
How do I change them to "faster sites"? How do I know what is "faster"?
Use different repositories. For example, mirrors.kernel.org and
livna.org.
I think you again answered a question I did not ask. You answered:
"How do I change them?"
My second answer was a "Here is a list of faster sites:".
How do you know they're faster? I guess you'll have to trust me.
[1] Well, not really, if you have a backup. But only having to back
/some/ stuff is still better than having to back up /all/ stuff.
Especially if you have a *lot* of stuff.
[2] Just because you backed up everything before the upgrade, doesn't
mean you should *have* to restore all of it afterwards.
--
Best Regards,
~DJA.
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
