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

Bryan J. Smith b.j.smith at ieee.org
Thu Jun 17 05:49:48 UTC 2010


Nico Kadel-Garcia <nkadel at gmail.com> wrote:
> 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.
> ... 
> 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.
> ...
> 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.

Bugzilla submissions are _crucial_ to Red Hat being able to address
issues with software.  Leverage your Red Hat accounts and, if one
has none, then Bugzilla directly.  Red Hat needs customer feeback.

However, one should also realize that there are at least five (5)
types of software at work here, and that should be taken into account
when it comes to _expectations_:  

1.  Free Software in Enterprise Linux itself
2.  Free Software from the Fedora Project (EPEL, et al.)
3.  Free Software from the community at large (and indie repos)
4.  Independent Software Vendor (ISV) "partner" software
5.  Other ISV (non-partner) software

Red Hat employees focus on #1 and #4, and heavily #2 as well as even
some of #3, depending on customer needs.  However, the more closed
source #4 and #5 are, the more unable Red Hat is able to address issues.

Red Hat does not have access to VMware or Microsoft source code they
do not provide.  I've had to explain to my clients regularly why
Red Hat Cluster Suite failover is not supported on VMware, because
there were not the facilities in VMware to support such until just
recently (the "helper" agent just became available more recently
because the facilities were there).  That's despite the fact that
Red Hat and VMware are partners, it happens, and it's hardly on Red
Hat.

In the case of newer Hyper-V virtualization, Microsoft and Red Hat now
have an interoperability agreement in place.  Anything running on Hyper-V
should be filed into Bugzilla, and Red Hat will take it up with its
partner.  But when it comes to older Virtual PC, while I encourage people
to file Bugzilla entries, understand that newer Linux interfaces aren't
always going to be supported on older Virtual PC hypervisors.  This is
not Red Hat at work, but newer Linux on older, proprietary and largely
stagnant closed source code at work, which Red Hat can't do much about.

So do expect Red Hat offerings to meet customer needs, but also understand
when Red Hat is powerless to do anything about some things.  ;)

> I personally detest VNC in production use ...

And PXEBoot uses TFTP, and many other things, during installation,
are often "not recommended for production."  VNC is a fall-back for
installation-only, offering a GUI that can be pulled up by a very,
very simple client that does not need to be installed.

As someone else pointed out, one _can_ use full X, SSH tunnels and
other options too.  VNC is just an option in the toolset, one the
installer will offer when it cannot launch a local X-Server on the
local display hardware.

> 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?

It comes outside of all the distro vendors themselves.
No standard makes anyone happy.

Take Zoneinfo Region/City selection for example ...

There are regularly Bugzillas filed because someone disagreed
with the selection, and want others added.

In reality, the Zoneinfo approach (now over 25 years old) is
based on the largest (most populous) city of the time zone.
Although one could argue that others could be added, this would
add more complexity and possibly conflicts as well.

Sometimes it's just best to follow the upstream standard, and
not try to do otherwise, especially when it is very trusted.


-- 
Bryan J  Smith             Professional, Technical Annoyance 
Linked Profile:           http://www.linkedin.com/in/bjsmith 
------------------------------------------------------------ 
"Now if you own an automatic ... sell it!
 You are totally missing out on the coolest part of driving"
                                         -- Johnny O'Connell





More information about the rhelv6-beta-list mailing list