[rhelv6-beta-list] My first experiences with RHEL6 beta

[Nico Kadel-Garcia]

On Tue, Jun 15, 2010 at 5:19 AM, James Findley
<james.findley at trans-axion.net> wrote:
> On 06/15/2010 03:37 AM, John Summerfield wrote:
>>

>> It's lost here. My installs of RHEL6 and Fedora12 on Windows XP
>> Professional running Microsoft Virtual PC did not complete. They got to
>> installing the last package, then set there using little resources for
>> some days.
>
> It's very possible you're the only person reading this list that cares at
> all about MS Virtual PC on windows XP.

Simply put, this claim is not true. Flaws that break one
virtualization system are often indicative of flaws that will break
others under other circumstances. And I've certainly used MS Virtual
PC in environments where I was blocked by local policy from installing
non-Microsoft tools, such as VMware or VirtualBox, but needed a
working Linux environment on my desktop or laptop.

> Here in the real world, we have some rather better virtualisation options
> open to us.

And this is not particularly relevant. RHEL is supposed to be robust,
with robust support from RedHat, and with contributions from the free
software community. That's what's going on here.

>>> http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6-Beta/html/Beta_Release_Notes/installer.html#id625818
>>>
>>> For text-only or headless systems, VNC is _highly_recommended_. In
>>> fact, the installer is fairly good at offering VNC if it can't start
>>> the graphical installation. This feature alone was very welcome by
>>> several people I know. ;)
>>
>> zBox-owners I expect.
>
> Actually there's a slightly different release for z-series.  Dismissing the
> recommended installation method because you think it's for z-series only is
> a mite silly.

What? He didn't dismiss it. He guessed at who would most welcome it.

> You seem to have missed something.  RHEL stands for Red Hat Enterprise
> Linux.
> This is an operating system designed primary for servers, with X/destop bits
> included for corporate desktops or IT professionals.  It really isn't
> designed around you, personally.

It's also built on freeware, which *is* designed "for us, personally"
because we wrote it. This is why we publish patches for the Fedora
world, or RHEL, or other freeware flavors of software and publish
them. Bug reports are a big part of that process: simply saying "oh,
it doesn't work, I shouldn't expect it to work" and failing to report
the issue leaves broken software lying around.

>>> And those issues include running Windows under Virtual PC itself. ;)
>>
>> We could talk about Windows 7 Sound in Microsoft Virtual PC hosted on
>> XP, but this is a Linux list!
>>
>>
>>>
>>> Also know Networking is typically a major issue with Microsoft and
>>> VMware hypervisors. I also find the more familiar people are with
>>> Windows, and using Windows for virtualization, the more things I have
>>> to teach them in how to setup their environment for Linux.
>>
>> I could talk about VMWare too. I removed it just as fast as I could when
>> I found it disables Fast User Switching.

Oh, my. I generally find the reverse to be true, but I date back to BSD 4.x.

>>>> Speaking of vi, why is the whole of vim not installed?
>>>
>>> vim-minimal v. vim-enhanced or vim-X11 (w/vim-common) -- the first
>>> goes into /, the latters going into /usr. This was discussed years
>>> ago, and the current logic is sound to most customers I speak with.
>>>
>>> Also, installing (and bloating) the system off-the-bat with many
>>> things is not always the best move. vim-minimal works, and doesn't
>>> bring in the much, much bigger lot of software.
>>
>> I was surprised to find just how much more it did bring in, but then
>> Linux sans Perl is fairly surprising too.

Yeah, it took me a while to stop laughing when I realized the "emacs"
in the installation media is actually Jove, "Jonathan's Own Version of
Emacs", sometimes known as :Jove", even though there is no Fedora or
RHEL published RPM for it over at rpm.pbone.net.

>>>
>>>> Why, when I wanted to install more software, yum goes out to the
>>>> network and downloads stuff at 30kbytes/sec (my network can
>>>> do 1.5 mbytes/sec and better, the the speed problem's not at
>>>> my end) when it could load of my virtual DVD at 200
>>>> Mbytes/sec?
>>>
>>> Then target the virtual DVD image as your YUM repository. ;)
>>
>> That should be done automatically. Last time I tried, probably with
>> RHEL5, the DVD image seems unusable post install. I had a qhick look at
>> the repo files and it didn't seem to have changed.

RHEL 6 doesn't seem to do this. It would be a disabled repository
listed in /etc/yum.repos.d/*.repo files.

>>> "My VM software of choice is Microsoft Virtual PC ..."
>>>
>>> Repeat for VMware hypervisors as well. ;)
>>>
>>>> On prompting, I manged to choose one that was close, and
>>>> went on to install using a framebuffer console.
>>>
>>> VNC works wonders here. Again, I've had several customers now comment
>>> how the auto-offer of VNC really helps during installation, and easy
>>> setup post-installation.
>>
>> VNC might work, but it's not how I want to use it.
>
> Once again, this isn't "John Summerfield Linux"  Feel free to create that if
> you want.

I personally detest VNC in production use, even through I wrote the
first SunOS port of it years and years ago, and its historic default
storage of server session passwords in $HOME/.vnc/ with merely "crypt"
based passwords, and its default settings of "start a bare xterm with
a minimal window manager, rather than the system's default window
manager with screenlock available and other useful settings" to be
fairly painful.

>>> Application details are another. Although GNOME, KDE and some frameworks
>>> could be well integrated, paper size and other localizations may require
>>> far more logic -- and possibly still get things wrong.
>>
>> Getting it right some times would be an enormous improvement over
>> getting it wrong all the time. AFAIK nobody outside USA uses Letter paper.

And, oh, dear lord, don't get me started on setting it properly in
CUPS. Take a look at Eric Raymond's old essay on "The Luxury of
Ignorance" for a good screed on open source interfaces and how they so
often fail.

>> text-mode used to be quite a viable choice, and I sometimes used to
>> simply to get the job done faster.
>>
>
> This I agree with - localisation is a major pain.  Unfortunately making it
> work in practice isn't as easy as it looks, which is why it hasn't been done
> yet.

Yeah. I'm a big believer in setting "LANG=C" or "LANG=POSIX" by
default. This makes old man pages work better, and fixes the
case-insensitive "sort" problem, unlike the RHEL standard
"en_US.UTF8". What fool decided that standard should be case
insensitive, I'd like to know?

>> Those cases where the mouse doesn't work over ssh need some attention,
>> and the a proper interactive install over ssh, using a mouse, would be
>> possible, and I reckon the mainframe users would love it.
>>
>> Installing graphical software of any kind on a mainframe is a huge wast
>> of very expensive CPU cycles. Most of them would be very happy to omit X.
>>
>>
>
> As noted there's a slightly different version for mainframes, and with the
> regular release if you select the "server" option it won't install any
> graphical stuff anyway.  So what's your point?
> Because the option doesn't make sense for $arbitary_unrelated_usecase it
> must be wrong for you too?  That's odd.

It's hardly an arbitrary usecase. And many components demand X to
operate usably. For example, there is no graceful non-X tool for
managing NFSv4 ACL's, nor for configuring kickstart files.