Weekly Edition
Return to the Press page
| |||||||||||
Experts say software vendors will soon offer products for different Linux 'flavors' (NewsForge)
Here's a NewsForge editorial on a change in
the Linux application landscape. ""Historically, vendors have
tended to work with one flavor of Linux," said Daniel K. Boice, president
and CEO of The Jaxara Group, an open source software applications
developer, located in Bethesda, Md.. "However, it seems that vendors, such
as Oracle, are using the growing popularity and acceptance of SUSE, Red
Hat, and other Linux distribution, to grow sales. I believe that in an
effort to increase both visibility, and revenue, vendor will begin to
partner with different Linux distribution.""
(Log in to post comments)
Experts say software vendors will soon offer products for different Linux 'flavors' (NewsForge) Posted Sep 7, 2004 21:33 UTC (Tue) by dang (subscriber, #310) [Link] This seems a silly concern. There clearly *is* a difference wrt to certification. If you want to keep your ass covered ( and your job secure ), then you run an app on a platform for which it is "certified" and you pass problems up the support chain. But the "linux flavors" and "extensions" stuff is bogus. It has always been the case that to run certain applications you might need to patch your kernel and tune your system in certain ways. This really hasn't changed. Who runs a vanilla kernel.org kernel these days anyway?
The only real concern would be if apps wanted kernel patches for which the source was not open, but that isn't what I see. For now the impact is all in the ( important and legitimate ) butt-covering area.
Experts say software vendors will soon offer products for different Linux 'flavors' (NewsForge) Posted Sep 7, 2004 22:50 UTC (Tue) by iabervon (subscriber, #722) [Link] I'm running a 2.6.8.1 kernel from kernel.org, and the only change I made to it is to remove -nostdinc because the build of GCC I have is broken wrt -iwithprefix. Distros seem to be interacting better with Linus et al these days and getting their patches into the mainline. Most of the distributions I've heard about have made a goal of not carrying any external kernel patches, because it just creates extra work for them.
Vanilla kernels 'flavors' (NewsForge) Posted Sep 7, 2004 23:19 UTC (Tue) by man_ls (subscriber, #15091) [Link] This only reinforces the point made above: that "flavors" of Linux are all about commercial interests. When complex frameworks like KDE work perfectly on different flavors of proprietary Unix, FreeBSD and Linux, on a staggering multitude of hardware architectures, I can't see why some application might only run on Red Hat. Of course drivers are different, but how can anyone tie their program so tightly to the kernel patch-set of any distribution that they can not be made to run on another?It is clearly cheaper for a developer house to just support, say, Red Hat 9 on x86. But as the previous poster said, it looks just like collective butt-covering.
Vanilla kernels 'flavors' (NewsForge) Posted Sep 8, 2004 2:35 UTC (Wed) by iabervon (subscriber, #722) [Link] I think the main reason to not want to support anything but particular distros (and particular versions) is that the versions of everything (and sometimes even the version numbering schemes) is different. This makes it difficult to provide binaries that will behave as expected. Sun's JDK works admirably, but anything that uses C++ will run into the issue that it might want libstdc++.so.5 when I only have libstdc++-3-libc6.2-2-2.10.0.so and libstdc++.so.3.0.4.
Experts say software vendors will soon offer products for different Linux 'flavors' (NewsForge) Posted Sep 7, 2004 23:27 UTC (Tue) by dang (subscriber, #310) [Link] Actually a lot of the large distro's kernels *are* significantly patched. But if you want to run an app that needs those patches, you can easily apply them yourself.
Experts say software vendors will soon offer products for different Linux 'flavors' (NewsForge) Posted Sep 8, 2004 2:18 UTC (Wed) by iabervon (subscriber, #722) [Link] Much more so with 2.4 kernels than 2.6 kernels, though, because a lot of the patches are backports of 2.5 features to 2.4. Red Hat needed the new features to support some customers, but they didn't want to ship a development-series kernel, so they backported stuff. But the current Red Hat kernel is evidentally almost all from kernel.org, particularly if you include non-vanilla patches available from kernel.org (e.g., -mm). For that matter, the "true Red Hat stuff" mentioned in the lwn article on the subject is conveniently linked from kernel.org. One reason not to do a 2.7 series is that it would surely encourage distros to backport the changes and ship more heavily patched kernels again.
Experts say software vendors will soon offer products for different Linux 'flavors' (NewsForge) Posted Sep 8, 2004 6:45 UTC (Wed) by dang (subscriber, #310) [Link] Yup, but if you want to run oracle on a certified RH environment, for instance, you are on enterprise server, which is a heavily patched 2.4 kernel.
Experts say software vendors will soon offer products for different Linux 'flavors' (NewsForge) Posted Sep 8, 2004 10:18 UTC (Wed) by dps (subscriber, #5725) [Link] I would expect most software to work on most distributions provied you can bypass any "installer" than assumes you use rpm, dpkg, or whatever else you turn out not be using. 98% of softwrae works with most versions of the major shared libraries, provided nobody twiddled an ABI changing gcc switch.
I would expect most software that "only works on RH" to run fine on debian (and Fedora, SuSE, etc). Most of the extras are actually the same things on most distributions, albeit maybe not things installed by default.
KDE, Gnome, and a lot of free software works almost anywhere partly because the GNU auto* tools are good at figuring the local variations on any given system.
Experts say software vendors will soon offer products for different Linux'flavors' (NewsForge) Posted Sep 9, 2004 12:57 UTC (Thu) by NAR (subscriber, #1313) [Link] I would expect most software that "only works on RH" to run fine on debian (and Fedora, SuSE, etc). Most of the extras are actually the same things on most distributions, albeit maybe not things installed by default.Yeah. Until you get a fault report from one of your costumers that you just can't reproduce. Then, after weeks of debugging, you realize that the glibc/zlib/etc. shipped with the costumer's distribution has a bug (or feautre) which the glibc/zlib/etc. shipped with your distribution doesn't have and that caused all the trouble...
|
|||||||||||