Hello,
Actually, in response to some stuff below :-
- In RedHat 6.1 if you select "server install" The latest version of RedHat
lets you assign your partition. Which RedHat 6.0 and RedHat 5.2 doesn't
- It adds simple system administration tools like the "C Compiler" that if you
do a mannual install on RH 5.2 and 6.0 it wouldn't give you a C Compiler.
(learnt that the hard way) which is a improvement.
- And if you intend to install/upgrade stuff on a live box (running FreeBSD,
RedHat , BSDI) please read the documentation, prepair a checklist of what needs
to be done, run a test on some form of RedHat Playpen box. Update any checklist
what exactly needs to be done. Then carefully touch the live box.
On Wed, 08 Mar 2000, rpjday wrote:
> On Tue, 7 Mar 2000, Steve Frampton wrote:
>
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On Mon, 6 Mar 2000, rpjday wrote:
> >
> > > arrrrggghh! because, as i recall, you asked for a "server" install, no?
> >
> > Er...
> >
> > > if something is going to be a server, that suggests it is going to be a
> > > 24x7 box, never to be dual-booted. hence, the complete wiping of the
> > > disks and everything on them.
> >
> > Huh? Why? I have a pretty nice Alpha box here, which has a RAID unit
> > attached with about 24 Gb of user space. Until now, it has been an
> > Digital Unix "Tru64" database server, but has been retired from that
> > purpose.
>
> then, according to red hat's definition (which is the only one that
> counts), it's not a "server" any more. (more on this later. keep
> reading if you want to know why.)
> >
> > Had Vidiot not screamed loud and hard about the problems with the
> > installation routine, Red Hat "Server" install would have not only wiped
> > out Digital Unix on the system disk (good thing), but all 24 Gb of user
> > data as well (BAAAAD thing).
> >
> > I agree 100% with Vidiot on this -- there should be an option to choose
> > between "automatic" and "manual" partitioning.
>
> i hate doing this, but i'm going to try to clarify a couple of points
> in this whole discussion. the main reason that this discussion is
> dragging on is because the main participants don't realize that
> they're arguing two distinct issues and are continually getting
> them confused.
>
> first, let's establish something up front: yes, red hat's install
> process could be improved. as numerous people have pointed out,
> the standard red hat install procedure could be clearer, more
> powerful, more flexible, give the user more choices, etc, etc.
> everyone recognizes this, and many people have already made
> lots of suggestions about how to do this. so there's no debating
> this point.
>
> however, vidiot is making a totally different claim: that red hat's
> install process is *disastrously* *flawed*, to the point that it
> cost him years worth of work. and as we've already established,
> this is complete nonsense.
>
> vidiot's disaster is not a consequence of a flawed red hat installation
> program -- it is a result of numerous incredibly bad decisions on
> vidiot's part, including (but not limited to) getting a new release
> of the OS from a friend without the docs, refusing to read the
> easily available docs and assuming that he knows what's going to
> happen, selecting (if i recall correctly) a "server" install,
> ignoring the glaring warning about what's about to happen,
> and (most incredibly) doing something as significant as an install/
> upgrade without having done a valid backup in years. how this
> can be interpreted as red hat's fault is beyond me.
>
> yes, the install process can be made better. is it awkward?
> sometimes. is it inconvenient. sometimes. can it be made more
> powerful? undoubtedly. is it fatally flawed? in my opinion, no.
> and the frustration in this ongoing dialogue is a result of
> confusing the first issues with the last issue. vidiot seems to
> think that any admission that the red hat install process can be
> improved vindicates him. wrong. what vidiot did, he brought upon
> himself.
>
> now, as to this "server" definition. as i read it, when you select
> a "server" type install, this will (currently) wipe *all* of your
> disks. some people object to this. your objections are misplaced.
>
> one definition of a server is a machine that is up 24x7. based on
> this definition, there is no justification for anything else to
> be on the hard drive. this may be just one definition of the
> word, but it is the definition that red hat is apparently using.
> if you don't like it, too bad -- it's red hat's product, it's their
> docs, and if they choose to define it this way, that's their
> business AS LONG AS THEY DEFINE CLEARLY WHAT THAT MEANS. which
> they do.
>
> you can argue they should have used a different word. fine.
> they could call it a "virgin" install. or a "complete wipe"
> install. or, for that matter, a "veeblefetz" install, as long
> as they define what that means. which they do, up front and
> in big letters, with accompanying warnings. you, as the user,
> have a responsibility to not select a "server" install unless
> you know what *red hat* means by that, and they explain it pretty
> clearly. the fact that you would prefer a different definition
> is not relevant.
>
> so, yes, we can all take potshots at the red hat install process.
> god knows, i have. but there's a huge difference with pointing out
> areas of improvement, and claiming that it is hideously, fatally
> broken. which is why this discussion is being dragged out as
> long as it has been.
>
> rday
>
>
>
>
> --
> To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe"
> as the Subject.
--
--
To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe"
as the Subject.
