20

Hello community, I need to know for sure if the following options are enough to remove 32bit support for the entire system: In the custom kernel configuration file: nooption COMPAT_FREEBSD32 In the src.conf file: WITHOUT_LIB32=yes This is enough? And if so, will it bring stability problems to the system?

no, it shouldn't bring any stability changes

that looks good enough to me

Ok, thanks for your feedback

i think that some changes should be made to the freebsd news flash rss feed since all the articles link to the same page, the only thing that differs is the first few lines that would be description of the item i guess, so like take the article "New FreeBSD Core Team Elected" for example i think that instead of linking to freebsd.org/news/newsflash/#2024-06-12:1 it would be better to link to lists.freebsd.org/archives/freebsd-ann

nce/2024-June/000136.html

also btw are there any other rss feeds for freebsd?

F, the link got messed up

lists.freebsd.org/archives/freebsd-announce/2024-June/000136.html is the correct link

and the security rss feed is messed up even more(freebsd.org/security/feed.xml) articles on it just contains the proper title but when the article is opened it just contains a link that just redirects to the main page of the rss feed -_-

i would share a video to explain better but idk how to use dcc :/

clear

lists.freebsd.org/archives/freebsd-hackers/2024-July/003391.html huh, didn't realize this had landed

splash(4) on -CURRENT now has png support on UEFI systems

If I understand right, cgit.freebsd.org/src/commit/?id=f6e8b0e850 means that it can be the same splash screen from loader(8)

Yeah, that's outright stated in cgit.freebsd.org/src/commit/?id=00460cc8c5a

It's a few hundred lines of code, and now we get to make jokes about year of the freebsd desktop

cgit.freebsd.org/src/commit/?id=ef2a572bf6bdc say what?!

Gotta say, I am not fond of accelerated FOSS release cycles, and am unhappy FreeBSD is going there with RELEASE. I use "LTS" Linux and FreeBSD on my @work servers to avoid churn. :( I'll live with it because FreeBSD is my favorite OS and I have no choice if I want to keep using FreeBSD ... and I do want to keep using it. Hopefully there won't be much more churn on our FreeBSD RELEASE installs, we'll see. Fingers crossed. :)

unixman_home You can always use the -STABLE branch btw. it also gets features much earlier

I'm planning on moving to -STABLE soon

but you would need to update more often with -STABLE than with -RELEASE, unixman_home wants to update less often

Correct, less churn for OS upgrades is what I want. Plus we have lots of Linux and Windows folk, but only two FreeBSD savvy folk, me and one other, who manage our thousands of VMs and standalone boxes. Anyway, I'm just whining. It may not end up being as awful as I fear. ;)

unixman_home: same for me. I am not complaining, as FreeBSD is completely free and really awesome :) I use it exclusively in our data center to host all kinds of gnu/linux VMs

I do love that the upgrade process is easy and painless, though I do wonder at times how many security vulnerabilities are never detected/fixed tbh

Hmm, the remark that I am using it to run linux VMs (using bhyve) is not meant sarcastically in any way -- it's just that the specific software we need to run requires a specific linux setup

Having freebsd as the host system is wonderful because bhyve is simple enough to give me a chance to actually understand it + zfs

I even run a windows 11 VM on it, was surprised just how stable that (the VM) was

lets seem if the shorter and more predictable release cycle makes it easier for re@ and if it makes stuff easier for users

The one thing I find a bit unsettling tbh is the ABI changes and need to recompile everything

I bought a new threadripper in preparation of that :p

/25/sb end

(woops)

hc: what's your favourite human interface to bhyve? A web page? Or just pure terminal CLI?

I used to use sysutils/cbsd for 10-ish years

now I am transfering via sysutils/vm-bhyve to just base tools

ah shit, that was directed at hc - never mind

Hecate: I'm using the vm from the ports/pks

Hecate: bascially what jbo suggested

vm-bhyve is the one. Works very well and reliably

I moved from the default config of having image files to using zvols, though. In my experience it is safer and also you can pass trim commands through

that is still on my todo list. still just images here

but at least they are _inside_ of a dataset

heh

Actually, it wasn't difficult to transition, I just dd'd it onto the zvol

With images, I had frequent ext4/xfs corruptions inside the containers when rolling back a snapshot made while the VM was running. With zvols no such problems so far

Hecate: i'm also a fan of vm-bhyve