Bryan J. Smith wrote:
> On Sun, 2004-12-05 at 19:16, Chad Perrin wrote:
>
>>1. Is this based on the memory requirements of the text-only install?
>>I ask only because this makes a difference to users that feel
>>uncomfortable with text-only installs, and thus might be an important
>>fact to address.
>
>
> At this point, I don't know if you're being honest or argumentative. I
> will assume honest (Read the "P.S." if you're interested in my comments
> on otherwise ;-).
Yes, that was an honest query. As you have repeatedly pointed out, I
don't know as much about Fedora as you do.
>
> But I will assume you are being honest. In reality, if you have
> available swap, if you can get the kernel up, you'd be surprised how
> little you can install it in! But I've typically only done it with
> text-only installs on systems with small memory footprints, because they
> are not exactly fast systems to begin with. Especially given the fact
> that so much is running from CD, and already slow to begin with. ;->
>
> Once I reboot, I _do_ let XFCE come up. I typically don't like to boot
> XFCE on anything less than 200MHz, 64MB of RAM. But on such a system, I
> have very few issues.
That's interesting information, but I'm afraid it doesn't answer my
question. Were the memory requirements you cited based on the graphical
or text install?
Here's another question while I'm at it: What, if that's the text
install, are the actual requirements of the graphical install (since
that, too, might be overstated)?
>
>
>>2. As with the text-only install, many users will not be prepared to
>>set up swap space for an installation. Based on that, it sounds like
>>one might find oneself dealing with a 96MB minimum for installing
>>Fedora. This strikes me as being rather high, particularly if this is
>>the text-only installation.
>
>
> Again, it's much, much lower. I have installed on 48MB of RAM with _no_
> swap pre-created. It will still vary from system to system though.
. . . unless someone has the hardware requirements that you cited as
requiring the higher resources. Yes? You yourself said that depending
on hardware the installation might require as much as 96MB. Thus, as I
tried to convey, it concerns me that 96MB seems like a rather high
resource requirement for a Linux install, particulary if it is the
text-based install.
When you say "Again, it's much, much lower," I get the impression that
what you actually mean (to be precise) is "in some (many?) cases, it CAN
BE much, much lower". That's quite different from "It is always much,
much lower."
So, again, 96MB seems like an awful lot of required RAM for a Linux
installation. The fact that some people might be required to have that
much RAM to successfuly install it concerns me somewhat.
Am I misunderstanding something here?
>
> As far as requirements, that's one of the side-effects of Red Hat's use
> of Python/Newt. It _does_ require an extra mount of memory to driven
> even .pyc (Python p-code bundled with the loader/executive). In a
> nutshell, if you have 64MB of RAM, you _shouldn't_ have an issues.
That's good to know. If I may be allowed a moment to nit-pick, though,
I "shouldn't" have been paid so little while I was in the Army, but I
was. "Shouldn't" and "won't" aren't strictly interchangeable. Thus, I
think my statements and questions further up about 96MB-required
installs are relevant.
>
>
>>3. I, for one, would surely be inclined to go with XFCE instead of
>>Gnome if installing Fedora on a machine. I was not aware, until you
>>mentioned it, that XFCE was receiving rougly equal support on Fedora
>>now. That's good news.
s/rougly/roughly/
>
>
> I'm curious if Red Hat hasn't been tapping the Cobind distribution for
> its ideas. First Cobind builds a 100% Fedora Core 1-based distro around
> XFCE, then Fedora Core 2 offers it stock. Now Cobind offers a YUMGUI
> and tools, and Seth Vidal talks about the new YUM-integrated
> installer/tools. I wonder if that YUMGUI is written in Python with the
> Newt widget set? [ I haven't had the time to research all this ]
If they're tapping Cobind for ideas, they're doing the Right Thing.
That's sorta the whole point of all this Open Source stuff (that, and
avoiding corporate market dominance politics). More power to 'em.
>
[snip]
>
> Win32 was nice, like .NET could have been too. But as always, NT became
> a "bastard" of non-Win32 code from "Chicago" (which became 95+), just
> like .NET is being trashed in NT today.
That much I was aware of, and I agree with you. Microsoft's development
strategy is very much a cobbled-together mess of half-baked technical
hybrids forced together to support market dominance strategy. As a
result, it's a disaster in terms of stability and security.
Thank Linus we have other options (not to take the kernel originator's
name in vain, or anything).
>
>>I actually rather liked NT4, in comparison with Win95,
>
>
> It was far better before. NT4 _lacked_ a lot of "Chicago" code, but it
> had enough to start destroying it. NT5.0/2000 tried to balance many
> things, and did a fair job. NT5.1/XP was the ultimate hack for
> "Chicago" compatibility, most of which was "unhacked" in SP2 --
> resulting in the current compatibility mess.
Again, I'm fully aware of this state of affairs, and am in complete
agreement with you.
>
>
>>and found it in many ways superior to Win98.
>
>
> Win95B (OSR2) and Win98 are MS-DOS 7.1. They are the _exact_same_ code,
> sans some GUI changes.
By the way, just for clarity's sake: When I refer to Win98, I tend to
refer to Win98SE. The first edition of Win98 was a mess that should
have been shot, dismembered, burned, and consigned to a watery grave.
Microsoft solved some major issues there, though only enough to make it
somewhat usable. It was still a nightmare, but now a manageable and
tolerable nightmare.
>
>
>>Win2k was a vast improvement over both Win98 and NT4,
>
>
> Yes, because NT5.0/2000 hacked in the remaining "Chicago" components
> that NT4 lacked. But it's _nothing_ like the original "Cario,"
> "consumer Win32," that was promised. Just like "Longhorn" is _nothing_
> like the original ".NET" platform as promised.
>
> History repeats itself 10 years later.
Of course. I certainly don't expect Microsoft to market a product that
was the result of primarily GOOD decisions any time soon. I think that,
of all the Windows OSes I've dealt with (including the shunned, loathed,
greatly avoided WinME, may it burn in hell), Win2k was by far the "least
bad" collection of decisions. As such, it is a "very good" OS, though
only really in comparison to other Windows versions (and, based on my
experience, in comparison to MacOS pre-X).
> Go back to NT3/4 and "C:\WINNT\PROFILES" v. the countless other
> "non-standard" file locations until they _finally_ standardized on "My
> Documents and Settings."
Err, no. I don't want to. Heh.
>
> Then you have the whole user v. system registry access issue. DOS
> doesn't care, NT does. That _still_ causes me grief when I support
> various products -- including some of Microsoft's own.
You an' me both, pal.
>
[snip]
>>As I already indicated, I personally dislike the XFCE interface.
>
>
> Remember, as I mentioned, XFCE is _three_ things:
> - Session Manager
> - File Manager (XFFM)
> - Window Manager (XFWM)
[snip]
>
Understood. Considering that I prefer to do without (most) session
manager functionality and particularly dislike all graphical file
managers (separate from file-browsing capability of applications) as
compared with file management from the command line, it should come as
no surprise that this bit of information about XFCE doesn't in any way
mitigate my distaste for XFWM's interface behavior. I really don't find
anything about XFCE to like, personally, other than the fact that it's
easier to configure (I think -- I haven't played with it too much) than
IceWM and is much more lightweight than GNOME.
>
>>I quite like that of IceWM's interface, however.
>
>
> And you _can_ use IceWM's window manager _with_ XFCE's session and file
> managers. Or you can use ROX Filer's session and file managers.
>
> ROX seems to work best with XFWM as a window manager. But IceWM is
> fairly close.
Considering my above statements about preferences, I suspect it should
be obvious at this point that this doesn't solve any of my issues with XFCE.
>
>
>>Aside from the fact that I just like the WindowMaker interface more,
>
>
> And there's nothing stopping you from using it with ROX Filer either
> (and many people _do_ run it with WindowMaker), or another session+file
> manager.
. . . aside from the fact that I don't want a file manager or session
manager. If I had my druthers, some of the behavior of WindowMaker that
overlaps with session manager functionality would actually be removed,
or would at least be easily removable through a graphical configuration
interface without sacrificing functionality that I do want.
>
> Or you don't have to run with _any_ session and/or file manager.
That's my choice.
>
>
>>the biggest problem I have with IceWM is the lack of a good, reasonably
>>comprehensive graphical configuration tool that is trivial to install.
>
>
> Exactly. It would be nice if a distro shipped with IceWM and a basic
> config tool -- possibly with an optional session+file manager set too
> (like ROX Filer).
AGREED! In spades! That would, all else being amenable (like, perhaps,
including strong apt support), probably instantly become my favorite
distro for converting Windows users.
>
>
>>While I'm normally inclined to prefer configuration files from the
>>command line over graphical configuration utilities, the reverse is true
>>when what is being configured is a GUI. Being able to interact with the
>>GUI to configure it seems by far the superior approach, to me. Maybe
>>that's just me, though.
>
>
> It's hard to beat the "full enchilada" of GNOME or KDE. That's why Red
> Hat's support of Afterstep, WindowManager, etc... essentially died after
> Red Hat Linux 5.2/6.0.
There are at least two fairly comprehensive, easily used graphical
configuration tools for WindowMaker. That's just one reason among many
that I like it so much. The issue of graphical configuration capability
for the GUI is admirably addressed, and in fact seems more intuitive to
me than even KDE's central GUI configuration tools.
>
[snip]
> In fact, if you like KDE, I recommend one stick with a Debian-based
> distro that caters to KDE -- like Xandros. I typically do _not_
> recommend Fedora for people who prefer KDE.
For people that would be better served by KDE than GNOME, and by a very
user-friendly kitchen sink distro than a lean "novices need not apply"
(though that's changed a great deal) like Debian, I typically recommend
either MEPIS or SuSE, depending on other needs. For a GNOME kitchen
sink distro, I tend to send 'em all to Fedora and RHEL first, or Progeny
Debian if Fedora/RHEL doesn't seem appropriate.
>
[snip]
>>I don't even like midnight commander.
>
>
> I occasionally use MC when I want to write a glob that bash won't
> recognize but MC will.
I thought that was (among other things) what Perl was for.
Heh.
> Being able to understand anything from the boot/operational scripts is
> where the CLI is key. Because you can understand any UNIX/Linux flavor.
>
> Otherwise, I don't get into the CLI v. GUI stuff.
I just rigorously apply the CLI Only rule when building dedicated
servers, and prefer a functional hybrid of CLI and GUI for "desktop"
systems. Both interfaces have their strengths, and I tend to feel that
ignoring them is like ignoring the importance of recognizing the
strengths of water and fire. Water will keep you hydrated, and fire
will keep you warm. Both are important, though sometimes being kept
warm isn't strictly necessary.
>>As such, all I need is a window manager. Others need more, I
recognize,
>>and I don't begrudge them that. In any case, this is part of the reason
>>I prefer WindowManager over Gnome or KDE.
>
Typo alert! I typed WindowManager when I meant WindowMaker.
>
> And then there's the session manager. The thing that shares DCOP,
> CORBA, .NET or other structures. That's the biggest complaint about the
> Linux desktop right now, there is no "single standard."
I consider that more of a strength than a weakness. Strong standards
are good, but trying to shoehorn everyone in the world into one standard
interface approach strikes me as a bad idea, reminiscent of the market
dominance tactics of Microsoft.
>>I prefer to get pretty much everything by use of the package manager
>>after installation. This is where that whole Lean Distro vs. Kitchen
>>Sink Distro decision comes into play. I prefer the lean distribution,
>>Debian, over the kitchen sink distribution, Fedora.
>
>
> Again, assumptions, assumptions, assumptions. _Stop_ talking about
> Fedora -- you have _no_ idea what it does _now_! ;->
>
> The first thing Fedora Core had was release a "lean" 90MB "minimal"
> install because APT/YUM was now the distribution center, not RHN. You
> _can_ install Fedora from CD #1 and then grab _everything_ via a
> package-manager front-end like APT or YUM. Red Hat even changed UP2DATE
> so it can yank from _any_ APT or YUM repository, in addition to the RHN
> (even in Enterprise Linux ;-).
That wasn't so much an assumption as sloppy phrasing. The usefulness of
the lean approach is affected by a number of factors other than simply
how much crap is installed. Yes, Fedora can be installed without extra
bloat, just as Debian can be installed WTIH extra bloat using tasksel
(or aptitude, if you're interested in torturing yourself). On the other
hand, the entire Debian setup is more oriented toward the lean approach.
For instance, the Debian installer, by default, requires far less RAM to
run than the Anaconda isntaller. In fact, the new Debian installer is
about as easy to use as (if not easier to use than) the Anaconda
installer (this estimation coming from my experience with Progeny
Debian, primarily, since other Anaconda experience of mine is quite out
of date). As another example of how Debian is more targeted at lean
installs is the native support for apt with an amazing breadth and depth
of package support for the apt utilities. As I recall, even you have
stated (in either this list or another to which we both belong) that
Debian's apt support is rather superior to Red Hat's, and you've
expressed some reservations about current YUM implementation as well.
So, in any case, I don't mean to suggest that you can't install a lean
system and build from there with Fedora, but Debian certainly seems a
bit better suited for it, just as Fedora seems to be quite better suited
to the task if you want a kitchen sink install.
>
[snip]
>
>>I also prefer the impressive apt support for Debian over any other
>>package management options in any other distributions I've touched.
>
>
> So do about 75% of Fedora users. ;->
>
> Whether you use DPKG or RPM as your "back-end," APT works great. Today,
> the capabilities of DPKG and RPM are largely the same, and built around
> LSB requirements. The difference then becomes the guidelines of the
> software packages themselves, which differ. But as far as the front-end
> is concerned, it's the _same_ -- regardless of DPKG or RPM.
>
> When APT was first ported to RPM by Connectiva circa 2001, it was pretty
> "raw." Some of the early, 3rd party repositories for Red Hat Linux had
> a half-baked APT-RPM implementation. FreshRPMS.NET used to really get
> me, both with limitations in their APT-RPM, as well as just blantant
> conflicts with stock Red Hat Linux packages.
>
> That changed at the University of Hawaii in late 2002. They built a
> very proper APT-RPM implementation, and aligned their RPM's very
> strictly against Red Hat Linux. The Fedora Project was born at
> Fedora.US.
>
> In Red Hat's constant, internal scrutinizing of its own product/project
> identity crisis that had been plaguing it since it introduced Enteprise
> Linux to answer SuSE's market sway, someone found the Fedora Project in
> 2003. I was among the many, many Red Hat Linux users who did. And then
> it became clear to Red Hat by mid-2003 what they needed to do.
>
> Who to merge with became obvious. ;->
>
> The original Fedora Project is now Fedora Extras (still Fedora.US).
> Their _preferred_ distribution is via APT, and for good reason. But in
> reality, both APT and YUM are supported. "Legally questionable"
> packages have been moved from Fedora.US to Livna.ORG, still largely
> maintained by the same people behind Fedora Extras, but not an official
> repository.
>
> Red Hat seems to be dedicated to YUM. But everytime a new YUM
> capability is introduced, it's adopted with little effort in APT-RPM.
> Many Fortune 100 organizations use APT-RPM internally for configuration
> management of their Fedora/RHEL platforms. It's an ideal implementation
> for a "front-end" distribution system to _any_ back-end, be it DPKG or
> RPM.
>
> The farce that APT is somehow "native" to "only Debian" is completely
> untrue. It was just developed for DPKG first, but it works just as well
> for RPM.
As I understand it, there is still a greater degree of apt package
support for Debian than for Fedora, though -- if only because the Debian
apt archives have been around longer and had longer to mature. Please
correct me if I'm wrong.
>
>
>>If you prefer a kitchen sink distro, Fedora is clearly a far better
>>choice than straight Debian (though Progeny Debian has created one of
>>several available Debian variants that take a more kitchen sink
>>approach).
>
>
> Again, assumptions, assumptions, assumptions.
Oh? Are you saying that Fedora isn't better for kitchen sink
installations? Should we use Debian for that instead?
>
>
>>Clearly, the people with whom the proposed YUM approach of
>>later Fedora versions is a "sticking point" are not people that are
>>likely to be seduced by Debian's approach to things, and I'm glad they
>>have a distribution like Fedora to satisfy their needs.
>
>
> Again, assumptions, assumptions, assumptions.
Actually, I think YOU are the one making an assumption here.
Specifically, I think you're assuming a different meaning for that
statement than I intended.
In essence, what I understand is that YUM is meant as an approach to
package management vaguely analogous to the apt approach. Clearly,
there must be differences, but from what I understand they can be used
in much the same way. I only meant to suggest that those who have a
problem with that approach to package management that YUM and apt have
in common will not likely be as interested in Debian.
>
>
>>There. That's my outsider's view of the Fedora way of doing things.
>
>
> Again, assumptions, assumptions, assumptions.
Okay, now you're just pissing me off. Do NOT pick another fight with
me. I'll cram your sanctimonious repetitions up your butt where they
belong for you.
Be respectful and polite, and I'll do the same. Things were going so
well until you decided to start being condescending to me.
The rest of your email after this point is just pure, unmitigated
flamebait. Keep it to yourself.
-- Chad ----------------------------------------------------------------------- This list is provided as an unmoderated internet service by Networked Knowledge Systems (NKS). Views and opinions expressed in messages posted are those of the author and do not necessarily reflect the official policy or position of NKS or any of its employees.
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 20:21:41 EDT