What to expect on upcoming 15.0-RELEASE

[POSIX.1]

The schedule you might know already:

FreeBSD 15.0 Release Process

FreeBSD is an operating system used to power modern servers, desktops, and embedded platforms.

www.freebsd.org

But here is what to expect:

FreeBSD 15.0 Planning - HackMD

Things that have been committed to the tree.

hackmd.io

The only thing I hope that does not happen is this: 32-bit platform deprecation

 

[fmc000]

Well, in "Want" I see:

Support for rust in the kernel
Support for rust in userland

I really hope it doesn't happen.

 

[sko]

The only thing I hope that does not happen is this: 32-bit platform deprecation

General Notes Regarding Future FreeBSDReleases​

FreeBSD 15.0 is not expected to include support for 32-bitplatforms other than armv7. The armv6, i386, and powerpc platformsare deprecated and will be removed. 64-bit systems will still beable to run older 32-bit binaries.

This has been announced for a long time. Pretty much everything i386 is more useful as a boat anchor or doorstop nowadays than to run a modern OS...

 

[SirDice]

The only thing I hope that does not happen is this: 32-bit platform deprecation

Already happened in 15.0-CURRENT, so definitely going to be the case for 15.0-RELEASE.

And i386 was already demoted to Tier 2 on the 13 major branch.

Platforms

FreeBSD is an operating system used to power modern servers, desktops, and embedded platforms.

www.freebsd.org

 

[POSIX.1]

And i386 was already demoted to Tier 2 on the 14 major branch.

Yeah I know, and that did bite me unexpected, and cost me not a few bugs for hardware replacement.

 

[sko]

unexpected? It has been in all releasenotes for over a year (since 13.2-RELEASE and 14.0-RELEASE) and deprecation has been announced well before that when i386 was demoted to TIER2.

 

[Geezer]

Will it be possible to run 32 bit windows programs in wine on 15.0?

 

[SirDice]

FREEBSD32 and lib32 will still be there, there just won't be a i386 release image any more (or the ability to create one).

 

[mer]

Well, in "Want" I see:

Support for rust in the kernel
Support for rust in userland

I really hope it doesn't happen.

Support in userland. What exactly would that look like? Would it be similar to libc stuff, but maybe tied to a specific version of Rust? That's what I think it may look.

Support in the kernel? I think that horse has been rode hard and put up wet.

I'm more interested in the words around pkgbase. To me it sounds like pkgbase is going to be the default for 15; is that a correct assumption?
If so, definitely a "ZFS new BE to upgrade" is in order.

 

[POSIX.1]

unexpected?

sko yes unexpected. That was 2020

the bump to i686 was originally committed to head in base r353936, after base r352030 bumped it to i586 at first. On 2020-01-07, so already 11 months ago, this was all merged back to stable/12 in base r356460, as part of the clang 9.0.0 merge. Similarly, on 2020-05-05 for stable/11, in base r360658.


Konstantin Belousov

2020-11-01 12:44:31 UTC

