On Mon, 06 Dec 2004 00:42:48 -0500, Bryan J. Smith <b.j.smith@ieee.org> 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. I sent you the link to
> the Fedora Core 2 Release Notes. Here they are again:
> http://download.fedora.redhat.com/pub/fedora/linux/core/2/i386/os/RELEASE-NOTES-en.html
>
> And the ones for Fedora Core 1 and 3 as well:
> http://download.fedora.redhat.com/pub/fedora/linux/core/1/i386/os/RELEASE-NOTES.html
> http://download.fedora.redhat.com/pub/fedora/linux/core/3/i386/os/RELEASE-NOTES-en.html
>
> > . . . 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.
>
> > 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."
>
> Correct. Which is why Red Hat _overestimates_.
>
> > 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.
>
> Then not only go read the requirements of other distros, but try to
> install them on them.
>
> > Am I misunderstanding something here?
>
> At this point, I think you're just being argumentative.
>
> 1. I sent you the Release Notes off-list.
> 2. I've given you them again above.
> 3. I've stated that Red Hat distros typically install in far less than
> stated.
> 4. I'll now state that I've _never_ seen a case where if I had the
> minimum for a Red Hat distro and it didn't work because of insufficient
> memory
> 5. I have _plenty_ of times seen distros state "minimums" that _failed_
> to boot.
> 6. I've explained, _in_depth_, why Red Hat states its requirements.
>
> Now you seem to want to go on at length why this "requirement is so
> high." If I haven't made myself _perfectly_ clear:
>
> A. Red Hat has a _reason_ why it states its requirements as such
> B. If other distros don't, then that's their decision
> C. If users are "scared off" because of them, then I'm sure Red Hat
> would rather see 99.99% of them scared off than see more than 0.01%
> _fail_ to have enough
>
> So what's the big deal?
>
> > 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.
>
> Honest to God, just shoot me.
>
> If I admit Fedora has the most _bloated_ installer in the universe, will
> this suffice? God forbid I ask you to go read and then install Mandrake
> Linux or SuSE Linux and hold it up to the same "litmus test."
>
> No, that's right, we're here to justify why people don't run Fedora.
> Why? Why? Why? I'm certainly _not_ asking. ;->
>
> > 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.
>
> Win32 was well designed. .NET was as well.
> We didn't get Win32. We aren't getting .NET.
> We didn't get "Cario." We won't get "Longhorn."
>
> > Thank Linus we have other options (not to take the kernel originator's
> > name in vain, or anything).
>
> Thank Stallman. Thank Tiemann. Thank many.
>
> > 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.
>
> Win95B -> Win98SE are the same, core system, MS-DOS 7.1 / Windows 4.1.
>
> > 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.
>
> It's because they put unstable MS IE and other components in the mix.
>
> > 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.
>
> Please _drop_ the "kitchen sink" tag on Fedora.
> I _beg_ you _please_.
>
> > I thought that was (among other things) what Perl was for.
> > Heh.
>
> I don't write regular expressions when globs will do. ;->
>
> > 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.
>
> A good, single object model would be nice.
>
> > 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.
>
> And you're basing your "assumptions" on Fedora on your prior "trial" of
> Red Hat Linux?
>
> You'd be surprised how "lean" you can make Fedora "out-of-the-box." The
> team has done a "good sweep" of stupid dependencies in core portions
> starting with Fedora Core 1.
>
> But Red Hat _always_ asks for volunteers in helping find more.
>
> > For instance, the Debian installer, by default, requires far less RAM to
> > run than the Anaconda isntaller.
>
> Of course. Python/Newt isn't small.
>
> > 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"?
>
> > 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.
>
> APT-RPM upon introduction of Hawaii's Fedora Project really brought it
> "up-to-snuff." Many people swear by YUM, but I'm "familiar and
> comfortable" with APT -- largely because I learned it on Debian.
>
> In all honesty, I haven't had an "apt-get dist-upgrade" barf on me yet
> with Fedora! I have several times with Debian, but that was awhile ago,
> so it might not be fair to make a comparison since it was an older
> version.
>
> There are some source and package configuration options in APT-DPKG that
> haven't made it over to APT-RPM yet. But I think that's more of a DPKG
> v. RPM implmentation consideration. On the binary front, there's
> _nothing_ I can't do in APT-RPM that I can in APT-DPKG.
>
> > 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.
>
> Again, assumptions, assumptions, assumptions. ;->
>
> And you still haven't addressed the "kitchen sink" non-sense with either
> the installer or APT comparison. ;->
>
> Anytime you want to stop, feel free. ;->
>
> > 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.
>
> No, that's very true. APT/YUM repositories are still forthcoming for
> Fedora compared to Debian, and I don't expect Fedora will _ever_ offer
> as much.
>
> At the same time, all the "official" repositories and the "big 5" Fedora
> repositories haven't failed me yet. ;->
>
> > Oh? Are you saying that Fedora isn't better for kitchen sink
> > installations? Should we use Debian for that instead?
>
> 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.
>
> Especially Debian people versus "old" Red Hat Linux, Gentoo people
> versus any "packages" distro, etc...
>
> Again, choice in technology ... good.
> Choice in marketing ... er, um, it's just more marketing.
>
> > 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.
>
> I'm not even engaging you on your comments about Debian v. Fedora --
> other than to _correct_ any assumptions you have about Fedora based on
> just your "trial" of Red Hat Linux.
>
> Again, I ask you, why compare?
>
> > 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.
>
> The big questions are:
> 1. Is the front-to-backend reliable?
> 2. Are the repositories well aligned?
>
> Regarding #1 and Fedora, APT-RPM and YUM-RPM are fairly reliable. I
> prefer APT-RPM out of experience. I also don't like how YUM _always_
> updates the package list, whereas APT allows you to choose.
>
> Regarding #2 and Fedora, if you stick with the _official_ Fedora
> repositories, and select 3rd parties (e.g., Livna.ORG), you're find. If
> you start tapping FreshRPMS.NET and others, outside of maybe DAG's well
> maintained list, you're asking for trouble.
>
> And if you load Ximian, you'll have further issues with Fedora.
> But if you load Ximian on Debian, same deal, right?
>
> > 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.
>
> Because you _are_ making "assumptions" on Fedora.
> The "kitchen sink" non-sense has to end.
>
> > The rest of your email after this point is just pure, unmitigated
> > flamebait. Keep it to yourself.
>
> Anytime you want to stop making assumptions on Fedora, based on your
> prior "trials" of Red Hat Linux, we'll finally get somewhere.
>
>
>
> --
> Bryan J. Smith b.j.smith@ieee.org
> --------------------------------------------------------------------
> Subtotal Cost of Ownership (SCO) for Windows being less than Linux
> Total Cost of Ownership (TCO) assumes experts for the former, costly
> retraining for the latter, omitted "software assurance" costs in
> compatible desktop OS/apps for the former, no free/legacy reuse for
> latter, and no basic security, patch or downtime comparison at all.
>
> -----------------------------------------------------------------------
> 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.
>
I'm sorry for replying in this way under this thread, but you two
(Chad and Bryan) need to sit down, hash this out, and bury the NT
server (read: hatchet). Your incessant quibbling is DRIVING ME
CRAZY!!!!! I have come to the point of not reading posts that come
from either of you if they are more than a few lines long, and,
probably to my detriment, I am most likely missing some good
information. But I don't care because I cannont stand it! Please
stop.
Regards, Mav
-----------------------------------------------------------------------
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:35:39 EDT