FreeBSD Foundation Flounders on 15 with Rust, pkgbase, and KDE

JohnK said:
Rust userland/kernel: "Things that would be nice to have but aren't critical"
Click to expand...
But it wouldn't even be nice to have replace anything. What is the benefit of rewriting anything in Rust? What's wrong with C? Rust is a fad. In 40 years it might be a zombie like COBOL and just exist so people can maintain old software. That is my biggest fear about integrating fadlangs into base, with my second biggest being a massive buildworld time.
 
cracauer@ said:
Again, when did Rust enter this? I have never seen the Foundation push for Rust.
Click to expand...
Its simply a good example of a bad idea (in the kernel/base. Anywhere else, its fine minus the slight weakness it has with dependencies and C interop).

I don't believe the Foundation needs to push for something in order for a group of developers to add it. Things like Rust, PkgBase, KDE can be done by internal lobby groups right? Otherwise, the Foundation certainly seems to hold much more sway than it used to a decade ago.
 
RetroComputingCollector said:
I found this on the official 15.0 release notes. This is a nightmare. It seems like, to compete with Linux, the Foundation wants to turn BSD into Linux. I hate the idea of pkgbase being the only way to update FreeBSD. That is the main reason why I fled the Linux world. Furthermore, the KDE integration is also so Linuxy. I also hate the push for rust and zig and whatever is the new fad. FreeBSD is abandoning its UNIX roots to chase trends and imitate Linux. I probably will not end up switching to OpenBSD (atleast for the forseeable future), but this new route is concerning, to say the least.
Click to expand...

You assume that with switch to PKGBASE You will lose the distinction between FreeBSD Base System and third party packages - and it will be like with yum(8) on RHEL or like with apt(8) in Ubuntu ... IT WILL NOT.

Its just the Base System instead being 'just a bunch of files' - they will be 'organized' and packed into their pkg(8) compatible packages - and they will be served in a SEPARATE pkg(8) repository.

That means you can still upgrade just FreeBSD Base System with specifying the FreeBSD-base repository - like that:

# pkg upgrade -r FreeBSD-base

You can also upgrade only the packages with this:

# pkg upgrade -r FreeBSD

... and freebsd-update(8) is far from perfect - HardenedBSD after making the fork from FreeBSD even provided its own not delta based version called hbsd-update(8) instead.

You can not create your own on premise freebsd-update(8) infrastructure and update servers - but you can do that with PKGBASE:
- https://vermaden.wordpress.com/2023/12/09/personal-freebsd-pkgbase-update-server/

You can also convert any freebsd-update(8) system into PKGBASE if needed:
- https://vermaden.wordpress.com/2025/07/20/freebsd-pkgbase-pkgbasify-tool/

The freebsd-update(8) is also VERY interactive which is FAR from ideal for automation or updating large amount of machines or Jails.

... and no matter if you use freebsd-update(8) or pkg(8) with PKGBASE just remember to ALWAYS create new ZFS Boot Environments with beadm(8) or bectl(8) to have snapshot of a working system before the upgrade.

Hope that helps.
 
vermaden said:
You assume that with switch to PKGBASE You will lose the distinction between FreeBSD Base System and third party packages - and it will be like with yum(8) on RHEL or like with apt(8) in Ubuntu ... IT WILL NOT.

Its just the Base System instead being 'just a bunch of files' - they will be 'organized' and packed into their pkg(8) compatible packages - and they will be served in a SEPARATE pkg(8) repository.

That means you can still upgrade just FreeBSD Base System with specifying the FreeBSD-base repository - like that:

# pkg upgrade -r FreeBSD-base

You can also upgrade only the packages with this:

# pkg upgrade -r FreeBSD

... and freebsd-update(8) is far from perfect - HardenedBSD after making the fork from FreeBSD even provided its own not delta based version called hbsd-update(8) instead.

You can not create your own on premise freebsd-update(8) infrastructure and update servers - but you can do that with PKGBASE:
- https://vermaden.wordpress.com/2023/12/09/personal-freebsd-pkgbase-update-server/

You can also convert any freebsd-update(8) system into PKGBASE if needed:
- https://vermaden.wordpress.com/2025/07/20/freebsd-pkgbase-pkgbasify-tool/

The freebsd-update(8) is also VERY interactive which is FAR from ideal for automation or updating large amount of machines or Jails.

... and no matter if you use freebsd-update(8) or pkg(8) with PKGBASE just remember to ALWAYS create new ZFS Boot Environments with beadm(8) or bectl(8) to have snapshot of a working system before the upgrade.

