Re: Linux Vs. FreeBSD

"Daveman750" <dsimcha@xxxxxxxxx> writes:

> > BSD and Linux are each highly compatible within their flavours, and
> > between each other to a surprising degree. Binary compatibility is only
> > important if you think that distribution of binaries is the correct way to
> > move software around. Why is that so obviously the case to you?
> > --
>
> Simple: Being able to see the source code is only an important
> personal, as opposed to collective, freedom, for the small minority of
> people who are actually programmers. On the other hand, compiling
> source code is annoyingly slow and relatively difficult when it cones
> to things such as build environments. It's nice to know that with free
> software, anyone can see the source code and is free to hack it, but
> given that I only have minimal programming skills, it really is of no
> use for me _personally_ to be able to see the source code, along with
> about 99% of other users. For us, binaries are just plain easier.
>
> Elaborating on the whole binary compatibility thing, if you try to
> install something intended for one distro on another, different GCC
> versions, library versions, etc. make it virtually impossible, as I
> understand it. Debian vs. Fedora is actually a bad example, because
> they use different package managers. A better example would be Fedora
> vs. Suse. You usually can't install a Fedora package on Suse or vice
> versa. Correct me if I'm wrong on this one, but I can't imagine why
> else they would package things separately for each of these distros.
> This is an extreme pain in the you-know-what for users who don't want
> to compile source themselves and are using anything but the most
> popular, well-known distros.

This is an RPM problem, not a binary problem, and it is a well-known and
much-ridiculed one. If you were to use, say ,rpm2tgz (or whatever it's
called), and turn those packages into a tarball and extract them, if you
met the required dependencies (actually met them, not met whatever your
distro chooses to call them), you can run that program. Most programs
worth using usually make a few binary forms available, and a plain tarball
is usually one of them. Don't go blaming Red Hat's idiocy, and the idiocy
of those who follow them, on a binary incompatability problem that by and
large does not exist.
.

Relevant Pages

  • Re: Linux Vs. FreeBSD
    ... > source code is annoyingly slow and relatively difficult when it cones ... > Elaborating on the whole binary compatibility thing, ... A better example would be Fedora ... You usually can't install a Fedora package on Suse or vice ...
    (comp.os.linux.misc)
  • Re: Linux Vs. FreeBSD
    ... Being able to see the source code is only an important ... Elaborating on the whole binary compatibility thing, ... A better example would be Fedora ... You usually can't install a Fedora package on Suse or vice ...
    (comp.os.linux.misc)
  • Re: cobbling a ComboBox
    ... suggest you have a look at the library source code (of Swing, ... package scratch; ... boolean shouldValidate = false; ... the String ought to be "scratch.CustomMetalComboBoxUI". ...
    (comp.lang.java.gui)
  • Re: can I install java 1.5 on redhat 7.1?
    ... apt or portage for managing updates of binary packages or source code. ... have a much easier time with a more recent distro, ... Debian or Gentoo that has a good system for keeping things up to date. ...
    (comp.os.linux.misc)
  • Re: Redhat and OpenSSL Manner
    ... It's equivalent to 0.9.7a as originally distributed by OpenSSL project, with security and bug fixes added to it by Red Hat. ... enhancements and new features might be backported from newer versions too if they are not introducing any compatibility problems (for example this is often done for kernel package in RHEL to support new hardware). ... If you look into the SRPM packages, you'll see that they contain original unchanged source code wich is the same version as the package version, and also bunch of patches that get applied to that source code prior to compilation. ...
    (RedHat)