# FreeBSD 13 features



## rootbert (Dec 18, 2020)

I do not follow -current closely. However, when I read the release schedule I became excited ... roughly 3 months to go. What featues will we get, maybe a dev or someone with more knowledge could provide some quick overview, or give a link to relevant mails in the mailing lists.

I am interested in the migration to OpenZFS 2.0, bhyve pause/migrate + other features/speedups, NFS+TLS, better wifi support (.ac, hostapd, ath10k driver...), linux compatibility layer, wireguard kernel integration, all stuff security related or performance improving (especially regarding the issues I have with swapping/memory), stuff around jails ...


----------



## SirDice (Dec 18, 2020)

There's often a nice list here: https://wiki.freebsd.org/WhatsNew 
But it looks like it hasn't been added for 13 yet.

Release notes haven't been written yet either, but that's typically done when things are being finalized. Up to the code slush things can still change quite a bit. Once stable/13 has been created things are more or less set and no major changes can happen.


----------



## a6h (Dec 18, 2020)

I.. FreeBSD 13.0 Process   | HackMD
II. FreeBSD 14.0 Planning | HackMD


----------



## rootbert (Dec 18, 2020)

oh, yes, forgot p9fs for bhyve to mention - great ... wireguard in kernel seems like it is planned for version 14, also 802.11ac, VPP on netmap, eBPF and - oh wow! - NetBSDs NPF. 

And I really hope we get veriexec - see https://reviews.freebsd.org/D8554


----------



## a6h (Dec 18, 2020)

rootbert said:


> oh, yes, forgot p9fs for bhyve to mention - great ... wireguard in kernel seems like it is planned for version 14, also 802.11ac, VPP on netmap, eBPF and - oh wow! - NetBSDs NPF.


There was a detailed discussion about some of these features on the last day of "November 2020 FreeBSD Vendor Summit".
I can't exactly the timestamp, but it's available online on streaming video websites.


----------



## shkhln (Dec 18, 2020)

rootbert said:


> linux compatibility layer


Most of the Linuxulator improvements are already in 12.2.



rootbert said:


> And I really hope we get veriexec - see https://reviews.freebsd.org/D8554


This was merged 2.5 years ago. What's missing?


----------



## rootbert (Dec 18, 2020)

veriexec is comming - cool, merged in April 2019, see https://svnweb.freebsd.org/base?view=revision&revision=345830

The video of the devsummit 2019: 



_View: https://www.youtube.com/watch?v=mBJNLkMmb48_


----------



## shkhln (Dec 18, 2020)

rootbert said:


> veriexec is comming - cool, merged in April 2019, see https://svnweb.freebsd.org/base?view=revision&revision=345830


That utility is already there (since 12.1), but it doesn't look it's a part of the default build.


----------



## rootbert (Dec 31, 2020)

anyone knows the state of W^X (write xor execute) and whether we get full ASLR (and not just ASR)?


----------



## rootbert (Jan 4, 2021)

oh, and we get the great ~5x performance improvement on if_bridge by kp: https://reviews.freebsd.org/D24250 - great!


----------



## rootbert (Jan 19, 2021)

aaaand we get a new shiny bootloader: 



__ https://twitter.com/i/web/status/1348876680295636992_View: https://twitter.com/i/web/status/1348876680295636992_