Hope that helps.
Click to expand...
Thanks so much, but I still have a bome to pick with whoever decided that KDE was a good idea. Not to mention Rust.
 
vermaden good stuff as typical (I always look for the Monday Updates).
I think your second article points out to me:
If I install 15 in Traditional mode, is the pkgbasify.lua included or does that still need to be fetched from git?
 
RetroComputingCollector said:

2024 FreeBSD Developer Summit: Integration with Rust | FreeBSD Foundation

Presenter: Various contributors The discussion on integrating Rust into FreeBSD, which spun off of the FreeBSD 15 release planning sessions, highlighted the potential benefits and the challenges of adopting the memory-safe programming language within the FreeBSD ecosystem. Contributors focused...
freebsdfoundation.org freebsdfoundation.org
Click to expand...

The Foundation has nothing to do with this. Developers on the developer summit can discuss any topic they want.

IIRC this was nothing but a big re-hash of the "Rust in userland" mailing list discussion.

I'll give you that the foundation didn't very accurately portrait that in their blog. I would have to re-watch the video.
 
RetroComputingCollector said:
But it wouldn't even be nice to have replace anything. What is the benefit of rewriting anything in Rust? What's wrong with C? Rust is a fad. In 40 years it might be a zombie like COBOL and just exist so people can maintain old software. That is my biggest fear about integrating fadlangs into base, with my second biggest being a massive buildworld time.
Click to expand...
'Replace'? 'Rewrite'? ...what are you talking about?! That was about "support" and 'support' does not equal 'replace/rewrite'. At most it would mean providing libs and/or frameworks so rust developers can provide applications and whatnot.
 
vermaden said:
You assume that with switch to PKGBASE You will lose the distinction between FreeBSD Base System and third party packages - and it will be like with yum(8) on RHEL or like with apt(8) in Ubuntu ... IT WILL NOT.

Its just the Base System instead being 'just a bunch of files' - they will be 'organized' and packed into their pkg(8) compatible packages - and they will be served in a SEPARATE pkg(8) repository.
Click to expand...

My prediction still remains that SEPARATE pkg(8) repository will see a lot of churn. Way more than when it was a monolithic base set.
Is there any kind of guarantee or expression of interest from anyone developing this that they intend to keep it consistent? (or at least, as consistent as the current status quo).
 
mer said:
vermaden good stuff as typical (I always look for the Monday Updates).
I think your second article points out to me:
If I install 15 in Traditional mode, is the pkgbasify.lua included or does that still need to be fetched from git?
Click to expand...
Thanks.

If you boot 15-CURRENT installer - it even asks you now if you want 'classic' install or PKGBASE install.

As for the pkgbasify(8) tool - right now it needs to be fetched directly from its GitHub page.

... and PKGBASE is not limited to 15.x - you can also convert FreeBSD 14.x systems to PKGBASE with pkgbasify(8) tool.
 
RetroComputingCollector said:
Thanks so much, but I still have a bome to pick with whoever decided that KDE was a good idea. Not to mention Rust.
Click to expand...
I would prefer XFCE or MATE instead of KDE - but that is me.

There was even recent pools what FreeBSD users want - and yes - by general they want XFCE over KDE ... and a WM over any DE:
- https://reddit.com/r/freebsd_deskto...ce_and_kde_retain_lead_among_freebsd_desktop/

Image here:
xfce-and-kde-retain-lead-among-freebsd-desktop-users-as-the-v0-jhlng9ul4pef1.png


As for Rust - I would prefer to see Checked C instead of Rust rewrite - not because Rust is bad - its good - its that rewriting now OS feels pointless and very expensive task while Checked C (and other good programming techniques) just seems more reasonable.

It would be also very 'expensive' to have both CLANG and RUST compilers in the base - compilation times - space - time needed to fetch with online installs - same for updates - space on servers - servers bandwidth - and all that for ... just another programming language that seems to be more popular NOW ... it it would be up to me - I would continue with C and introduce Checked C and other 'C' improvements and do not import Rust and ... watch the World. Maybe Rust is the future - maybe its jest 'another' language.

Remember how big hype Ruby had in a day? Where is Ruby now? Exactly.
 
A lot of people on here, including me, have a different vision of what FreeBSD needs to be. While some don't see it, pkgbase allows more people to install FreeBSD closer to their vision.

