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 ;-).
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.
> 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.
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.
> 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.
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 ]
Users have _always_ had a _lot_ of say in Red Hat Linux. But the
"suits" tended to make the "final decisions." Now that has _not_
changed with Fedora Core, even though there is a "Fedora Steering
Committee" (Meritocracy based like the Apache Foundation), the "suits"
still have the final say. But because Fedora Core is no longer a
"product," the suits view it _very_differently_.
The result is that Fedora Core still gets _all_ of the same "developer
attention" as it still makes up Red Hat Enterprise Linux, just like Red
Hat Linux before it. But because it isn't a "product," it doesn't
"compete" with Red Hat Enterprise Linux anymore, or try to "complement"
it in certain ways. The result is that Fedora Core is "allowed" to
follow FHS, LSB, good practices, etc... with far less "red tape" than
before.
> I have extensive (much of it professional) experience with 3.11, 95,
> NT4, Win2k, and WinXP. I've never even laid eyes on an NT3.5 machine,
> to my knowledge.
I was an original NT 3.1 beta tester at the largest installed base of
the first native NT application. My boss was the international
president of the user group of the primary OEM advocate of NT. I saw a
lot.
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.
> 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.
> 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.
> 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.
> in my experience, though there were some niggling little issues that came
> up (the most annoying being the replacement of "network neighborhood"
> with "my network places", which foreshadowed the much-loathed
> Fisher-Price widget set that debuted with WinXP).
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."
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.
> In my own experience, Win2k SP2 is the best OS extant from Redmond.
Of the post-NT3.5[0] release, yes, it finally merged in the "we do it
our way" codebase of "Chicago" into the NT lineage. "Chicago" code
accounts for about 99.9% of the desktop holes in NT today.
> It's the only one I will consider using personally, and that only for
> software that will not run on Linux, and because I need to have a
> Windows workstation running for work-related purposes.
And it's a good choice.
> In any case, as I indicated, I can't really comment on NT3.5, I'm
> afraid. I'll take your word for it, as regards the problems inherent in
> Microsoft's move from 3.5 to 4.0.
It was due to Gates giving "Chicago" the "go ahead" in 1994. Just about
everyone at Microsoft working on NT, as well as most OEMs, including the
company that wrote much of NT and knew it better than Microsoft,
Digital, wanted to give Gates the bird. "Chicago" was _killed_ Win32 as
it was originally designed.
Just like today's "bastard" of Win32 is killing any chance of .NET in
the Windows platform.
> 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)
Just like GNOME is _three_ things:
- Session Manager
- File Manager (Nautilus)
- Window Manager (Metacity)
And KDE is also _three_ things:
- Session Manager
- File Manager (Konqueror)
- Window Manager (KWM)
> 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.
> 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.
Or you don't have to run with _any_ session and/or file manager.
> 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).
> 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.
With Fedora Core 2, XFCE is now the 3rd "full enchilada" they now
support. Maybe not to the full extent of GNOME, but that's for the same
reasons as KDE, Red Hat just has far more GNOME gurus than KDE ones.
But at least XFCE is GTK+-based, and is GNOME-aware. Plus with people
like Cox liking it, Red Hat seems to pay attention enough. ;->
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.
> I find that, outside of interacting with a given application, I don't
> like graphical file managers at all (as contrasted with file management
> the old fashioned way, from the shell).
So you don't really care for a file manager. Again, it's optional.
> 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 realize I may (or may not) be in a minority in this, but I
> went from being essentially unable to comprehend how someone would
> prefer the command line (as a Windows user) to preferring it for many
> operations (as a Linux user).
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.
> 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.
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 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 ;-).
Fedora Core 1 took 8 months, instead of the regular track record of
almost 6 months (+/- 2 weeks) since Red Hat Linux 4.0, because they
_combed_ through the endless dependency BS. Fedora Core has adopted
stricter guidelines on dependencies, various LSB approaches like
"alternatives" and "groups" (that Debian users have gloated about for
years), etc...
You are basing 100% of your statements on *0* familiarity with how
Fedora can and does work. I can only assume you believe that Fedora
Core works on the same model that Red Hat Linux did prior.
> 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.
> 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.
> 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.
> There. That's my outsider's view of the Fedora way of doing things.
Again, assumptions, assumptions, assumptions.
Any chance you might learn a bit about it before you speak again? I
know that's not happening with 90% of the Fedora commentary out there
because ...
"the fact that some of us just aren't interested in trying Fedora out
for ourselves any time soon."
But you won't see me responding with comments like:
"Shut the hell up and stop being pissy just because not
everybody in the world is glued to your ass."
When you won't stop talking about Fedora even though you don't use it.
And that's the #1 reason why I said you need to _look_ at _yourself_
when you get upset with me. Because you might just see where _I'm_
coming from for once. ;->
-- Bryan
<Flammatory>
P.S. Select Debian users tend to "pick" on Mandrake, Red Hat, SuSE,
Xandros, etc... for the requirements of the GUI installer method. In
fact, I think it's nice to note that Red Hat _does_ give you an option
of either way, whereas other distros either don't, or make it
difficult/limiting (but so few seem to note that ;-). Red Hat's
development of its tools using Python/Newt (Newt being able to target
either slang or GTK+, console or X). Even Debian maintainers seem to
recognize this, all the way to the founder, Ian Murdock, who has even
adopted Red Hat's Anaconda installer in his Progeny's Componentized
Linux.
The Progeny developers _are_ on the Fedora lists. I've corresponded
with them off-list. It's funny, being a Debian maintainer from
2001-2003, I _never_ corresponded with them at all. And I've been
really no more active on the Fedora developer lists than I was on the
Debian lists (because I never released any Debian packages, only got
involved with the kernel building structure and how our WLAN components
might fit in). But they are a great group! And they are in a far
better position to comment about Fedora -- because they are actually
_involved_!
</Flammatory>
-- 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.
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 20:20:05 EDT