also an update to the linuxulator, hopefully with chromium supporting netflix and spotify; also an update on openbsm and various improvements coming from netapp, pf performance improvements ((see link),  routing subsystem improvements ... (see quarterly report)


----------



## chrbr (Jan 19, 2021)

rootbert said:


> aaaand we get a new shiny bootloader:


Here I cannot resist to comment. The bootloader is visible for seconds. I have no idea why it should be more beautiful.


----------



## fraxamo (Jan 19, 2021)

chrbr said:


> The bootloader is visible for seconds


It is possible to pause it


----------



## Snurg (Jan 19, 2021)

I liked the simple bootloader from old FreeBSD best.
No "information" overload.
Instead, quick navigation between drives/partitions to boot.

Maybe one can implement this in Lua


----------



## olli@ (Jan 19, 2021)

chrbr said:


> Here I cannot resist to comment. The bootloader is visible for seconds. I have no idea why it should be more beautiful.


The advantage is that the graphics support (UEFI frame buffer) is available throughout the boot process (well, I assume it is, because it wouldn’t make sense otherwise). So you get a high-resolution console.


----------



## olli@ (Jan 19, 2021)

rootbert said:


> I do not follow -current closely. However, when I read the release schedule I became excited ... roughly 3 months to go. What featues will we get, maybe a dev or someone with more knowledge could provide some quick overview, or give a link to relevant mails in the mailing lists.


It is not only interesting what new things are coming, but also what old things are going away. FreeBSD 13 will drop support for quite a few things, see https://wiki.freebsd.org/WhatsGoing/FreeBSD13 for details.


----------



## msplsh (Jan 19, 2021)

olli@ said:


> FreeBSD 13 will drop support for quite a few things, see https://wiki.freebsd.org/WhatsGoing/FreeBSD13 for details.


This page admittedly isn't even complete.  It would be nice to have better comms about this.  The kind of chatter in the telnet comments section is what I would appreciate.


----------



## rootbert (Jan 21, 2021)

this one also seems what I am so looking for: https://reviews.freebsd.org/D28270 - bhyve warm migration. Hope we get it for 13, and hopefully it will also work with HAST


----------



## Lars Skogstad (Mar 10, 2021)

Anyone noticed if something will actually break? Like common packages etc?


----------



## richardtoohey2 (Mar 10, 2021)

Lars Skogstad said:


> Anyone noticed if something will actually break? Like common packages etc?


Do you have anything specific in mind?  I've installed on Intel NUC, Dell server (Poweredge T330 with hardware RAID5) and so on and UEFI installs work perfectly and the "common" packages I used (e.g. vim and MySQL) work fine.

Do you mean more desktop packages or browsers or something else?


----------



## drhowarddrfine (Mar 10, 2021)

Lars Skogstad said:


> Anyone noticed if something will actually break? Like common packages etc?


This isn't typically a concern and not anything I've ever noticed.


----------



## richardtoohey2 (Mar 11, 2021)

The Register has an article on FreeBSD 13.0









						License to thrill: Ahead of v13.0, the FreeBSD team talks about Linux and the completed toolchain project that changes everything
					

'For many ... vendors, the BSD license is very important compared to the GPL'




					www.theregister.com


----------



## scottro (Mar 11, 2021)

I've been running 13, hrrm, I think it's up to RC-1 last time I looked, for awhile, and it's not broken anything.  It *looks* like it's going to be a safe upgrade on my main machine. (But I will use beadm, just in case.).


----------



## richardtoohey2 (Mar 18, 2021)

rootbert said:


> wireguard kernel integration


Looks like this has ended up a bit messy, sadly: https://marc.info/?l=freebsd-hackers&m=161609423000677&w=2


----------



## sidetone (Mar 18, 2021)

The good thing about the bootloader having graphics through LUA, is that it means a console (not necessarily the default) can have the ability to show pictures on it, to start a basic graphical program (one not like not ncurses) without needing a window manager (or Windows like DOS used to do), or to split the screen between monitors. Not that this would be needed.

FreeBSD 13 looks great. LLVM and its toolchain is expected to be much better, and complete. Hopefully, 3 different versions of the toolchain will no longer be needed.


----------



## sidetone (Mar 18, 2021)

rootbert said:


> wireguard kernel integration





richardtoohey2 said:


> 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/


----------



## richardtoohey2 (Mar 19, 2021)

sidetone said:


> LLVM and its toolchain is expected to be much better, and complete. Hopefully, 3 different versions of the toolchain will no longer be needed.


Sadly not if you need to build MySQL from ports - it won't build with the base LLVM.


----------



## Argentum (Mar 19, 2021)

richardtoohey2 said:


> The Register has an article on FreeBSD 13.0
> 
> 
> 
> ...


Great article!


----------



## marcus123 (Mar 19, 2021)

I can't wait for it


----------



## Argentum (Mar 19, 2021)

marcus123 said:


> 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.


----------



## tankist02 (Mar 20, 2021)

Any progress on support of 802.11ac?


----------



## chrcol (Oct 6, 2021)

vigole said:


> I.. FreeBSD 13.0 Process   | HackMD
> II. FreeBSD 14.0 Planning | HackMD


These remind of the old updates pages someone used to maintain, thanks.


----------



## mrbeastie0x19 (Oct 6, 2021)

richardtoohey2 said:


> 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.


----------



## SirDice (Oct 6, 2021)

mrbeastie0x19 said:


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


Third-party software isn't covered by the FreeBSD roadmaps. This is about the OS itself, not third-party software.


----------



## mrbeastie0x19 (Oct 6, 2021)

SirDice said:


> 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.


----------



## SirDice (Oct 6, 2021)

mrbeastie0x19 said:


> 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.


----------



## mrbeastie0x19 (Oct 6, 2021)

SirDice said:


> 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?


----------



## richardtoohey2 (Oct 6, 2021)

I think the issue with MySQL has been fixed - so I think it will build with base llvm (at least on FreeBSD 13).


----------



## SirDice (Oct 6, 2021)

mrbeastie0x19 said:


> but do we need to include everything else along with it





mrbeastie0x19 said:


> Does the current ports infrastructure support library only packages?


At the moment the compiler ports/packages aren't split up. So you either get all or nothing.


----------



## grahamperrin@ (Oct 6, 2021)

mrbeastie0x19 said:


> tabular road map for base



▼









						Technology Roadmap
					

https://freebsdfoundation.org/blog/technology-roadmap/  Enjoy.




					forums.freebsd.org


----------



## astyle (Oct 6, 2021)

richardtoohey2 said:


> I think the issue with MySQL has been fixed - so I think it will build with base llvm (at least on FreeBSD 13).


Base 13-RELEASE only comes with Clang 9, which has been ripped out of devel/llvm90. The complete devel/llvm90 compiler stack is not in base. But that doesn't change my observation that databases/mysql57 can be compiled with just Clang.


----------



## richardtoohey2 (Oct 7, 2021)

astyle said:


> 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.


----------



## astyle (Oct 7, 2021)

richardtoohey2 said:


> 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.


----------



## mrbeastie0x19 (Oct 7, 2021)

richardtoohey2 said:


> 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.


----------



## sidetone (Oct 7, 2021)

mrbeastie0x19 said:


> 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.


----------



## astyle (Oct 7, 2021)

mrbeastie0x19 said:


> 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.
> 
> ...



Confusing what is really a part of what can lead to things not making sense down the road.


----------



## mrbeastie0x19 (Oct 7, 2021)

astyle said:


> 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.


----------



## astyle (Oct 7, 2021)

mrbeastie0x19 said:


> 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.


----------



## mrbeastie0x19 (Oct 7, 2021)

astyle said:


> 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.


And which linker does the clang compiler on FreeBSD use exactly?





__





						LLD - FreeBSD Wiki
					





					wiki.freebsd.org


----------



## astyle (Oct 7, 2021)

mrbeastie0x19 said:


> And which linker does the clang compiler on FreeBSD use exactly?
> 
> 
> 
> ...


Also ripped out of llvm90.  The wiki you linked to can very well lead one to conclude that Clang can use either LLD (if told to by the makefile) or the regular /usr/bin/ld.


----------



## mrbeastie0x19 (Oct 7, 2021)

astyle said:


> Also ripped out of llvm90.  The wiki you linked to can very well lead one to conclude that Clang can use either LLD (if told to by the makefile) or the regular /usr/bin/ld.


The regular /usr/bin/ld is the llvm linker.

You can clearly see from the source code https://github.com/freebsd/freebsd-src/tree/main/contrib/llvm-project









						freebsd-src/contrib/llvm-project/llvm at main · freebsd/freebsd-src
					

FreeBSD src tree (read-only mirror). Contribute to freebsd/freebsd-src development by creating an account on GitHub.




					github.com
				




If you can use the GNU tools like the linker with clang (which maybe u can with a little bit of work, as said Clang is only the front end) that isn't what the FreeBSD project IS doing (Probably because LLVM libraries are used at build time anyway) .


----------



## sidetone (Oct 7, 2021)

They're a part of each other, but the emphasis was on which was the main part, being llvm.

Either base and ports of LLVM/Clang, have been mixed sucessfully with parts of binutils and GCC. Other utility components from ports can be used too. The installs come fully for LLVM/Clang, but the components of LLVM/Clang or GCC and binutils used to compile can be adjusted through make.conf. Between newer FreeBSD versions, enough changes have occurred that this doesn't always work. Thread is-it-possible-to-buildworld-without-base-compilers-to-use-package-compilers.59874


----------