I see pkgbase as an extended base, which is better standardized and better maintained than ports. Pkgbase can keep the install image smaller. Also, pkgbase can help coding cycles for programs, so improvements dont have to match cycles on FreeBSD release dates. Improvements can keep coming during FreeBSD major release code freezes. There's lots on pkgbase, like firewalls, GPIO and cleartext services which ports aren't reliant on or are of their own category of ports. This brings up, that some applications in src.conf require parts of kernel to be compiled in, consequently, pkgbase will require it. Thus, they have to consider, that they may need multiple kernels as well or a hybrid kernel.

For those who don't want a desktop at all, pkgbase can help them to not install video drivers.

Also, people say how pkgbase would make it no longer like what FreeBSD has been. In that case, they can make the argument for removing src.conf, as many people compile their userland, which is a complex process.

The only issue with pkgbase, would be the same one that exists when a computer boot ups with applications which are not in base, such as with a shell like ksh or video drivers needed that haven't been installed yet. For instance, a computer that has its boot up and root directory on zfs, would need a zfs bootstrap in the base system, and not on pkgbase. Either, best practices would be use zfs, but not on root and boot so all of zfs can be a pkgbase, or have a bootstrap for zfs in base so root and boot can boot the system.

I wish these topics were split, instead of being in one thread.

Rust in base? No. If you want that, use Redox, and use it with C programs on top, since C has one of the largest libraries of applications. Users who want Rust in base need to build Redox up, and use C programs to make up for what it now lacks, or use Linux.
 
vermaden said:
Its just the Base System instead being 'just a bunch of files' - they will be 'organized' and packed into their pkg(8) compatible packages - and they will be served in a SEPARATE pkg(8) repository.

That means you can still upgrade just FreeBSD Base System with specifying the FreeBSD-base repository - like that:

# pkg upgrade -r FreeBSD-base
Click to expand...
Yes, but what happens if I do pkg delete -af? Does it also remove the base install packages and completely hose the system? Or will I still have a base system?
 
vermaden said:
That means you can still upgrade just FreeBSD Base System with specifying the FreeBSD-base repository - like that:

# pkg upgrade -r FreeBSD-base

You can also upgrade only the packages with this:

# pkg upgrade -r FreeBSD
Click to expand...
SirDice said:
Yes, but what happens if I do pkg delete -af? Does it also remove the base install packages and completely hose the system? Or will I still have a base system?
Click to expand...
Pkgbase needs its own separate command than pkg, maybe plain pkgbase. It's enough that pkgbase saves compile time and complexity of implementing src.conf. For anyone who believes there shouldn't be a pkgbase at all, then there's whole threads on adjusting src.conf, and compiling and configuring that FreeBSD system.
 
sidetone said:
Pkgbase needs its own separate command than pkg, maybe plain pkgbase. It's enough that pkgbase saves compile time and complexity of implementing src.conf. For anyone who believes there shouldn't be a pkgbase at all, then there's whole threads on adjusting src.conf, and compiling and configuring that FreeBSD system.
Click to expand...
I hope someone suggests that in the mailing list.
 
sidetone said:
Pkgbase needs its own separate command than pkg,
Click to expand...
Don't think it should be a seperate command, but I do think the pkgbase packages will require some sort of protected status, so you don't entirely hose your system with pkg-delete(8), maybe one or more additional -f if you really, really wanted to remove them. As in pkg delete -afffffffff --allow-foot-shooting
 
kpedersen said:
In the same way that people would get annoyed if FreeBSD dropped support for laptops. What you call "gatekeeping" is actually called "calling out breakage and bad ideas".


You will see in the thread that the issue raised by many of us is not about how we install base; its about base being broken. Either the "entire base" will be polluted with crap. Or they will start picking holes in it; making it impossible to install an "entire base".

Just as seen with Linux package managers (and in many ways NPM/crates.io/PIP), if you make it too easy to add dependencies; people go overboard and technical debt builds. Whats to stop them adding random little packages (or removing SUS/POSIX stuff like awk/nvi) etc. Because its now "quick and easy".


I think that's in your mind. We want people to come to FreeBSD. We don't need to break the OS to do so. Not only can it stand on its own merit but honestly as Linux becomes less and less usable, FreeBSD kind of wins by default and is attracting people at a faster rate than ever.


Many do care about avoiding breakage. There are growing amounts of infighting; particularly around Rust in base (another bad idea as an example) as you probably know. FreeBSD compared to Linux is quite a slow moving and stable target; what do you think the reason is for that? Yes, the people driving it choose for it to be stable and move at a responsible pace.
Click to expand...
Pkgbase is not remotely like dropping support for laptops.

