|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
|
Re: [PLUG] Continued newbie questions thread !-0
|
On Sat, Oct 06, 2001 at 03:01:05AM -0400, kaze wrote:
> <kaze>: OK, So there's no RH7.1 SP1, instead it's RH7.2, makes sense.
Well, going from, say, RH 7.1 to RH 7.2 is actually a more-or-less
full-blown distribution upgrade, although the changes tend to be less
sweeping than, say, MS-Windows 3.1 to 95 or NT4 to 2k. Think more like
98 to 98SE in scope.
>From what I know of Red Hat, they tend to release an x.y to x.(y+1)
every six months, where y <= 2. If they get to an x.2 release, then the
next one will be a (x+1).0 release. For example, they published 5.0-2,
6.0-2, and, most recently, 7.0 and 7.1 releases. And now, on their FTP
server, there is a 7.2 directory, although it's not yet publically
readable. And I bet their next release will be 8.0, in approximately
six months. ;)
In between the offical releases, though, they provide updated versions
of packages. This might be due to security holes, broken functionality,
or something similar. These would be more analogous to MS service packs
than the offical releases would be, although the important difference is
that it's not an all-or-nothing proposition. You can pick and choose
which updates you wish to install. For example, if an updated package
provides a later version that would break part of a custom
configuration, you don't have to install that package to get the
benefits from the other security fixes.
> <kaze>: Does BugTraq list both kernel bug/fixes and dist specific ones?
>From what I understand of it, yes. I'm not entirely sure since I don't
subscribe to it; instead, I'm subscribed to my distribution's (Debian's)
security mailing list, which tells me of bugs as fixes are made
available for them, and whether they are Debian-specific or not. The
convenient thing about Bugtraq is that it collects bug reports about
many different operating systems, including Microsoft operating systems,
proprietary Unices, and the major free *nix variants, all in one place
and on one mailing list.
More information:
http://www.securityfocus.com/popups/forums/bugtraq/intro.shtml
http://www.securityfocus.com/popups/forums/bugtraq/faq.shtml
> <kaze>: Wow, a lot of feedback there - still not sure I understand. Do
> people try out _all_ the desktops and window managers and then pick one they
> like? Is there a site which does a clean, easy to read, feature comparison
> btwn them all?
Generally, people tend to sample around until they find one they like
and are comfortable with. As for comparisons, I don't know of any
off-hand. They *do* exist, though. I asked Google about it (at
<http://www.google.com/search?q=window+manager+comparison>) and rather
high up on the list is
<http://wwwinfo.cern.ch/pdp/as/linux/gnome/gnome_kde/index.html>, which
has a basic rundown of the X architecture, discusses what window
managers and desktop environments are, looks at GNOME and KDE, and
throws in fvwm2 (which you can get for Linux) and CDE (which I believe
you can't) for comparison.
> <kaze>: Let me put it another way:
> <kaze>: (1) Say I do most everything CLI; then I launch a chess game like
> "startx /some_path/chess_game", and also do a "startx
> /some_path/mp3_player". Now I could flip btwn the CLI and the two X-Windows
> sessions with like F1, F2, and F3, but _not do anything_ btwn them.
<pedantic>Well, you could start the first one that way, but the second
application you tried to start would fail due to the X server
complaining that the "Display is already active". You'd need to append
a "-- :1.0" to the second one you start. *waves hand, dismisses
technical details*</pedantic> But yes, you're basically correct.
> <kaze>: (2) A desktop evironment then gives me icons, a GUI way to launch
> apps, virtual desktops, copy and paste btwn windows within the larger
> X-Window (of which there is only one)?
> <kaze>: (3) A Windows Manager tweaks those app windows more?
> <kaze>: Questions: Can you run a wm alone or only on top of a desktop? Do
> you need a wm with a good desktop?
A window manager provides widgets (I believe they're called "controls"
in MS-Windows terminology) such as title bars, window borders, and the
like. A desktop environment encompasses this functionality and also
provides other services, such as consistent drag-n-drop facilities.
I think that KDE has a separate program (called kwin) for window manager
services. (I don't know if it can be used separately from KDE.) Window
managers (what people usually mean when they use that term) in general
are run standalone. Desktop environments run with a window manager,
either its own (in the case of KDE) or with a separate program that does
window-manager duty (like GNOME).
> <kaze>: Guess I wanna do that then - any howtos? This is for unique hardware
> and/or getting specific stuff running within the kernel? Definitions of
> kernel vs. module? Why would you recompile each?
Reasons why you might choose to compile your own kernel, in no
particular order:
* The generic kernel provided by your distribution doesn't include
support for some of your hardware. Not too likely anymore, given
the typical distribution and hardware setup.
* The kernel you have doesn't include other functionality you want or
need, say, for making a firewall machine. Again, most distributions
include darn near everything.
* You want to save memory by excluding things you don't need. This
isn't a big issue today, considering how much RAM most people have.
* You want to slim the kernel down and possibly get better performance
by removing functionality you consider unnecessary. A good example
of this is if you use ReiserFS (a filesystem) and run RedHat. RedHat
enabled the extra debugging checks in their default kernel
configuration, and performance suffers because of it. (However, they
had some good reasons for doing it, from what I heard. Ask if you're
interested, but I'll omit for the sake of brevity.)
* Perhaps you want to apply a patch for some piece of functionality
that isn't in the mainstream kernel yet.
* You just want to have the last word on what goes on with that part of
your system.
* You want to upgrade to the latest and greatest, either because of
improved performance or extra functionality, or just because.
* Bragging rights. ;)
As far as documentation, there's the Kernel-HOWTO, available at
<http://www.linuxdoc.org/HOWTO/Kernel-HOWTO.html>. There's also
miscellaneous documentation available with the kernel itself. The
kernel source is often found at /usr/src/linux, and there is a README
file in that directory. There's also /usr/src/linux/Documentation,
which contains many other files.
The HOWTO has a good definition of a module, but I'll add to it by
saying that a module is somewhat like an MS-Windows device driver
running in Ring 0 (or "kernel space", in Unix parlance). These usually
come with the kernel and are compiled at the same time (the most notable
exception as of late being a module from NVIDIA, for their video
chipsets).
> <kaze>: I guess I'm not clear on the difference btwn reinstalling and
> upgrading Linux. If you make all the nice recommended partitions and you go
> from RH6.1 to RH7.1 is both a reinstall and an upgrade essentially removing
> the OS and then installing the new one there; is the only diff keeping the
> config files?
Yes, roughly. Backing up for a second, if you upgrade a single package
(on RedHat, these would be RPM files), the package manager will
uninstall the old version and install the new version. Now, if you
upgrade from RH6.1 to RH7.1, basically, that happens for every package
on the system.
> <kaze>: Another question based on the answers above is do you / can you
> change kernel releases independently or distribution releases? Could you
> have the 2.2.2 kernel running and alternately boot into two different
> distros?
Most definitely. One thing that you'd want to check if you're upgrading
from, say, a 2.2 kernel to a 2.4 kernel, is
/usr/src/linux/Documentation/Changes, which lists the minimum versions
needed of certain pieces of software on the system.
It certainly is possible for two different installations to share the
same kernel, although that gets a bit trickier than having each
distribution use its own kernel.
> Thanks, this stuff is awesome - I hope this post isn't annoyingly huge.
One suggestion for the future -- you'll probably get more and quicker
replies if you reply with your questions as they arise in the thread,
rather than saving everything for one big post such as this one. I'll
be honest, I found myself confused more than once by the style that you
used here, and I imagine I'm not the only one. It keeps the flow going
to reply to individual posts with your questions as they arise. More
conversational, it is. And smaller numbers of questions at a time are
easier to digest. I *did* appreciate the fact that you kept the line
wrap under 80 characters, though. :)
Anyway, I hope I haven't confused you overly much. ;) Feel free to keep
asking questions.
--
Bill Jonas * bill@billjonas.com * http://www.billjonas.com/
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." -- Benjamin Franklin
If encryption is outlawed, bayl bhgynjf jvyy unir raelcgvba.
______________________________________________________________________
Philadelphia Linux Users Group - http://www.phillylinux.org
Announcements-http://lists.phillylinux.org/mail/listinfo/plug-announce
General Discussion - http://lists.phillylinux.org/mail/listinfo/plug
|
|