[nSLUG] Why you are not seeing software ported to Linux
draker at gmail.com
Thu Jun 23 02:56:33 ADT 2011
On 23 June 2011 00:09, D G Teed <donald.teed at gmail.com> wrote:
> On Wed, Jun 22, 2011 at 10:19 PM, Daniel Morrison <draker at gmail.com> wrote:
> It isn't as bad? Really? My workplace sometimes uses mothballed hardware
> from your workplace. We do unusual things when we are lacking funds.
> I might have a little more experience with how backward compatible
> new software and old hardware really are.
LOL, let's not make assumptions about each other's workplaces.
Discussion can be a good thing, but I don't want to get into a
drawn-out debate. So I'm just going to tell you how I see it:
In general, you're right. The [linux community|almost anything] could
benefit from a more disciplined and carefully planned approach to
development. It would make everybody's life easier not to have to deal
with seemingly bad decisions that cause problems. Perhaps corporate
involvement would increase if there were greater faith in the
stability and interoperability of Linux distributions on the part of
But it comes down to: what do you advocate?
Open source development is not like closed source development. In free
software, every patch and new feature is generally public. The
development process depends on the public for testing, bug reporting,
and patch contribution. There isn't always an official release of
software -- the Linux kernel being a good example of that.
Naturally not everyone wants to live on the raw bleeding edge all the
time, so collections of packages (in essence, lists of compatible
software version numbers) became "distributions". Now someone else was
doing at least basic sanity checking to ensure your system worked
Some companies have tried to make money at this. You can pay RedHat a
lot of money (still less than it used to cost for a Sun though) and
get all sorts of guarantees about compatibility as well as tech
support, so long as you pay their registration, run on approved
hardware, using all their approved packages. it's a controlled
environment. And that's why third parties release/sell packages for
RHEL, but not Debian. It also helps that the "controlled environment"
aspect of RedHat appeals to businesses, and so that's where the money
In consequence, however, you advance at a snail's pace with respect to
main thrust of development. It takes time to test all this software
together, and collect the required patches to make everything work.
RHEL 6 is way behind schedule.
I don't like a constrained environment. I don't like Microsoft's
products, and I'm not keen on RedHat. I prefer the source to be open
more than closed, and often simple rather then clever. (Debian folks
are just too darn smart). I prefer to have more features, and to deal
with some bugs -- as frustrating as they can be. I prefer the code
released sooner, rather than cleaner. One can always back off a
version that's fatally broken. But at other times it's possible to
leap to the forefront and support something brand new.
Fortunately, I'm not overly concerned with mass-market acceptance of
Linux. No company in their right mind would ever base a product on my
description of Linux!
I see your position as acknowledging all this, but having the opinion
that developers of software, especially key components such as the
kernel, grub, etc, should exercise more care and attention and
planning for changes than they currently do. The benefits would be
happier users and wider acceptance, and associated benefits. This is a
reasonable point of view.
The problem is that you stir up controversy by doing things like:
- dredging up an almost-decade old blog post that references two of
the biggest "moults" in Linux history (a.out/elf and libc5/6) -- you
might as well talk about the transition from DOS/16bit-Windows to
- referencing the single most contentious piece of proprietary kernel
code ever (nVidia graphics drivers)
- passive-aggressiveness, saying things like "I'm not defending the
blog" but then going on to state negatively that "much of open
source... meets a minimum standard"
- mixing related subjects (ABI/API/packaging) and also going on tangents
- using a subject like "Why you are not seeing software ported to
Linux". This is a provocative statement indicating that you know
something, contained within. But there's nothing delivered.
In short, this is trollish behaviour. I don't believe you're a genuine
troll, but you'll note that only somebody obsessive like myself is
still participating. And I quit. Right after I add a few notes inline
> I said "lazy" literally? Don't think so. I said they didn't
> put a high priority on the issues. Maybe you'd like to
> offer a guess as to why the standards can be lower at times.
You're right; you didn't say lazy. It's your characterization of the
developer ("It worked for me") that implies a laissez-faire
attitude... crudely translated as lazy.
> Of course, but you don't see them determining the bridge safety
> by trial and error afterward,
Well not afterward, but yes, you do. It's called destructive testing.
It happens in a lab. Some code is developed using analogous methods of
failure testing. But it tends to be expensive, and perhaps somewhat
contrary to the free software process I described earlier. Basically,
you can't compare desktop PC software with a civil engineering
project. They're just not the same.
> I would never say paid people always do worse quality.
And neither would I, nor did I. In fact, I would suggest that perhaps
some of the paid programmers producing the best code are also the
programmers producing some of the best open source code.
> So when Microsoft change their network drive mapping or active directory
> they send down the specs to the folks at Samba so they
> can correctly emulate it? No, it is reverse engineered.
Erm, yes, actually. The CIFS protocols are public and available here:
The specs for SMB2 were released before the first implementation
(Windows Vista) and the Samba project now supports SMB2 as well.
Originally the Samba project was reverse-engineering, but no more.
More information about the nSLUG