(In reply to Dimitry Andric from comment #4)
I was just surprised that this change went into 12.x, at least without loud
announcement. More, I suggest to take a look at
https://www.freebsd.org/releases/12.2R/relnotes.html
11.1. Default CPUTYPE Change

Shit happens!

 

[SirDice]

Erhm, that was a switch from building for 80386 to 80486 and later on at minimum a Pentium class CPU. Has nothing to do with 32 vs 64 bit. You could still rebuild world to work on a 386.

 

[RetroComputingCollector]

Support for rust in the kernel

Support for rust in userland

Why don't we just open the floodgates and include INTERCAL‽ /s I can't belive people are still trying to cram these trendy languages (or as I call them, fadlangs) into base. I bet soon someone will suggest integrating a garbage collector into the kernel.

 

[mer]

I bet soon someone will suggest integrating a garbage collector into the kernel.

Don't some of the Mach-based variants have a GC? One could argue that a lot of memory algorithms have a lot of similarities to GC.

 

[RetroComputingCollector]

Don't some of the Mach-based variants have a GC? One could argue that a lot of memory algorithms have a lot of similarities to GC.

Good point. I was thinking more along the lines of "because there is now a GC, let's never do any memory management ever again".

 

[hpnothp]

I'm scared by "UCL-fication" - gradually rewriting system config files to UCL:Universal Configuration Language. In 15.0 there is such plan for login.conf, but more will likely come in future.

Here is screenshot from Allan's presentation showing "improved crontab" - rewritten to UCL - do we really want that?

Source: https://papers.freebsd.org/2015/bsdcan/allanjude-UCL.files/allanjude-UCL-slides.pdf, page 9.

Personally I hope that such "innovation" (so much similar to current Linux devastation by corporations) will not materialize...

Disclaimer: I don't mind using UCL for new components (or not "standardized" components) as pkg.conf. But we should keep system configuration files (crontab,syslog,...) intact to keep Unix as Unix - there is nothing wrong with so called DSL "Domain specific language" concept - using custom configuration format for specific program. Only this way we can survive long term, all those bubbles (remembering when only XML was right format for everything, next YAML, next JSON, next....).

 

[nxjoseph]

I'm scared by "UCL-fication" - gradually rewriting system config files to UCL:Universal Configuration Language. In 15.0 there is such plan for login.conf, but more will likely come in future.

Here is screenshot from Allan's presentation showing "improved crontab" - rewritten to UCL - do we really want that?
View attachment 23280
Source: https://papers.freebsd.org/2015/bsdcan/allanjude-UCL.files/allanjude-UCL-slides.pdf, page 9.

Personally I hope that such "innovation" (so much similar to current Linux devastation by corporations) will not materialize...

Disclaimer: I don't mind using UCL for new components (or not "standardized" components) as pkg.conf. But we should keep system configuration files (crontab,syslog,...) intact to keep Unix as Unix - there is nothing wrong with so called DSL "Domain specific language" concept - using custom configuration format for specific program. Only this way we can survive long term, all those bubbles (remembering when only XML was right format for everything, next YAML, next JSON, next....).

Indeed, I agree with you on this.

 

[POSIX.1]

Michael W Lucas on UCL:

Have you ever looked at a JSON configuration and thought, That could be a regular Unix text file? YAML and JSON and Unix text all represent similar data in different formats. Each has strengths and weaknesses, and each has syntactical idiosyncracies that earn them devotees. JSON might be the most complete configuration store, but it’s not designed to be written by hand and very few people advocate doing so. YAML looks writable, until it fails to validate. Even plain text can go wrong. Every format is full of failure.

Universal Configuration Language (UCL) brings all these failures together. UCL-aware tools can read Unix-style text configurations as well as various JSONs, YAML, and messagepack. They can output configurations in any of these formats. If it makes sense for you to configure an application in YAML, do that. If someone else needs the same application to use Unix-style text configuration, that’s fine. UCL also simplifies programmatic configuration changes.

 

[xibo]

pkgbase and hardware tracing support.

From the "future" features that have not yet been announced to be making it into 15.0, I hope to get ASPM and better Saphire Rapids / Eagle Stream platform support in 15.0...

... and better WiFi. Though our poor WiFi support doesn't affect me directly right now, better WiFi support will end up with more people running FreeBSD on laptops, which will result in hard lobbying for better platform support for AlderLake and its successors, which in return will fix half of the Saphire Rapids bugs, while more laptop users also implies more IDE setups and therefore more third party software being developed on and tested against FreeBSD once more people actually use FreeBSD as their primary OS, rather then in some deploy-and-forget HyperV / Proxmox instances.

 

[T-Aoki]

Indeed, I agree with you on this.

UCL is far more readable. So I would prefer:

• Keep existing codes as-is.
• Add converter (uni-directional or bi-directional) between UCL-based config and legacy config.
• Allow direct editing of legacy (actually used) config, if reverse conversion is possible or configured NOT to use UCL version of config.

What I imagine is vipw that edits /etc/master.passwd and invokes conversion to shadow passwd (/etc/spwd.db).