8 ms·

It's not Rust, it's FreeBSD (and LLVM)

32 points by smatija 2y ago

deleted 2y ago
[deleted]
irdc 2y ago
Putting all of a BSD in separate packages is going to make evolving the various parts together more difficult. See for instance the ease with which OpenBSD does ABI changes (I know FreeBSD doesn’t do that, just an illustration).
- crest 2y ago
  I'm using package base on FreeBSD 14.0 and 14.1. Upgrading the system worked as expected. FreeBSD already has a documented official way to deal with ABI breakages. You're supposed to install the new kernel only, reboot, install rest of the new release (including updating /etc) and reboot again. Next upgrade the installed ports/packages. Afterward delete the old files (and libraries) and reboot again. Upgrading/reinstalling all installed packages during the userland upgrade after the first reboot takes care of that on a package base installation whenever the ABI triple changes. If you're using ZFS boot environments they provide an even faster and safer way to upgrade without rebooting in between steps by creating a new boot environment from the currently active one, mounting it as a jail (or chroot env) and pointing the package manager at the mountpoint. Neither OpenBSD nor FreeBSD are still commonly used without at least one binary package installed so the complexity of having a package manager that works isn't optional.
Y_Y 2y ago
I wonder if they could use tcc or similar and get a reasonable system. Hopefully someone familiar with BSD can expand on the quest for a suitably licensed compiler.
- janice1999 2y ago
  Hasn't LLVM solved their license requirements already (at the cost of removing some niche CPU targets)?
  - irdc 2y ago
    It’s still Apache 2.0 with LLVM exceptions. Which is not BSD-compatible.
    - Pet_Ant 2y ago
      What are the material differences between the BSD and Apache? Is it just the fact that it's not litterally BSD licensed?
      - irdc 2y ago
        The Apache 2.0 license includes a patent grant.
  - Y_Y 2y ago
    As I inderstood it, the point of phk's post was the LLVM shouldn't be considered part of FreeBSD (src) and is unreasonably large.
    - crest 2y ago
      Yes clang used bootstrap in a similar time to its contemporary GCC version and compile code notably faster at the cost of emitting slightly less optimised code. Over the years LLVM became bloated. It's now by far the biggest and slowest to compile part of the FreeBSD base system, but there are only two useable open source C and C++ compilers and GCC isn't acceptable to the existing userbase because they changed their license to GPLv3. Also modern GCC isn't nearly as small as GCC 4.2 used to be.
klez 2y ago
I'm not sure I understood what this was all about. I guess I'm missing some context. Can someone please help me understand?
- janice1999 2y ago
  There's ongoing debate in the Linux community about the use of Rust in the Linux kernel (e.g. wrapping existing APIs safely for driver development). This heated up recently. Use of Rust puts requirements on the kernel developers to specify a Rust compiler version to use and ensure C code changes do not break Rust code and vice versa. This has triggered discussions in other communities. The linked discussion is amongst FreeBSD developers about how to conceptualize FreeBSD itself (where compilers, kernel, userspace and ported application code lives) and where compilers like Rust fit into that vision in the future. Unlike Linux, which is just a kernel, FreeBSD is a kernel + userspace + compiler (equivalent to the GNU part of GNU/Linux + GCC or LLVM).
  - steveklabnik 2y ago
    > ensure C code changes do not break Rust code This is not true. C code is allowed to break Rust bindings. The Rust For Linux folks will then go fix it. The C side was repeatedly told this, but doesn’t seem to want to hear it.
    - janice1999 2y ago
      As far as I understand it, that is only in the short term for the file system experiment where Rust is a "second class citizen" as Ted T'so put it.
      - steveklabnik 2y ago
        Nobody has decided what the post-experiment policy will be. A second language is new grounds for the kernel. Ted is assuming in order to interfere with the experiment.
    - anon-3988 2y ago
vermaden 2y ago
Why have LLVM in FreeBSD Base System if I have to add additional LLVM by Ports or package? % pkg info|grep Clang llvm15-15.0.7_10 LLVM and Clang IMHO both Rust and LLVM should be OUT of Base System.
- yjftsjthsd-h 2y ago
  Because the compiler in base necessarily has the same life cycle as base, while ports lets you rotate new versions in whenever you want.
  - vermaden 2y ago
    I know - but I would like to see an option that 'forces' the use of Base System compiler instead of building/installing another one ...
