What features are you excited about for FreeBSD 12?

[olli@]

My main reason for updating to FreeBSD 12 (actually stable/12, to be exact) are improvements in the NVMe support and TRIM, because my new hardware includes an NVMe SSD that can do 3 GB/s (read and write), and I want to make good use of it.

There are also some improvements to bhyve, but it still doesn't support pass-through of CD / DVD / BD drives, so I'm stuck with VirtualBox which supports that.

 

[DriverBuilder]

Now Supervisor Mode Access Prevention(SMAP) works as expected in 12.0-RELEASE.

 

[joggx]

As the title says!

I'm personally excited for:

- ZFS RAID-Z expansion
- ZFS device removal
- pkg base
- other stuff I'll probably remember after this post

Any features, enhancements, new additions that get you hyped up? Lay it all down here!

Where you found these info?

https://www.freebsd.org/releases/12.0R/relnotes.html#storage-zfs

 

[chrcol]

Or compare this :
https://www.freebsd.org/releases/9.0R/relnotes.html

to this :

https://www.freebsd.org/releases/12.0R/relnotes.html ?

The official relnotes has always been pretty bad. Hence these alternative url's.

How can I comment on my favourite new Feature if I dont know what the new features are?

 

[chrcol]

The Clang change isn't a problem unless you can prove that it breaks a userland API/ABI (go ahead and prove me wrong, I doubt you can), that's what the stability in FreeBSD is all about and not about whether the tools used to build the programs are this version or that version.

Well for me I have to audit every compiler change, as need predictable behaviours in binaries. I got round this by using a specific version of a compiler from the ports tree instead of base compiler, but now the ports tree maintainers have started removing compilers that are not EOL upstream. Which makes it hard to rely on a compiler version in the ports tree as well, because the removal of compilers is now unpredictable and not in line with support policies upstream anymore.

Compiler development tends to be ahead of other software development, so a compiler gets released, and then there is a time lag for software developers to catch up and make their software work properly with that compiler, but if the OS is always on the latest bleeding edge compiler you dont get that 'matured' advantage.

Now if as you said the only concern is userland code, then perhaps that concern needs to be widened a bit, I know in the past the base compiler had to be stable on all ports as well.

I am looking at this from a LTS perspective, whilst FreeBSD seems to be gradually moving more and more to a rapid development model, other OS's have done the same but tend to have alternative policies in place for LTS user's as well.

 

[ralphbsz]

Well for me I have to audit every compiler change, as need predictable behaviours in binaries.

Purely out of curiosity: Can you explain why you care so much? For example, if the compiler maintainers improve the code generator or optimizer slightly, and create a nearly equivalent but faster instruction sequence, why would this create problems for you? At what level do you really care about the binary being predictable? Perhaps you could (should?) have the compiler run only once, and take its output and check it into your change control system and rely on it?

I'm just interested in why someone would go to the extreme of auditing the generated code, that's an interesting workflow.