What to expect on upcoming 15.0-RELEASE

POSIX.1 said:
The only thing I hope that does not happen is this: 32-bit platform deprecation
Click to expand...

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.
Click to expand...

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...
 
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.
 
fmc000 said:
Well, in "Want" I see:

Code: 
Support for rust in the kernel
Support for rust in userland

I really hope it doesn't happen.
Click to expand...
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.
 
sko said:
unexpected?
Click to expand...
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
freebsd_committer
freebsd_triage
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
Click to expand...
Shit happens!
 
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.
 
Code: 
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.
 
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?
fbsd-crontab-ucl.png

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....).
 
hpnothp said:
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....).
Click to expand...
Indeed, I agree with you on this.
 
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.
Click to expand...
Click to expand...
 
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.
 
nxjoseph said:
Indeed, I agree with you on this.
Click to expand...
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).
 
You must log in or register to reply here.
Back
Top