- crest 2y ago
  FreeBSD has always been able to self-host (build the itself from source) with just whats available in the FreeBSD src repository. To do this it needs a toolchain that includes among other things a linker, an assembler, and a C and C++ compiler. This used to be GCC, but GCC was replaced with clang which is a C and C++ frontend for LLVM. Just sticking to the last GCC 4.x release under GPLv2 forever wasn't an option and neither was importing a GPLv3 toolchain. Clang also brought some welcome advantages (it used to provide a lot more useful and human readable error messages, better code analysis tools to catch common bugs). The reasons you have different versions of LLVM in the ports tree is that users either directly require a specific version or other ports require a specific LLVM version as a dependency (e.g. compilers for Rust, Haskell, Julia, etc.). There will never be a situation where every user and every port is happy at the same time with just one LLVM version, because LLVM isn't just the compiler frontends, but also the C++ libraries used to implement compilers and API changes with each release. And even if the compilers available in the ports tree using LLVM as their code generation backend could be patched to build with the latest version, which would already be an unreasonable demand on their port maintainers. The new LLVM release may add new optimisations that are "legal" to a language lawyering compiler writer according to their understanding of the LLVM IR semantics, but still break existing code by exploiting undefined, under defined, or implementation specific behaviour. The problem with moving the system compiler out of the ports goes deeper than just the self hosting aspect. The binary package repositories compiled from the ports tree must work for all still supported minor releases on that major release line (e.g. https://pkg.freebsd.org/FreeBSD:14:amd64/latest/ https://pkg.freebsd.org/FreeBSD:14:amd64/latest/ works for both 14.0 and 14.1). Given that the supported lifetimes of minor releases in a major release line overlap and that compilers don't provide perfect binary compatibility this would lock in the compiler for the whole major release to whatever was packaged for the .0 release. Do you want to be restricted to C and C++ language version and instruction set support from 5 years ago by the end of a major release line? Stuck dealing with compiler bugs that have been fixed ages ago, but never backported? I would like to see full support for external toolchains from ports before anyone dares to evict the compilers from the base system even if LLVM is a bloated enough to dominate the build time and install size.

32 points by smatija 2y ago

deleted 2y ago

[deleted]

irdc 2y ago

Putting all of a BSD in separate packages is going to make evolving the various parts together more difficult. See for instance the ease with which OpenBSD does ABI changes (I know FreeBSD doesn’t do that, just an illustration).

crest 2y ago
I'm using package base on FreeBSD 14.0 and 14.1. Upgrading the system worked as expected. FreeBSD already has a documented official way to deal with ABI breakages. You're supposed to install the new kernel only, reboot, install rest of the new release (including updating /etc) and reboot again. Next upgrade the installed ports/packages. Afterward delete the old files (and libraries) and reboot again. Upgrading/reinstalling all installed packages during the userland upgrade after the first reboot takes care of that on a package base installation whenever the ABI triple changes. If you're using ZFS boot environments they provide an even faster and safer way to upgrade without rebooting in between steps by creating a new boot environment from the currently active one, mounting it as a jail (or chroot env) and pointing the package manager at the mountpoint. Neither OpenBSD nor FreeBSD are still commonly used without at least one binary package installed so the complexity of having a package manager that works isn't optional.

Y_Y 2y ago

I wonder if they could use tcc or similar and get a reasonable system. Hopefully someone familiar with BSD can expand on the quest for a suitably licensed compiler.

janice1999 2y ago
Hasn't LLVM solved their license requirements already (at the cost of removing some niche CPU targets)?
- irdc 2y ago
  It’s still Apache 2.0 with LLVM exceptions. Which is not BSD-compatible.
  - Pet_Ant 2y ago
    What are the material differences between the BSD and Apache? Is it just the fact that it's not litterally BSD licensed?
    - irdc 2y ago
      The Apache 2.0 license includes a patent grant.
- Y_Y 2y ago
  As I inderstood it, the point of phk's post was the LLVM shouldn't be considered part of FreeBSD (src) and is unreasonably large.
  - crest 2y ago
    Yes clang used bootstrap in a similar time to its contemporary GCC version and compile code notably faster at the cost of emitting slightly less optimised code. Over the years LLVM became bloated. It's now by far the biggest and slowest to compile part of the FreeBSD base system, but there are only two useable open source C and C++ compilers and GCC isn't acceptable to the existing userbase because they changed their license to GPLv3. Also modern GCC isn't nearly as small as GCC 4.2 used to be.

klez 2y ago

I'm not sure I understood what this was all about. I guess I'm missing some context. Can someone please help me understand?

janice1999 2y ago
There's ongoing debate in the Linux community about the use of Rust in the Linux kernel (e.g. wrapping existing APIs safely for driver development). This heated up recently. Use of Rust puts requirements on the kernel developers to specify a Rust compiler version to use and ensure C code changes do not break Rust code and vice versa. This has triggered discussions in other communities. The linked discussion is amongst FreeBSD developers about how to conceptualize FreeBSD itself (where compilers, kernel, userspace and ported application code lives) and where compilers like Rust fit into that vision in the future. Unlike Linux, which is just a kernel, FreeBSD is a kernel + userspace + compiler (equivalent to the GNU part of GNU/Linux + GCC or LLVM).
- steveklabnik 2y ago
  > ensure C code changes do not break Rust code This is not true. C code is allowed to break Rust bindings. The Rust For Linux folks will then go fix it. The C side was repeatedly told this, but doesn’t seem to want to hear it.
  - janice1999 2y ago
    As far as I understand it, that is only in the short term for the file system experiment where Rust is a "second class citizen" as Ted T'so put it.
    - steveklabnik 2y ago
      Nobody has decided what the post-experiment policy will be. A second language is new grounds for the kernel. Ted is assuming in order to interfere with the experiment.
  - anon-3988 2y ago

vermaden 2y ago

Why have LLVM in FreeBSD Base System if I have to add additional LLVM by Ports or package? % pkg info|grep Clang llvm15-15.0.7_10 LLVM and Clang IMHO both Rust and LLVM should be OUT of Base System.

yjftsjthsd-h 2y ago
Because the compiler in base necessarily has the same life cycle as base, while ports lets you rotate new versions in whenever you want.
- vermaden 2y ago
  I know - but I would like to see an option that 'forces' the use of Base System compiler instead of building/installing another one ...
crest 2y ago
FreeBSD has always been able to self-host (build the itself from source) with just whats available in the FreeBSD src repository. To do this it needs a toolchain that includes among other things a linker, an assembler, and a C and C++ compiler. This used to be GCC, but GCC was replaced with clang which is a C and C++ frontend for LLVM. Just sticking to the last GCC 4.x release under GPLv2 forever wasn't an option and neither was importing a GPLv3 toolchain. Clang also brought some welcome advantages (it used to provide a lot more useful and human readable error messages, better code analysis tools to catch common bugs). The reasons you have different versions of LLVM in the ports tree is that users either directly require a specific version or other ports require a specific LLVM version as a dependency (e.g. compilers for Rust, Haskell, Julia, etc.). There will never be a situation where every user and every port is happy at the same time with just one LLVM version, because LLVM isn't just the compiler frontends, but also the C++ libraries used to implement compilers and API changes with each release. And even if the compilers available in the ports tree using LLVM as their code generation backend could be patched to build with the latest version, which would already be an unreasonable demand on their port maintainers. The new LLVM release may add new optimisations that are "legal" to a language lawyering compiler writer according to their understanding of the LLVM IR semantics, but still break existing code by exploiting undefined, under defined, or implementation specific behaviour. The problem with moving the system compiler out of the ports goes deeper than just the self hosting aspect. The binary package repositories compiled from the ports tree must work for all still supported minor releases on that major release line (e.g. https://pkg.freebsd.org/FreeBSD:14:amd64/latest/ https://pkg.freebsd.org/FreeBSD:14:amd64/latest/ works for both 14.0 and 14.1). Given that the supported lifetimes of minor releases in a major release line overlap and that compilers don't provide perfect binary compatibility this would lock in the compiler for the whole major release to whatever was packaged for the .0 release. Do you want to be restricted to C and C++ language version and instruction set support from 5 years ago by the end of a major release line? Stuck dealing with compiler bugs that have been fixed ages ago, but never backported? I would like to see full support for external toolchains from ports before anyone dares to evict the compilers from the base system even if LLVM is a bloated enough to dominate the build time and install size.