FreeBSD 13 features

wireguard kernel integration
Looks like this has ended up a bit messy, sadly: https://marc.info/?l=freebsd-hackers&m=161609423000677&w=2
WireGuard's status on FreeBSD has been the topic of two Ars Technica articles already this week:
* https://arstechnica.com/gadgets/202...on-its-way-to-freebsd-and-the-pfsense-router/
* https://arstechnica.com/gadgets/2021/03/freebsd-kernel-mode-wireguard-moves-forward-out-of-tree/ (this is the updated one)

Also, status on PFSense that it was pushed back to future release:
* https://pcper.com/2021/03/wireguard-is-coming-to-your-pfsense-router/
 
I can't wait for it
You can get it already. I have one experimental desktop system running. All good. Web browsers, MATE desktop, etc. A week to wait for official release, but I took an approach to install it early on non-critical machine to avoid any surprises when the release comes out.
 
Sadly not if you need to build MySQL from ports - it won't build with the base LLVM.
This is a big usability issue with the llvm compile times too, needs work for sure.

Would definitely be nice if there was a clear roadmap we could see, if there is one I cannot find it anywhere.

I know there was the article recently, but a clear table like one of the ones above would be good.
 
Third-party software isn't covered by the FreeBSD roadmaps. This is about the OS itself, not third-party software.
The quote was only meant for the first paragraph, I meant it would be nice if there was a tabular road map for base development so we knew what the priorities were.

And if you mean in relation to LLVM that we cannot fix what MySQL etc depends on, true enough, but the pkg infrastructure is developed by the base team, so ways to mitigate situations like that should definitely be welcomed, this is one area I did not notice on linux, I did not see packages pulling in gcc, only when they were built.

And another thing is if compilers are changing so we rapidly we keep needing so many versions of them, surely that is not very viable for long term? Building llvm takes a long time, downloading it is often the bottleneck of any package download.
 
I did not see packages pulling in gcc, only when they were built.
Some ports actually require the libraries that come with the compiler it's being built with. Some ports don't. So in some cases it's only a build dependency but in other cases it might be a run dependency too. Build dependencies are only required when actually building the port, they're not a dependency of the resulting package. With a run dependency they are a dependency of that package.
 
Some ports actually require the libraries that come with the compiler it's being built with. Some ports don't. So in some cases it's only a build dependency but in other cases it might be a run dependency too.
Yeah they require the libraries, but do we need to include everything else along with it? It seems there is a solution to this since rpm and deb already do it, and this is one area (of a small number of areas) the linux package management is better. Does the current ports infrastructure support library only packages?
 
But that doesn't change my observation that databases/mysql57 can be compiled with just Clang.
Yes, it can now - the port was changed. But when I wrote my original comment the port would pull in another version of llvm was pulled in which wasn't much fun.

It was this change in August that made things better for me: https://cgit.freebsd.org/ports/comm...e?id=974e13b50148c5c8e7b33a1cb7e9dbaa9aedbc70

EDIT: or have I misunderstood - is there something about Clang ("just Clang") that is different to llvm? Not being sarcastic, just thinking I might have missed a point.
 
EDIT: or have I misunderstood - is there something about Clang ("just Clang") that is different to llvm? Not being sarcastic, just thinking I might have missed a point.
Clang is part of the LLVM compiler stack. Clang is available either by itself, or as part of LLVM. FreeBSD 13-RELEASE includes just clang in the base, not the entire devel/llvm90 compiler stack.
 
Yes, it can now - the port was changed. But when I wrote my original comment the port would pull in another version of llvm was pulled in which wasn't much fun.

It was this change in August that made things better for me: https://cgit.freebsd.org/ports/comm...e?id=974e13b50148c5c8e7b33a1cb7e9dbaa9aedbc70

EDIT: or have I misunderstood - is there something about Clang ("just Clang") that is different to llvm? Not being sarcastic, just thinking I might have missed a point.
There is, LLVM is part of clang, but not actually clang, and some of the code generation is used by other packages at runtime like mesa for shaders. However imo that's precisely why it makes no sense to pull in clang when what you actually need is some of the LLVM headers only.
 
There is, LLVM is part of clang, but not actually clang, and some of the code generation is used by other packages at runtime like mesa for shaders. However imo that's precisely why it makes no sense to pull in clang when what you actually need is some of the LLVM headers only.
Because the toolchain isn't modular. A modular toolchain makes sense. However, they're against it, because, the only example they have of that is one which is described as a mess from Linux. It can actually work, and be better than anything, and not be anything like the bad example.

Maybe one version of llvm that's more capable could be available without clang. They also want to keep clang and llvm versions together.

I use packages for llvm/clang and other programming languages.
 
There is, LLVM is part of clang
It's the other way around. If you go to llvm.org, on the very front page, you will see that:

The primary sub-projects of LLVM are:

1. The LLVM Core libraries provide a modern source- and target-independent optimizer, along with code generation support for many popular CPUs (as well as some less common ones!) These libraries are built around a well specified code representation known as the LLVM intermediate representation ("LLVM IR"). The LLVM Core libraries are well documented, and it is particularly easy to invent your own language (or port an existing compiler) to use LLVM as an optimizer and code generator.

2. Clang is an "LLVM native" C/C++/Objective-C compiler, which aims to deliver amazingly fast compiles, extremely useful error and warning messages and to provide a platform for building great source level tools. The Clang Static Analyzer and clang-tidy are tools that automatically find bugs in your code, and are great examples of the sort of tools that can be built using the Clang frontend as a library to parse C/C++ code.

....

Confusing what is really a part of what can lead to things not making sense down the road.
 
It's the other way around. If you go to llvm.org, on the very front page, you will see that:



Confusing what is really a part of what can lead to things not making sense down the road.
If you revisit what I said, I said that LLVM is part of Clang, which is correct, you cannot have Clang without LLVM. Clang is the front end.

Just to be clear, you can have Clang without a backend but it would be pretty useless without the underlying linking tools and libraries for example, you'd need an entire new backend.
 
If you revisit what I said, I said that LLVM is part of Clang, which is correct, you cannot have Clang without LLVM. Clang is the front end.
13-RELEASE includes clang v. 9, but not devel/llvm90. LLVM is the umbrella under which Clang lives.

You made me do a Google search to verify your claims. And that turned up the idea that the FreeBSD project has been taking advantage of: Yes you can have Clang without LLVM.
 
Back
Top