Okay, really, GP asks a genuine question, and you respond with this kind of misinformation? On the off chance that you're actually this confused - or on the likelier chance that someone else comes by and takes your comment seriously - let me make some corrections for you.
> There is no such thing as a vanilla Linux you can run
The phrase "vanilla Linux" doesn't even make sense. Linux is a kernel, not an operating system. If you're talking about the entire GNU/Linux operating system, it doesn't make sense to talk about a "vanilla" version, because there are thousands of different utilities that can comprise a GNU/Linux-based operating system, and there are combinatorially many ways to create a Linux distribution.
That's like saying that there's no "vanilla" BSD - only [Open|Free|Net]BSD - except worse, because some of the Linux "distributions" are really no more different than adding an extra package (eg, KDE) to an existing distribution and giving it a different name. It's as if you called BSD by two different names depending on whether or not you pre-installed Emacs.
> All the distros that have varying degrees of incompabilities and infelicities between each other.
This is vastly exaggerated. A properly compiled binary or a compatible source file should run on any distro - not just any modern distro, but any older one as well (assuming that it has the correct dependencies installed, etc.).
> And every now and then some figure who knows which political strings to pull uses that clout to load your favorite distro with pre-beta crapware.
If I wanted to get really snarky here, I'd say that the same thing could happen to BSD too and point to OS X. This is just ridiculous - Linux is open source and free-as-in-freedom, so just because somebody else packages your favorite distro with some stuff you don't like doesn't mean that anybody else has to as well - you can just as easily remove it and create your own "distro" as a fork.
I disagree that the GGP asked a genuine question (I've posted about this earlier), but just wanted to point out that the "genuine" question was about FreeBSD in particular, not BSD, and you're replying about BSD vs. Linux, rather than FreeBSD vs. Linux, so a bit of your answer is misdirected. That said:
> If you're talking about the entire GNU/Linux operating system, it doesn't make sense to talk about a "vanilla" version, because there are thousands of different utilities that can comprise a GNU/Linux-based operating system, and there are combinatorially many ways to create a Linux distribution.
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.
> > All the distros that have varying degrees of incompabilities and infelicities between each other.
> This is vastly exaggerated. A properly compiled binary or a compatible source file should run on any distro
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 (not easy even if its the same format, often hard if it's a different format), you have to be very familiar with both package standards to make it work. "alien" helps, but if your package has lots of dependencies, you really need to know what you are doing.
>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.
> 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.
> 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.
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.
>> If you're talking about the entire GNU/Linux operating system, it doesn't make sense to talk about a "vanilla" version, because there are thousands of different utilities that can comprise a GNU/Linux-based operating system, and there are combinatorially many ways to create a Linux distribution.
> 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.
If I want to use the FreeBSD kernel, I have many choices of distribution: FreeBSD, PC-BSD, Debian GNU/kFreeBSD, etc.
If I want to use the linux kernel, I have many, many, choices of distribution: Red Hat, SUSE, Debian etc.
I disagree, it's not misinformation but pretty much my experience.
> This is vastly exaggerated. A properly compiled binary or a compatible source file should run on any distro - not just any modern distro, but any older one as well (assuming that it has the correct dependencies installed, etc.).
Yes, if you feel like spending two hours compiling some code and twice that to debug some issues with the bug system on your repo. Fortunately this does not happen a lot, but it happens. Most of the things that are not in the package repositories for your distro is going to give you a hard time (6h install time might be reserved for extreme cases tough, if you are a seasoned linux veteran).
Btw, I suppose the problem is the same between the different BSDs.
> Most of the things that are not in the package repositories for your distro is going to give you a hard time (6h install time might be reserved for extreme cases tough, if you are a seasoned linux veteran).
Honestly, how often does that really come up? This is one of those horror stories that I always hear people (particularly BSD users) telling, but I've never had problems of this sort[1].
I run a distribution which doesn't use deb/rpm packages, and I compile things from source all the time. The vast majority of the time spent is the sheer compilation process, not debugging any local problems.
The only times I've had issues with binaries are with sloppily compiled executables - and it's not worth complaining about those, because there are a hundred different ways that sloppy code can be incompatible with two different systems running the same distro.
A static
> Btw, I suppose the problem is the same between the different BSDs.
Yes, and frankly, if you have a piece of code that is architected to work on at least one Linux distribution and at least one BSD or OS X, I have a hard time imagining that it would fail on other Linux distributions as well.
If it's not "cross-NIX", then it's probably something that only makes sense in the context of your distribution anyway (say, a patch for your package .manager) or a small, one-off that is easily modified.
[1] Problems, sure, but not problems arising from distro variation.
>The phrase "vanilla Linux" doesn't even make sense. Linux is a kernel, not an operating system. If you're talking about the entire GNU/Linux operating system, it doesn't make sense to talk about a "vanilla" version, because there are thousands of different utilities that can comprise a GNU/Linux-based operating system, and there are combinatorially many ways to create a Linux distribution.
The point is, when it breaks and you need someone to help you fix it, it's often not enough to find someone else who "uses Linux" - you need to find someone else who runs the same distribution, because they all have their own init scripts, packaging systems, filesystem layouts etc.
By contrast, because there is a single FreeBSD, anyone who "uses FreeBSD" can probably help you with your FreeBSD problems.
(Of course, if you choose a popular linux like Ubuntu, there are probably many more people who "use Ubuntu" than use FreeBSD)
>This is vastly exaggerated. A properly compiled binary or a compatible source file should run on any distro - not just any modern distro, but any older one as well (assuming that it has the correct dependencies installed, etc.).
Seriously? I don't think I've ever seen a cross-platform binary that worked without distro-specific hackery. Source sure.
>If I wanted to get really snarky here, I'd say that the same thing could happen to BSD too and point to OS X. This is just ridiculous - Linux is open source and free-as-in-freedom, so just because somebody else packages your favorite distro with some stuff you don't like doesn't mean that anybody else has to as well
You're right - but there is some truth to the generalization that linux distributions a) rush in software before it's truly stable (Debian stable being the exception that proves the rule) b) are more politicised than FreeBSD. The recent Gnome 3 / Unity fuss would be unthinkable in FreeBSD-land. In the time it's taken Linux to go OSS -> ALSA -> PulseAudio (and say what you like but I know several people whose sound broke with each of those) FreeBSD has stuck with OSS. Linux introduced devfs, encouraged users to migrate, then deprecated and killed it off in the space of about 18 months (in favour of udev); FreeBSD has only ever had one devfs. FreeBSD ships binary compatibility going back to at least version 5, while very few linux distributions still ship glibc5 libraries. In FreeBSD I've never had a driver that used to work stop working (under linux I used the qc-usb driver, which then stopped building against newer kernels; also the drivers for my PDA (sc-somethingorother)).
> The point is, when it breaks and you need someone to help you fix it, it's often not enough to find someone else who "uses Linux" - you need to find someone else who runs the same distribution, because they all have their own init scripts, packaging systems, filesystem layouts etc.
Again, greatly exaggerated. I'm usually able to use Ubuntu or Fedora forums to help solve my problems, even though I don't run a Debian-based distribution. If I'm having systemd problems, I can debug that the same way as with any system running systemd, whether it's Fedora, Red Hat, Arch, etc. If I'm having issues with my package manager, I can use resources from any distro that uses that same package manager.
You're assuming that these variations cause combinatorially many possibilities for problems, but in reality, Linux is designed to be modular enough that these things don't compound in practice.
That's not even taking into account that most Mint issues have the same solutions as they would on Debian/Ubuntu, etc., because most distros are derived from one of a small set of distros; very few start 'from scratch'.
> By contrast, because there is a single FreeBSD, anyone who "uses FreeBSD" can probably help you with your FreeBSD problems.
Yes, but NetBSD and OpenBSD? Not so helpful. And frankly, given the relative sizes of the Linux and BSD userbases, this isn't really a problem on Linux at all.
> There is no such thing as a vanilla Linux you can run
The phrase "vanilla Linux" doesn't even make sense. Linux is a kernel, not an operating system. If you're talking about the entire GNU/Linux operating system, it doesn't make sense to talk about a "vanilla" version, because there are thousands of different utilities that can comprise a GNU/Linux-based operating system, and there are combinatorially many ways to create a Linux distribution.
That's like saying that there's no "vanilla" BSD - only [Open|Free|Net]BSD - except worse, because some of the Linux "distributions" are really no more different than adding an extra package (eg, KDE) to an existing distribution and giving it a different name. It's as if you called BSD by two different names depending on whether or not you pre-installed Emacs.
> All the distros that have varying degrees of incompabilities and infelicities between each other.
This is vastly exaggerated. A properly compiled binary or a compatible source file should run on any distro - not just any modern distro, but any older one as well (assuming that it has the correct dependencies installed, etc.).
> And every now and then some figure who knows which political strings to pull uses that clout to load your favorite distro with pre-beta crapware.
If I wanted to get really snarky here, I'd say that the same thing could happen to BSD too and point to OS X. This is just ridiculous - Linux is open source and free-as-in-freedom, so just because somebody else packages your favorite distro with some stuff you don't like doesn't mean that anybody else has to as well - you can just as easily remove it and create your own "distro" as a fork.