On Tue, Aug 10, 2010 at 3:53 PM, Odhiambo Washington <odhiambo@gmail.com> wrote:
In the *BSD world, you can deal directly with the Core Team, the commiters, the ports maintainers, and they are all known. As a matter of fact, you can easily dig their names and contacts from the pieces that they maintain. It's like everyone knows everyone.
In the GNU/Linux world, you can also deal directly with both the package maintainers, and the (upstream) developers/maintainers of the software. For example, look at the Debian page for the GNU C Library package: <
http://packages.debian.org/lenny/libc6>. On the right-hand side, you'll see a list of the maintainers and their contacts (if you really want to know). To file bugs, you should of course use more streamlined procedures: <
http://www.debian.org/Bugs/Reporting>. And if you're sure that your issue isn't a packaging issue, you can follow it up directly with the developer, by going to their website for example: <
http://www.gnu.org/software/libc/bugs.html>. Some give names and direct contacts, and some require you to use more streamlined procedures. Or your distribution's package maintainers can follow it up on your behalf. Which is usually easier because they probably understand the software better, and interract more with the developers.
I meant to ask if you can compile a binary on one Linux and then move it to a different flavor of Linux and run it without hassles:)We definately can't do this on the *BSDs. Linux looks so homogeneous I thought it could pull that off..
Most people use pre-compiled packages directly from the distributions' collections. And this (together with the tools used for this) has its benefits, such as automated installation, dependency resolution, and so on. Moving the software would be tricky, as different distributions install software to different places, and so on.
If you're talking about doing it on source-based distributions, even that is tricky, as "packages" are very differently on different distributions.
But if you're talking about using manually compiled software, then this is probably possible, in theory. As long as the required libraries are available (and can be found) on the new system, and the hardware architecture is the same.
Joseph.