3 ms·

>That exactly WAS the GP's point about the difference, I think, and exactly what he said: There's no "vanilla Linux" you can run. There is a "vanilla FreeBSD" y

>That exactly WAS the GP's point about the difference, I think, and exactly what he said: There's no "vanilla Linux" you can run. There is a "vanilla FreeBSD" you can run. That's a huge difference. Linux is the kernel, vanilla Linux would be the Linux mainline. >That's NOT vastly exaggerated. While it is usually possible to do so, it is usually painful unless you start from a source package. If you have a binary rpm or deb and want to install it on a distro it was not intended for The one you are responding to was talking about binaries, why are you conflating that with rpm/deb package formats? Like the aforementioned poster said, as long as dependancies are met there would be no problem running binaries across Linux distributions.

Locke1689 14y ago
The one you are responding to was talking about binaries, why are you conflating that with rpm/deb package formats? Like the aforementioned poster said, as long as dependancies are met there would be no problem running binaries across Linux distributions. Of course there would be. The glib from debian is not the same as the glibc from red hat, despite the name.
beagle3 14y ago
> Linux is the kernel, vanilla Linux would be the Linux mainline. Without an "init" process (or equivalent), of which there is no vanilla, that's about as good as a power-on-self-test. So, yes, technically you can run a "vanilla Linux" kernel, but not a "vanilla Linux" system, because there is no such thing. > The one you are responding to was talking about binaries, why are you conflating that with rpm/deb package formats? I think you are misinformed. Both rpm/deb ARE binaries. You (and poster) might have meant "executables", which I didn't really pay attention to because it's a strawman. "Well, you can run a staticly linked executable!". Duh. It's likely output will be "can't find /var/share/blahblah" because there are very few standalone binaries these days. Once you have 2 files (even if they are statically linked binaries), there are assumptions that must be made about where files other than the binary can be found - is it /etc like LSB, or /package like djb or whatever GoboLinux is using, or whatever NixOs is using. Practically, anything you want to run is going to need some setup - a setup which package managers provide. Furthermore, even textual executables cause problems: It's been a while, but a few years ago, you might get a script that hashbangs "/usr/bin/perl" where your system only supports "/bin/perl". It's easy to fix, either in the script or by making perl available in the other place - but, as I mentioned before, it is only easy if you know a lot about how the system works.
- chimeracoder 14y ago
  > So, yes, technically you can run a "vanilla Linux" kernel, but not a "vanilla Linux" system, because there is no such thing. This is kind of quibbling over a comparison between apples and oranges - or rather, more like comparing apple seeds to an entire orange. Whatever a "vanilla" kernel is, it doesn't make sense to compare it directly to a "vanilla" operating system. > I think you are misinformed. Both rpm/deb ARE binaries. You (and poster) might have meant "executables", which I didn't really pay attention to because it's a strawman. You won't run into any problems if you have EITHER: 1. A properly compiled static binary 2. The compileable source code Because of Debian's policies regarding open-source software, in practice #2 will be satisfied for any .deb package you care about. It doesn't make sense to complain about improperly built packages or build files, because I can easily create a build process that will fail on some BSD systems and not others too - there are many ways you can either accidentally or intentionally hardcode system-specific attributes into a script; the filesystem layout is only one small portion of compatibility. > It's been a while, but a few years ago, you might get a script that hashbangs "/usr/bin/perl" where your system only supports "/bin/perl". It's easy to fix, either in the script or by making perl available in the other place There are more elegant ways of fixing this too. In practice, though, it's not a problem. Not only are there tools that will automate this process, but very few scripts are written this badly nowadays anyway. I run a distribution that doesn't use one of the common package formats, and I can't remember a single time in the last two years I had a problem binary portability because of distribution-specific issues.

Locke1689 14y ago

The one you are responding to was talking about binaries, why are you conflating that with rpm/deb package formats? Like the aforementioned poster said, as long as dependancies are met there would be no problem running binaries across Linux distributions. Of course there would be. The glib from debian is not the same as the glibc from red hat, despite the name.

beagle3 14y ago

> Linux is the kernel, vanilla Linux would be the Linux mainline. Without an "init" process (or equivalent), of which there is no vanilla, that's about as good as a power-on-self-test. So, yes, technically you can run a "vanilla Linux" kernel, but not a "vanilla Linux" system, because there is no such thing. > The one you are responding to was talking about binaries, why are you conflating that with rpm/deb package formats? I think you are misinformed. Both rpm/deb ARE binaries. You (and poster) might have meant "executables", which I didn't really pay attention to because it's a strawman. "Well, you can run a staticly linked executable!". Duh. It's likely output will be "can't find /var/share/blahblah" because there are very few standalone binaries these days. Once you have 2 files (even if they are statically linked binaries), there are assumptions that must be made about where files other than the binary can be found - is it /etc like LSB, or /package like djb or whatever GoboLinux is using, or whatever NixOs is using. Practically, anything you want to run is going to need some setup - a setup which package managers provide. Furthermore, even textual executables cause problems: It's been a while, but a few years ago, you might get a script that hashbangs "/usr/bin/perl" where your system only supports "/bin/perl". It's easy to fix, either in the script or by making perl available in the other place - but, as I mentioned before, it is only easy if you know a lot about how the system works.

chimeracoder 14y ago
> So, yes, technically you can run a "vanilla Linux" kernel, but not a "vanilla Linux" system, because there is no such thing. This is kind of quibbling over a comparison between apples and oranges - or rather, more like comparing apple seeds to an entire orange. Whatever a "vanilla" kernel is, it doesn't make sense to compare it directly to a "vanilla" operating system. > I think you are misinformed. Both rpm/deb ARE binaries. You (and poster) might have meant "executables", which I didn't really pay attention to because it's a strawman. You won't run into any problems if you have EITHER: 1. A properly compiled static binary 2. The compileable source code Because of Debian's policies regarding open-source software, in practice #2 will be satisfied for any .deb package you care about. It doesn't make sense to complain about improperly built packages or build files, because I can easily create a build process that will fail on some BSD systems and not others too - there are many ways you can either accidentally or intentionally hardcode system-specific attributes into a script; the filesystem layout is only one small portion of compatibility. > It's been a while, but a few years ago, you might get a script that hashbangs "/usr/bin/perl" where your system only supports "/bin/perl". It's easy to fix, either in the script or by making perl available in the other place There are more elegant ways of fixing this too. In practice, though, it's not a problem. Not only are there tools that will automate this process, but very few scripts are written this badly nowadays anyway. I run a distribution that doesn't use one of the common package formats, and I can't remember a single time in the last two years I had a problem binary portability because of distribution-specific issues.