[DMcCunney]

Originally Posted by Gregg Bell

Great explanations. Thanks.

You're welcome.

My analogy is with the automobile.

You can own and drive a car without needing to be a mechanic or understand the principles of operation of the four-stroke internal combustion engine.

We aren't there yet with computers, though things are better than they were. You sometimes do need to be a mechanic, and have a grasp of the principles of operation, to get the best out of what you use.

This is especially true if you venture beyond the packaged systems and try doing things like running Linux on older kit.

You know, they really work great as word processors as is. The LO is lightning fast. I don't do anything with them online.

And if they work great as dedicated word processors, that's a valid use. I do wonder how fast they are to boot, and how long LO takes to load, but if all is well once it's up, that's the critical part.

But where am I checking? Xubuntu has "Software Updater" in the applications menu, but that's the same thing as the 'software updates' it sends regularly.

You're checking Canonical's repositories for most stuff.

One complaint sometimes raised against Canonical and Ubuntu is that the repositories aren't at the current revision level for a lot of apps. There's a reason for that. Canonical is trying to play in the same space as Red Hat.

Red Hat makes its living selling support. You can get Red Hat Linux free. (The CentOS distribution is the open source version of Red Hat Enterprise Linux.) But if you decide you need support, there's an RPM you can apply to change the branding of CentOS to RHEL, and you call Red Hat and say "I'm running RHEL, and I'd like a support contract. What are my options?"

Canonical offers Ubuntu in supported versions, so they'll be fussy about stuff in their official repos being stable, debugged versions, because they may have to support it. This means bleeding edge code won't get added. If you need bleeding edge, well, that's what PPAs are for.

You can install other repositories in the list apt uses to look for updates in, and can install packages directly outside of that interface, but for the most part, what the official repos have is adequate.

If you think you're missing out on the latest and greatest, it's on you to find out what the latest and greatest is, and determine whether you need it enough to look farther afield than Ubuntu's repositories.

I misspoke earlier about the 95% stuff (trusting others and winging it by the seat of my pants, that is). In the very beginning, yes, because I really had very little other choice than to trust others because the whole Linux thing was so new to me. But as time has gone by I've learned a ton on my own. (I'm just finishing up "Ubuntu Unleashed." It's for 11.04. I got it at a used book sale, but it still had a lot of great stuff in it. (I just learned how to make "hard links.") I really enjoy learning about it.

The stuff about Ubuntu 11.04 is still valid in later versions.

Links are one of the best parts of *nix. I first learned to use them in AT&T Unix System V Release 2, back before Linux was a gleam in Linus Torvald's eye.

The key to understanding them is the nature of the file system. Under *nix, a directory entry doesn't point to a file. It points to a kernel maintained construct called an inode. The inode holds metadata about the file, like what ID owns it, what group the owner is part of, and what the file's permissions are. It also holds the creation and last modified dates, the file's size, and pointers to the first blocks on disk it occupies.

Because of this, you can have the same file appear in more than one directory, or appear under several different names in the same directory. The directory entries all point to the same inode. The Unix vi editor is an example. Vi is the full screen editor. Ex is a line editor. View is a read-only file viewer. All are links to the same underlying executable. It uses the name it is called by to determine what personality to use.

When you remove a file, you are removing a link to it. The actual underlying file doesn't go away till you remove the last link.

Hard links are neat, but have a limitation - they can't span file systems. Hard linked files must all be on the same file system.

To get around that, *nix uses symbolic links. A symbolic link is similar in concept to a Windows shortcut. It's a tiny file that points to the real one. Symlinks can span file systems. *nix follows the symlink and runs the program (or opens the file, if it's not a program.)

The quirk with a symlink is that they can be broken. Removing the symlink doesn't remove the file it points to. But if you remove the file it points to, the symlink is still there. Trying to execute it will produce an error, because what it points to no longer exists.

So yeah, for me, now, I really do try to figure things out on my own. Still I have to draw the line because I'm really a writer and I really should be writing most of the time, not learning how to make "hard links." LOL

That, and there are courtesy based limits on how much you want to impose on others, because they have things they should probably be doing instead, too. Learn as much as you can on your own first, then ask questions. People are far happier to help if you demonstrate you are trying to learn on your own.

But you're great for people like me when we get stuck and you're great at explaining stuff too. (Some very knowledgeable computer guys are not.)

I remember my confusion when I was first learning to deal with computers, and if I can dispel the confusion for others, I'll try to do so. The usual problem is determining what the other person I'm talking to already knows. I tend to err on the side of telling more than might be needed, simply to insure they'll have the context to understand the answer.
______
Dennis