NOTE: Some content was removed and generally ignored due to the
flammability of it.
Bryan J. Smith wrote:
> On Sun, 2004-12-05 at 23:57, Chad Perrin wrote:
>
>>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)?
>
>
> I _already_ answered this in an off-list post.
It must have been in an email wherein you referred to me as a hypocrite
and were otherwise unpleasant. I probably glossed over links, in that
case. I see now that you were referring to the text-based install.
>
>>. . . 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.
>
>
> I've had other distros barf on far more.
>
> Given the fact that Anaconda is Python/Newt, it's going to take more
> than _some_ other distro installers. But it also takes less than many.
>
> I think you're holding Red Hat up against a standard that you don't seem
> to want to hold others against? That's what bothers me.
I'm only comparing it with Debian and Windows installers. The
text-based install compares favorably with the recent Windows
installers, but not by as much as I'd like, when run without swap space
enabled. It compares unfavorably with the Debian installer -- actually
requiring more RAM (when run without swap space) for the minimal
installer than the larger-footprint version of a Debian install.
Fedora may be better, by far even, than some distributions in this
regard. As a habitual user of Debian, however, the larger numbers for
Fedora installs seem . . . well, large. That's all. Of course, in the
case of Anaconda, that's to be expected from running a scripts-based
fully graphical installer, and a fully graphical installer is of course
a very useful tool in helping out the new-to-Linux users of the world.
>
[a lot snipped for lack of use to the list at large]
> So what's the big deal?
There is no big deal. I'm afraid you've just read a "big deal" into my
words. When I tried to explain my concerns, you took that as though it
were some kind of indictment of Fedora. That's not what I intended at all.
>
[snip]
>>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.
>
>
> Actually, their strategy is _very_sound_. The problem is that they
> don't tend to actually _implement_ that strategy.
I spoke of implemented strategy, not initial strategy.
>
>>Thank Linus we have other options (not to take the kernel originator's
>>name in vain, or anything).
>
>
> Thank Stallman. Thank Tiemann. Thank many.
Of course. I was just making a (small) joke. It's not as amusing with
that many names in it, though.
>
[snip]
> Please _drop_ the "kitchen sink" tag on Fedora.
> I _beg_ you _please_.
No. It's descriptive, and it's not the pejorative you've decided to
assume it is. If you insist on misconstruing it, even after I've
explained at great length what is actually meant, that's your problem --
not mine.
>
[snip]
>
>>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).
>
>
> But I'm still scratching my head on how this has _anything_ to do with
> your phrase "kitching sink"?
Only the fact that a lesser resource requirement makes it easy to effect
a lean installation on a machine with limited resources.
>
[snip]
> I'm saying I don't think this "kitchen sink" phrase is applicable to
> _anything_. I find it one of those intangible "versus" comments that
> people like to make.
That, I'm afraid, is based on your snap-judgments of what you think I
mean by "kitchen sink".
>
[snip]
>>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.
>
>
> Does _anyone_ have a "problem" with distributed download front-ends?
> I don't care if its RHN/UP2DATE, Mandrake/URPMS (is it?), SuSE/YaST,
> APT/YUM, UBERDLPORNOMGR, etc... Every distro today has them.
Yes. Some people do. Ask a Gentoo user for the extreme example.
I thought Mandrake's was URPMI, not URPMS, though I admit a degree of
ignorance there.
>
> The big questions are:
> 1. Is the front-to-backend reliable?
> 2. Are the repositories well aligned?
3. Does the user prefer a different type of tool (such as YaST2 or
Aptitude, for instance)? I, for one, don't. Some others do.
>
[snip]
> And if you load Ximian, you'll have further issues with Fedora.
> But if you load Ximian on Debian, same deal, right?
I wouldn't know, actually. I haven't tried Ximian on Debian.
[snip]
-- 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 - 18:33:15 EDT