[rhelv6-beta-list] why rhel-6 still not a good choice for a programmer

[Bryan J. Smith]

[ Donning the meta-discussion hat ... oh boy, here I go ... ]

Rahul Sundaram <metherid at gmail.com> wrote:
> Fedora is not a commercially supported product ...

As a long-time, Fedora-Red Hat-centric welding engineer myself,
if we're really talking about developers and targeting platforms,
then we're usually talking four (4) different things (this is my
experience over the last decade talking, just myself) ...

1.  Targeting community releases (Fedora and EPEL, maybe others)
2.  Targeting enterprise releases (Red Hat)
3.  Targeting embedded releases (Timesys<-Fedora, Montavisa<-Red Hat)
4.  Targeting non-Linux (various)

If you're targeting community releases, then you're typically developing
on Fedora for Fedora, with a port to Red Hat Enterprise Linux via EPEL.

If you're targeting enterprise releases, then you're typically prototyping
and doing leading edge development on Fedora, with the pre-release,
release and consuming, sustaining engineering on Red Hat Enterprise Linux.

If you're targeting embedded releases, the top two vendors are Timesys,
who ships embedded, "reference" distros on Fedora, and Montavista, who
ships 3-year subscriptions heavily based on Red Hat source code releases.

I will not address non-Linux, although there are cross-compiling options
shipping with Fedora, as well as other options that run under either
Fedora or Red Hat Enterprise Linux.

In all cases, if you're going to virtualize, you're going to want to run
your host as x86-64, out of sheer memory usage.  If you really need
something 32-bit, then run it as a VM, and lobby the organization failing
to release ports for x86-64, period.

I've run Red Hat products as my host, and then Fedora and Red Hat products
as VMs.  if you really, really want to limit yourself, then by all means,
run Fedora 32-bit with guests that are 32-bit.  I do not see this as a
sustainable solution for the great majority of developers myself, but that
is my very biased view.

I have been running x86-64 as a developer solution since Fedora Core 3
and Red Hat Enterprise Linux release 4, chroot and other environments as
necessary.  In fact, most of the time it's support issues that have little
to do with the platform, when it comes to development.

I have a dual-boot with 32-bit, but I rarely use it.  The last time I
required such, it was the Fedora Core 5-6 time frame.  I am having a great
time with the Red Hat Enterprise Linux release 6 Beta and KVM on my
personal notebook, and look forward to its release (and its near-future
use on my corporate-issued notebook), and it may very much replace
Fedora my personal notebook's host OS (for the first time ever).

> Red Hat has no control over proprietary software like Flash
> and Skype and yes it is unfortunate they the vendors engage in poor
> packaging as with the case of Skype but this is not something
> programmers worry about primarily.

Putting entire, free and open communities under the thumb of proprietary,
closed and controlled protocols/services puts a completely new dependency
on the community.  I don't think people realize how poor of a move it is
to make a sanctioned choice, with commercial dollars, for the community.

It's one thing to take no issue with proprietary drivers or proprietary
applications, that ultimately still use open standards (e.g., OpenGL)
or open formats (e.g., TIFF).  As much as we'd love everything to be open,
sometimes consumers choose another solution, and as long as there is a
standard behind the implementation, the cringe is at least lessened by
the fact that the end-application or solution has a format that is or can
be implemented by something else.

But when you have a controlled, patented or otherwise non-free protocol,
implementation or other dependency, with no alternative that supports the
same protocol, files, etc..., and one entity decides to include or even
require that solution, the rest of the community shares in that dependency.
Not ideal.

> In the case of skype, the package fails to enumerate dependencies
> properly and needs a workaround.  Download the package and run
> yum install libXScrnSaver.i?86 libX11.i?86 libv4l.i?86
> alsa-plugins-pulseaudio.i?86 qt-x11.i?86;yum install
> skype-2.1.0.47-fc10.i586.rpm --nogpgcheck

Most x86-64 issues are merely such packaging issues.  Wish it wasn't the
case, and they are rare today, but they still happen.  The reality is that
most everyone has gone x86-64, and those who have not or do not support
such proper, are only going to alienate those who have.

Developers should be able to work through these packaging details without
much fuss.  There are always going to be issues developers have to address
for their complex environments.

My $0.02 ...

--
Bryan J  Smith             Professional, Technical Annoyance 
------------------------------------------------------------ 
"Now if you own an automatic ... sell it!
 You are totally missing out on the coolest part of driving"
                                         -- Johnny O'Connell