bystander: hey, there are flames pooring out of the windows on your house

home owner: well if you expect me to do anything about it, you'll need to lodge a formal request for me to look into it

Wrong analogy, methinks.

By the way, I have had good experience with that bug tracker: a problem I reported was fixed after 1.5 years or so.

if you give that page a read, you can see that the project has serious resource and governance problems. to the point where i'm questioning if the operating system is even safe to run anymore

Tinhead bot seems to have lost it's marbles in #freebsd-bugs

i love freebsd and have used it for decades, but if the project cannot address or at least respond to these issues, i'll have to seriously consider moving to a more mature/supported os like debian

mjp, if it is your won article -- great. You could initiate a productive discussion of it on the mailing lists, more suitable to lengthy discourse than IRC. (my personal opinion)

mjp, there are other BSDs, as well.

i'm a user/sysadmin with a full time job and a family, i don't have time to contribure to the project

talking a high and mighty game about governance issues makes you sound like a strasserite

i think if the project is not able or willing to take security seriously, state it and make everyone aware, don't pretend otherwise

mjp, reporting a problem is a tiny fraction of effort of having it fixed.

i dont think anyone would disagree with that

you might be right, but you are at this juncture a disruptive presence

i dont see the project even acknowledging long standing problems, let alone having a plan to address them

wake up calls usually are disruptive

that is the point?

linking master→main under «political commits» really does stand you out as a fascist. please just leave.

bystander: hey, there are flames pooring out of the windows on your house. home owner: you are at this juncture a disruptive presence

ok

analogy incorrect

if you're going to switch to a different OS because of this - switch

it's that simple. if you don't want to visit the house you think is burning, don't visit the house

building stuff as root doesn't seem great

i will probably apply some of their recommendations, at least

i like the house, i have lived here for decades, i dont want to leave

mjp: Then the solution is to constructively contribute. End of story.

i also have a landlord advising me "well if you dont like burning to death, just leave!"

i don't think if fair to blame users of the OS for not fixing its shortcomings, its perfectly valid to just be a user and not contribute

mjp, no contribution -- no complaint.

is that an offical rule of the freebsd project?

i also like it, i can't yet evaluate the difficulty of each proposed change here but running any WAN-facing freebsd i probably should put it on to-do...

or some BOFH quip from the 90s?

mjp, I think it is common sense. And of course, reporting bugs in the tracker counts as a contribution.

do we have literally an moderator on deck right now

i will agree some of the listed things are not really "bugs" per se

if you read the article. many problems have been reported to the project, and ignored? how would creating a bug report for an ignore bug report help?

like, if you have configured swap not to be encrypted, and it's not encrypted, that is correct behavior for the setting

also you have included your X account name at the top of this page of yours. in 2026. that puts you in the lunduke set

i'm not attacking the people or the project, but I think an honest conversation and response is warranted

encrypted swap is what i would consider one of the lesser problems raised here

mjp, a bug report /will/ help, because it will stay open and sore the eyes of the developers.

(this is a recommendation i will probably take)

yeah, was first example, not necessarily most important. i just mean reporting as bugs seems wrong for some of them, so I wouldn't know where it would be considered constructive to raise the issue etc etc

i don't see how making developers have even more sore eyes than they already do would help them when they are already overwhelmed and overworked

now i'm a bit confused, what are you advocating if not for the issues to be fixed?

mewt, report /any/ problem to the bug tracker. Mine was not a bug, either: <bugs.freebsd.org/bugzilla/show_bug.cgi?id=280941> .

interesting, ok

