[linux-elitists] What to do about cluebatting such companies, that require possibly *YEARS* old Distros
Wed Jan 26 12:37:38 PST 2005
On Wed, 2005-01-26 at 14:46, Greg Folkert wrote:
> On being prompted by Mister Moen...
> I for one, am disgusted with companies that are stuck in the
> "Pre-Fedora" Era.
Wow, it's the Pre-Fedora Era now?! I for one welcome our new
Ok, enough of the humor. Let's keep in mind that Fedora is VERY new, and
Red Hat Linux 7.3 was released in mid-may, 2002 -- less than three years
> I mean, WTF, I have stuff made for "Only RedHat v5." running just
> fine on Debian SID. Something that haven't been really worked/coded on
> for 5+ years (MARS-NWE) working just fine on Ubuntu's Warty. Yes, I
> compiled it, fixed a typo and voila.
There are typos in binaries? How does that happen?
Oh, you're talking about compiling from source...
That means minimal debugging of any portability issues. For example,
until VERY recently, Fedora was fond of a 4GB address-space patch for
the kernel that took the opportunity to move around a whole bunch of
shared libraries. This broke any software that thought it knew how
address space was allocated (e.g. almost all non-libc software including
interpreters for languages like Common LISP). There are also issues of
compiler compatibility (since gcc 3.4 broke most of the inline assembly
in the world by disallowing multi-line quotes).
Then of course, there's regression testing to make sure that that
debugging and/or the new platform didn't regress any previously known
issues. Fix any of those obscure issues (e.g. some new character set
handling just blew you out of the water on dozens of previously fixed
Then there's cutting the new release, release notes, errata, etc. This
is just time, and the process is already there, so it's not too bad...
unless you're trying to get other releases out the door at the same
Next QA starts hands-on testing.
Depending on how your company works and what their product is, the next
step is going to be convincing customers that they want to upgrade or
upgrading in-house software. The in-house upgrade is frustratingly the
solution that is often hardest. Why? Systems staffs have a reputation
for being bored and lazy, but this is a carefully crafted illusion ;-)
New customer deployments, monitoring enhancements and all sorts of other
priorities are going to vie with a massive shift of platform that gains
the company very little in comparison with most other activities that
currently have priority. So what do you do? What's more, you then find
that fringe infrastructure breaks. Your monitoring tools use an old
device probing API; your backups don't handle some new filesystem; and
In company after company I see this. Upgrading software more than once
every 5-6 years is HARD, and only once significant pain is felt does it
even become a consideration.
Of course, you can build that pain into your process, but why do you
want to build upgrades into your process that happen more than every few
years? What are you buying? Is it really that urgent that you get the
nifty new filesystem or X server RIGHT NOW? Why? Now, I will grant that
you want to not be stuck on Wang/VS for the rest of time, so there's a
compromise here, but you seem to be advocating the side of that
compromise that presents the most risk for the least return.
Bottom line: don't waste time getting stressed that people are running 3
year-old software. That's the best case scenario!
> So, how can we (we as FOSS activists) help these clueless Monstrosities
> called ISVs and IHVs get with the real program.
Beat them in the marketplace. That's the only language they understand.
Woefully, since they started with just about exactly the same attitude
you have, you'll likely just create the next generation of dinosaur.
More information about the linux-elitists