Removing stuff like awk (if it's not required for other packages!) is the entire point. If you don't need it, you don't install it! Too "easy" to add dependencies? It's pkgbase, as others have pointed out, not pkg. Different repo! You can still have the same requirements to add things to base!

I scoff at the idea that FreeBS is a "stable" target. Have you read /usr/ports/UPDATING ever? Surprise, you can suddenly have to do major port migration/maintenance if you just want to pick up a security update for a dependency...

Pkgbase isn't going to break FreeBSD. Freebsd-update was new at one time. Anybody remember pkgng? If anything, the tooling here is changing the least compared to the changes those brought.

It's going to let people strip FreeBSD down to run it for certain purposes in VMs, yes. Why does that even matter?
 
msplsh said:
Pkgbase is not remotely like dropping support for laptops.

Removing stuff like awk (if it's not required for other packages!) is the entire point. If you don't need it, you don't install it! Too "easy" to add dependencies? It's pkgbase, as others have pointed out, not pkg. Different repo! You can still have the same requirements to add things to base!

I scoff at the idea that FreeBS is a "stable" target. Have you read /usr/ports/UPDATING ever? Surprise, you can suddenly have to do major port migration/maintenance if you just want to pick up a security update for a dependency...

Pkgbase isn't going to break FreeBSD. Freebsd-update was new at one time. Anybody remember pkgng? If anything, the tooling here is changing the least compared to the changes those brought.

It's going to let people strip FreeBSD down to run it for certain purposes in VMs, yes. Why does that even matter?
Click to expand...
Maybe some deprecated base system features like ftpd could be resurrected in pkgbase! Someone should put that on the mailing list too.
 
SirDice said:
Don't think it should be a seperate command, but I do think the pkgbase packages will require some sort of protected status, so you don't entirely hose your system with pkg-delete(8), maybe one or more additional -f if you really, really wanted to remove them. As in pkg delete -afffffffff --allow-foot-shooting
Click to expand...
Yep. How many threads have showed up "pkg did something wrong when I did pkg autoremove -f"
 
msplsh said:
Removing stuff like awk (if it's not required for other packages!) is the entire point. If you don't need it, you don't install it! Too "easy" to add dependencies? It's pkgbase, as others have pointed out, not pkg. Different repo! You can still have the same requirements to add things to base!
Click to expand...
So you no longer will have a SUS/POSIX conforming platform. So any scripts requiring (and assuming) a sane UNIX-like environment will now fail (with confusing error messages). And you are going to need to explain why it all fails to new users on these support forums. Its going to be less user-friendly than ever before! And you accuse me of "gate keeping" haha.

msplsh said:
I scoff at the idea that FreeBS is a "stable" target. Have you read /usr/ports/UPDATING ever? Surprise, you can suddenly have to do major port migration/maintenance if you just want to pick up a security update for a dependency...
Click to expand...
And so making this worse helps this? As more changes accrue in base (and it will), this UPDATING tasks will only get larger. Actually, if base is no longer consistent, will an UPDATING file even be meaningful anymore? Its gonna potentially be a wild west like Linux is.

msplsh said:
Pkgbase isn't going to break FreeBSD.
Click to expand...
From your Awk example above, sounds like you will have already broken your install.

msplsh said:
It's going to let people strip FreeBSD down to run it for certain purposes in VMs, yes. Why does that even matter?
Click to expand...
If you want to rice a FreeBSD install, just a simple 'rm' in the bin directory is even easier.

mer said:
That is a possibility, but I maybe a process can be setup to reduce that. It means people have to actually care
Click to expand...
Care *and* be organised. Open-source is not the latter. Linux has demonstrated that this PkgBase idea does not work. RH/Fedora's core, minimal are anything but (and are bloomin random with their selection). Debian's essential even has hacks to override the Packages list. Again, just a random assortment of packages. And Arch Linux's for a time had core relying on extra for a random package (they fixed this after a month).

Gonna leave it here. I hope I am wrong about PkgBase of course. But I am simply not as optimistic as many of you are. Time will tell (or of course, we will all move on to alternatives if it all goes to pot).
 
sidetone said:
Also, pkgbase can help coding cycles for programs, so improvements dont have to match cycles on FreeBSD release dates. Improvements can keep coming during FreeBSD major release code freezes.
Click to expand...
I consider this to be a bad thing, not a good thing. When I'm on a major version (like 13), then all programs installed as part of base will not have major version changes, until I upgrade to the next major version (like 14). This greatly reduces the amount of breakage that minor or patch upgrades will cause.
 
You must log in or register to reply here.
Back
Top