mewt: basically telling us to stop using freeBSD while advertising his (he's a he. i just know it. no woman writes a web like that and is also openly christian.) website with linux hardening tips to us.

hmm

most of the article touches on more than "bugs" suitable for reporting in a tracker, they touch on the stated priorities and goals of the project vs actual reality on the ground, it needs high level evaluation and intevention

LXGHTNXNG: if you are talking about me, you are making some very bad assumptions and are not good at trying to doxx people

I'm not interested in doxing you.

I don't even use X btw, so not sure who's X acct you are talking about?

We're assuming that you wrote the article because you passed it us without any indication that you got it from somewhere else.

the author is not mjp i don't think, the author is a name i've seen around as an arch maintainer before

blakkheim iirc

yes

for some reason there's some negative emotional valence stored against tha name in my memory banks but I can't know what it is

okay. mjp you're forgiven, but all of my comments apply to blakkheim

consider the source before you send things

that's all I will say.

i think my comments on the Xitter profile are off topic, i do find it a bit off-putting. i'm willing to entertain the recommendations given anyways

LXGHTNXNG: you (no one else, not 'we') made wrong assumptions. I have not done anything wrong, i dont need your forgiveness. maybe ease up on the ad hominems though?

unforgiven then. and ignored

mjp, try the mailing lists with those higher-level concerns.

I just realised today that the article was first published over 3 years ago

I doubt lots all of the problems mentioned in it are fixed now.

Oh, hm. blakkheim used to be a regular in here, and was a FreeBSD person, but it was years ago. Anyway, most of the things in that article can be taken as hints for how to configure things. I think there are things in there worthy of being formal bugs, but it'll take some research. Not everything he says there is valid.

IIRC, he was, among other things, the first audio engineer for BSD Now.

o

well, this is novel. my small router PC likes to f*ing REBOOT randomly when a network cable is physically disconnected O_o

mjp: to be honest, as a random user/admin, i think your overall stance is reasonable, but that article if you look more deeply into some items they're exagerated, and many of the issues relate to many years ago and are no longer applicable

but i think it's good for everyone to fundamentally reconsider and re evaluate their security in the current era, with what's happening with AI

(to what you saida bout the publish date, yea i think it was quite some years ago that it was published)

RoL, reboot on lan

jmnbtslsQE: I recall first seeing this rant years ago, like a decade or more - "freebsd defaults are insecure". at least back then it was too far detached from objectivity to be taken seriously by anyone except those who already had something against freebsd and wanted to reinforce their stance

and "$project owes me something, I would like to speak to a manager" reaction rarely gets anywhere

yep, there's a curious illusion among users and many devs too that having more users has any intrinsic value

I'm at 13.4-RELEASE-p1 on this one box. . . can I build & install 14.x, or should I stop at a later 13.x first?

CrtxReavr: if you're using installworld, you should be fine to upgrade directly. if you're using freebsd-update, upgrade to the latest 13.x release and make sure you have all freebsd-update errata installed

bah

So rusty on this. . .

So according to ./sys/conf/newvers.sh I have a 13.4-RELEASE-p5 tree.

How do I get it to 14.4-R in the age of git?

There's also this ./stand/common/ tree.

is it already a git repository? you could git pull then checkout the git tag for 14.4 release

is it a git-cloned tree? /usr/src. what does git status say?

It is a git repo.

er - git clone

try this - git checkout releng/14.4

also `git pull` to update

git status: termbin.com/5ooe

i see

you seem to have modified some files, is that you or freebsd-update done it? probably the latter.

# git checkout releng/14.4

error: pathspec 'releng/14.4' did not match any file(s) known to git

nxjoseph, that was the patch for the recent dhclient RCE.

Ah I see, thanks

git pull origin releng/14.4

hm, try git fetch first

hehe

Can we get an agreement on commands?

all sort of works the same :D

'git pull origin releng/14.4' is 'Receiving objects'

Half way there.

Good

'resolving deltas'

git pull is git fetch + git merge, it brings your local branch up to date too (but I think in this case it makes a mess, because your local branch is releng/13.4 and the one you are pulling is releng/14.4)

nimaje, right, thanks

Just follow those three commands, or. . .

i believe git checkout should work now - git checkout releng/14.4

nimaje, you have input on that?

nxjoseph, that based on what you saw in my bpaste link?

yes

error: pathspec 'releng/14.4' did not match any file(s) known to git

hmm, git checkout origin/releng/14.4

error: pathspec 'origin/releng/14.4' did not match any file(s) known to git

I think I'll try those three commands.

:/

can you share output of git branch -r

git switch is a bit nicer there as it only takes branches, so git can't confuse if you meant a branch or a path

hmm, maybe try switch then

thanks, it seems like the pull command didn't work or what? :/

maybe nimaje can help better, sorry

probably the fetch part of the pull didn't happen then as it detected it can't put the branches together

The three commands from the "hints" I pasted compeleted without error or output.

nimaje, 'fetch part of the pull that didn't happen'? How do I do that.

try git fetch and if that doesn't give you the releng/14.4 in git branch -r then try git fetch origin releng/14.4

'k

'git fetch' running.

branch -r still showing origin/releng/13.4

> then try git fetch origin releng/14.4

Okay, apparently this is a mess: bpa.st/7PUA

sorry for the bad experience

Dont' appologize.

Should I 'rm -rf /usr/src/*' and start over?

hm, what does ls .git/refs/remotes/origin/releng say?

13.4

When I ran 'git fetch' it did print:

* [new tag] release/14.4.0-p4 -> release/14.4.0-p4

Amonst lots of other output.

hm, strange what is configured as origin in .git/config ?

oh, i think fresh start might be better :p

it seems to be configured only for the specific branch releng/14.3

i am not that pro to manually edit .git/config

try changing that to fetch = +refs/heads/*:refs/remotes/origin/* instead of hard coding 13.4 there

nimaje, you concur?

hmm, hope that fixes it

Like this: termbin.com/v97s

yes

Oh, should I nuke that [branch "releng/13.4"] stanza?

no, you can leave that, it just tells git that your local releng/13.4 branch comes from the one from the remote origin

Okay, so now what - git fetch again?

git fetch origin releng/14.4

That one?

yes

cool!

now git switch releng/14.4 should create a local branch releng/14.4 from the one from origin I think, if it doesn't try with -c

i think it's time to switch/checkout now

Griping about the patch to sbin/dhclient/dhclient.c

ah, yeah, there was that. What patch is that? do you still need it?

RCE in dhclient

Just last week.

Actualy, maybe a couple weeks ago.

Do I checkout releng/14.4 or origin/releng/14.4 ?

I'm gonna try just releng/14.4

git checkout releng/14.4

good luck! :)

Switched to a new branch 'releng/14.4'

congratz!

Can I start building?

Does git status show you are up to date?

> Your branch is up to date with 'origin/releng/14.4'.

it seems so.

Bitches about an old kernel config file, but I guess that's fine - gonna update that anyways.

so this is a remote upgrade. . . should I install and boot the the new kernel before doing installworld & mergemaster, or should I be okay to do them both together for the first boot?

feels like 13.4 to 14.4 is a big leap.

you will want to be booted into the new kernel before installing world, yes

otherwise things will be quickly hosed on the running system and it'll be considerably more annoying to work through the remaining steps

kevans_, even though my only access is via ssh?

CrtxReavr: maybe especially because your only access is via ssh

userland will almost certainly cease to function as soon as installworld is finished, if not in the middle of it

I get the feeling that my env. is corrupt some how. For the past week buildworld buildkernel has been failing with from what appears to be may failing bison and/or crunchgen mainly resuce.mk. I don't think it's -j issue or WITH_CCACHE_BUILD issue. yet it always errors.

I see from ci.freebsd.org the build of main and 14.4 are fine.

So I'm guessing it's something on my side.

How's it failing? sig11?

CrtxReavr: gist.githubusercontent.com/dereksch…bc576de353d15fbd1e0d1/gistfile0.txt

It seem to between that and crunchgen error 1

o/

i'm getting back into server stuff, got a freebsd server installed. now i'm trying to get bhyve-vm up and running. i have a guest installed and running but it can't get network access. i realized i don't have a bridge created and bhyve-vm is configured with switch_list="bridge0", type_bridge0="manual", bridge_bridge0="bridge0", so i gotta create my

own. i remember in the past there was a lot of conflicting info on whether the vm host should keep its ip on its interface, or if the ip should be moved to the bridge interface. any guidance greatly appreciated, i want to make sure to do everything right this time

"To allow the host to communicate with bridge members, IP addresses should be assigned to the if_bridge interface itself, not to the bridge's member interfaces." (man.freebsd.org/cgi/man.cgi?query=b…ion=4&manpath=freebsd-release-ports) but then "The bridge(4) interface doesn't need an IP address."

(forums.freebsd.org/threads/bridge-c…ing-of-bridge-use.86747/post-584354)

kerneldove: the IP address should be on the bridge interface or a vlan subinterface of the bridge, not on a member

so was SirDice wrong there or am i misunderstanding something?

he's correct to say it doesn't *need* an IP address. but if you want the host to have an IP address in the bridged subnet(s), that IP address goes on the bridge

my lan is 10.1.1.0/24. my server is 10.1.1.15, and the vms will use 10.1.1.16-19. what are the "bridged subnet(s)" there?

sorry, my lan's subnet is*

10.1.1.0/24 is a subnet

and that's the same as "bridged subnet"?

when i say "bridged subnet", i just mean a subnet with traffic going through the bridge. does traffic in 10.1.1.0/24 go though the bridge? then yes

I'm assuming ivy means: if the server interface is igc0 and typically gets the IP address 10.1.1.15, then you'd assign that IP to bridge0 and igc0 no longer gets an IP.

and igc0 becomes a member of bridge0

ok got it

tyvm for clearing the confusion for me

kerneldove yes, I forgot that bit.

my server has 4 phsyical ports that i make a lagg0 over and assign an ip to. i assume that i make lagg0 the bridge0 member and move the ip assignment to bridge0, correct?

Yes.

ok thx a lot ppl