3 ms·

>> A Linux distribution is a collection of tools written by different groups of people, often with conflicting interests and priorities. >This is true! Especia

>> A Linux distribution is a collection of tools written by different groups of people, often with conflicting interests and priorities. >This is true! Especially for core bits of the system, like glibc and the kernel. Come on, of course this is blatantly false. There is plenty of politics. I've experienced it first hand. FreeBSD developers are most definitively driven by some agenda other than the selfless "the common good". >> there are no conflicting interests in the [FreeBSD] project > Ha. ha. ha. My point exactly !

loeg 7y ago
I didn't try to say FreeBSD doesn't have detracting politics (I don't think I said that) — you're absolutely right; it does. My understanding, and let me know if I'm totally wrong, is that most glibc developers are not Linux kernel developers, and that most kernel developers are not glibc developers. In FreeBSD, I think there's more crossover of developers working on both userspace and kernel components. The monorepo design helps foster that (again, subjective, IMO).
- alacombe 7y ago
  The monorepo is actually a downside as it weaken any form of backward compatibility one could legitimately expect. The general answer in these case "rebuild", but it completely ignores binary-only software which exists in the real world and which is to a large extend completely ignored by commiters. At some point, you want to spend CPU cycle on something else than "rebuilding world". Also, there is de-facto no competition, short of a hard fork, in the software shipped. You can't just "switch to uclibc" if an embedded platform has memory constraint.
  - loeg 7y ago
    I don't know if you're familiar with FreeBSD's approach to backwards compatibility in general, or just making a general statement about monorepos. It doesn't seem like you're familiar with FreeBSD in practice; apologies if I guessed wrong. FreeBSD has strong backwards compatibility at the shared library level, across all versions. Support for BSD 4.3 (as in, 1986, pre-FreeBSD) compatibility is slowly being phased out in 2019. Grep around for COMPAT_FREEBSD, for example. This compatibility (for existing stable releases) is by and large maintained in the development branch. FreeBSD's also got a Linux syscall emulation layer, which implements (some of) the Linux kernel's (stable) ABI. > The general answer in these case "rebuild", but it completely ignores binary-only software which exists in the real world and which is to a large extend completely ignored by commiters. At some point, you want to spend CPU cycle on something else than "rebuilding world". That really isn't true. The point of the stable/ branches is the kernel KBI is stable for the lifetime of the branch. > Also, there is de-facto no competition, short of a hard fork, in the software shipped. Sure. But you can implement a patch and advocate for it against the existing implementation? Also, there is a lot of support for installing alternatives from ports. Doesn't seem that major of a gap.
    - alacombe 7y ago
      > I don't know if you're familiar with FreeBSD's approach to backwards compatibility in general, or just making a general statement about monorepos. I'm a former NetBSD developer, I left when I got fed up to re-invent the wheel. I spent many years after that supporting a commercial special purpose FreeBSD-basde distribution, and I got a fair share of conflicts on mailing list again "the old guard" (Warner & co) over various subsystem, and had to go as far as calling off an incompetent kernel committer working for Intel at the time. All my grief from ~10 years ago is publicly available in the mailing-list archives. > FreeBSD's also got a Linux syscall emulation layer, which implements (some of) the Linux kernel's (stable) ABI. IIRC, it is mostly vestigial, unless it has been going though a major updates in the past 10 years. > That really isn't true. The point of the stable/ branches is the kernel KBI is stable for the lifetime of the branch. Branch lifetime is irrelevant. Linux makes backward compatibility an utmost paradigm. I'm sure a 2.4 era binary will still work on 5.4, nearly 15 years later. > Sure. But you can implement a patch and advocate for it against the existing implementation? Unless you are a committer, the chance of getting ANY significant patch in is pretty much nil. As I mentioned previously, mailing list are NOT for discussing any significant changes, this is done behind the scene in private by a de-facto pseudo-"committee". The development process is closed to a few elites, generally small group of committers ruling over code sections. By the time any patch is ready, its author drops a +5000,-5000 lines turd^Wdiff that is utterly impossible to review. For lack of a better word, BSD are not remotely close to being open to outsiders. I know this by experience.
      - LargoLasskhyfv 7y ago
        >Linux makes backward compatibility an utmost paradigm. I'm sure a 2.4 era binary will still work on 5.4, nearly 15 years later. Why then is it that i'm locked to the kernel versions required by the binary blobs from proprietary vendors in the embedded space? Be it smartphones, home/SOHO routers, and so on. Are they doing it wrong? Am I? My ISP provided CPE runs Kernel 2.6.32.61 right now. Not to mention the crap uncounted Android devices (not mine, in the world out there) are running.
        7y ago

loeg 7y ago

I didn't try to say FreeBSD doesn't have detracting politics (I don't think I said that) — you're absolutely right; it does. My understanding, and let me know if I'm totally wrong, is that most glibc developers are not Linux kernel developers, and that most kernel developers are not glibc developers. In FreeBSD, I think there's more crossover of developers working on both userspace and kernel components. The monorepo design helps foster that (again, subjective, IMO).

alacombe 7y ago
The monorepo is actually a downside as it weaken any form of backward compatibility one could legitimately expect. The general answer in these case "rebuild", but it completely ignores binary-only software which exists in the real world and which is to a large extend completely ignored by commiters. At some point, you want to spend CPU cycle on something else than "rebuilding world". Also, there is de-facto no competition, short of a hard fork, in the software shipped. You can't just "switch to uclibc" if an embedded platform has memory constraint.
- loeg 7y ago
  I don't know if you're familiar with FreeBSD's approach to backwards compatibility in general, or just making a general statement about monorepos. It doesn't seem like you're familiar with FreeBSD in practice; apologies if I guessed wrong. FreeBSD has strong backwards compatibility at the shared library level, across all versions. Support for BSD 4.3 (as in, 1986, pre-FreeBSD) compatibility is slowly being phased out in 2019. Grep around for COMPAT_FREEBSD, for example. This compatibility (for existing stable releases) is by and large maintained in the development branch. FreeBSD's also got a Linux syscall emulation layer, which implements (some of) the Linux kernel's (stable) ABI. > The general answer in these case "rebuild", but it completely ignores binary-only software which exists in the real world and which is to a large extend completely ignored by commiters. At some point, you want to spend CPU cycle on something else than "rebuilding world". That really isn't true. The point of the stable/ branches is the kernel KBI is stable for the lifetime of the branch. > Also, there is de-facto no competition, short of a hard fork, in the software shipped. Sure. But you can implement a patch and advocate for it against the existing implementation? Also, there is a lot of support for installing alternatives from ports. Doesn't seem that major of a gap.
  - alacombe 7y ago
    > I don't know if you're familiar with FreeBSD's approach to backwards compatibility in general, or just making a general statement about monorepos. I'm a former NetBSD developer, I left when I got fed up to re-invent the wheel. I spent many years after that supporting a commercial special purpose FreeBSD-basde distribution, and I got a fair share of conflicts on mailing list again "the old guard" (Warner & co) over various subsystem, and had to go as far as calling off an incompetent kernel committer working for Intel at the time. All my grief from ~10 years ago is publicly available in the mailing-list archives. > FreeBSD's also got a Linux syscall emulation layer, which implements (some of) the Linux kernel's (stable) ABI. IIRC, it is mostly vestigial, unless it has been going though a major updates in the past 10 years. > That really isn't true. The point of the stable/ branches is the kernel KBI is stable for the lifetime of the branch. Branch lifetime is irrelevant. Linux makes backward compatibility an utmost paradigm. I'm sure a 2.4 era binary will still work on 5.4, nearly 15 years later. > Sure. But you can implement a patch and advocate for it against the existing implementation? Unless you are a committer, the chance of getting ANY significant patch in is pretty much nil. As I mentioned previously, mailing list are NOT for discussing any significant changes, this is done behind the scene in private by a de-facto pseudo-"committee". The development process is closed to a few elites, generally small group of committers ruling over code sections. By the time any patch is ready, its author drops a +5000,-5000 lines turd^Wdiff that is utterly impossible to review. For lack of a better word, BSD are not remotely close to being open to outsiders. I know this by experience.
    - LargoLasskhyfv 7y ago
      >Linux makes backward compatibility an utmost paradigm. I'm sure a 2.4 era binary will still work on 5.4, nearly 15 years later. Why then is it that i'm locked to the kernel versions required by the binary blobs from proprietary vendors in the embedded space? Be it smartphones, home/SOHO routers, and so on. Are they doing it wrong? Am I? My ISP provided CPE runs Kernel 2.6.32.61 right now. Not to mention the crap uncounted Android devices (not mine, in the world out there) are running.
      - 7y ago