binary updates would be off the table, current mishaps are relativly uncommon

once it's released updating to RELEASE is effortless

anyone ever zfs send a bunch of data, and receive it on another machine?

If so, can you guide me a bit on how to do it. my internet searches all assume it is on the exact same machine, or that I want to open up root access through ssh (could do temporarily if required)

zfs send mypool/blah@snapshot | ssh otherhost sudo zfs recv otherpool/foo

you could use netcat or something else, sure

i use a FreeBSD UNIX laptop in case my desktop (Slackware GNU/Linux, FreeBSD) disconnects, but both have ethernet. I mean if that disconnects (outage) I connect to my cellphone's Internet on laptop... but if I leave ethernet plugged-in, eventually it disconnects wifi. How can I disable that happening? If this is a feature, at least have it traceroute or something to see there's an actual connection!

some people even use multiple connections to increase speed

darwin: man.freebsd.org/cgi/man.cgi?ifconfig

perhaps I need to write an programme

is it intentional that you can't bind() to an 'inet6 anycast' IP address? this seems to make anycast addresses rather useless

like, i have an anycast DNS server, so i want it to respond queries but never use that as an outgoing source address, which seems to be what anycast is intended for, but you can't actually use it like that

hmm, apparently yes: cgit.freebsd.org/src/tree/sys/netinet6/in6_pcb.c#n215

seems like this comes from RFC2526, and the restriction was removed in RFC4291

you don't contribute to freebsd by making pull requests on github

deadlocked: yes you do? this has been an accepted way of submitting patches for well over a year

see cgit.freebsd.org/src/tree/CONTRIBUTING.md

you don't contribute to freebsd by making pull requests on github in the real world, just in the clown world

FreeBSD needs all the contributors it can get

if good quality patches come via github then that's a good thing

as the doc says, github is preferred for small changes

you go to the bar to meet bar women

you go to github to get github-tier contributions

if you think the riff-raff is worth all the extra headache... :/

doesn't seem like anyone answered my question. has anyone used quBSD(github.com/BawdyAnarchist/quBSD). I realise it's still a bit half baked(not yet in ports etc), just wondering how half baked and whether to bother installing FreeBSD to play around with it. As much as I like Qubes OS, there are a lot of things that annoy me about it, like using a full-blown fedora or debian install for every VM

when all you really need for many of em is a kernel, a couple drivers and daemons and utility scripts. performance is annoying to get right and the documentation leaves a lot to be desired

deadlocked: I mean, plenty of very serious projects are primarily developed on github or equivalent services, so I don't think it's fair to say that about github in general

though for freebsd specifically, it like many other projects like linux are not on github/gitlab because their dev infrastructure preexists those services. and the experienced greybeards are very familiar with that infrastructure already, so of course they don't use github

but github is gonna be more familiar to younger devs with less prior experience with the project. they obviously can't contribute as much as the greybeards yet, but it's important to recruit them to keep the project alive in the longer term

it's not about how much they're able to contribute, it's what they contribute as well, or maybe even moreso

not all contributions are positive, coming from somebody who was in a leadership role of an open source project once... a lot of the times there will be intense social pressure to push the project in a specific direction that isn't positive. and i am not referring to codes of conduct either. technical stuff.

just one more extra layer of abstraction here, just a few more edge cases there, gotta rejigger this new thing by adding a new parameter there, gotta add a new execution path to handle some kind of red herring over there

without equal amounts of effort guiding said contributions, it devolves into an unmaintainable mess

well yes, I'm not saying every contribution should be accepted. but that's a question of being a good maintainer, not a question of whether github can be a useful source of new devs to the project

maybe you should read the contribution guidelines then, about what is acceptable to contribute via a github pull request, the change should be small and straightforward

well anyway, the linked PR seems fine to me. i read the RFCs and it's valid.

kinda ironic that bsd used to be the reference ip implementation but it didn't implement a change from 19 years ago... heh

rtprio: so my understanding was, use 15.0-CURRENT and then at some point it turns into 16.0-CURRENT. Or does it work like, 15.0-CURRENT morphs into the branch which eventually becomes -RELEASE?

(because the latter would potentially be attractive)

duncan: 15.0-CURRENT is the 'main' branch in git, at some point it will be forked into stable/15 to prepare for 15.0-RELEASE, then main will become 16.0-CURRENT

you need to manually switch at that point if you don't want to stay on main

OK, that probably wouldn't be too bad given I'd have to be building base myself

but my original question was really one of, given 14.2-STABLE snapshots crash at the bootloader as well, would it be a reasonable assumption that the upcoming 14.3 would as well?

you don't need to build it yourself if you don't want, there are semi-official pkgbase packages: wiki.freebsd.org/PkgBase - however, you can run into issues with the src build and ports build not being in sync

that's hard to say without trying it, a lot of fixes from main get backported to stable and would be in 14.3

but not all of them

if 14.3 hasn't been frozen yet (i'm not sure of the status) there might be time to find the fix and get it backported if it hasn't been already

OK, I will report the issue on the bugtracker.

also not sure why you write 14.2-STABLE instead of 14-STABLE for 15-CURRENT instead of CURRENT I can understand it a bit, because it will eventually branch into 15-STABLE

duncan: i missed your earlier question i think, but are you asking because the issue you're having is fixed in 15 (but not stable/14) or is it broken in both? because in the former case there's a reasonable chance a PR might already exist

ivy: it's broken in 14.2-RELEASE, a snapshot of 14.2-STABLE I tried, but 15.0-CURRENT reaches the installer fine

nimaje: I write 14.2-STABLE because this is the name of the snapshot directory. Is this wrong?

oh, hah, tried another GPU and 14.2-RELEASE boots fine

(offending card is Radeon Pro W5500)

i think i'm missing something about allow.adjtime/allow.settime in jails, i have a jail with both of them set but settimeofday() is returning EPERM

is there some other jail restriction that stops that from working?

curiously security.jail.param.allow.settime is 0 in the jail even though jls -n shows allow.settime

ah, i think i see the problem

freebsd/freebsd-src #1619 - i'm quite enjoying service jails so far...

shouldn't that contain something to request that settime capability for ntpd in base when a user runs it in a service jail? I guess just ntpd_svcj_options="settime" in defaults/rc.conf

not a bad idea, but not strictly necessary for this one imo

I think there's a broader argument to be had about whether we should encourage ntpd in a svcj

nimaje: i don't use ntpd so i didn't do anything related to that, but that would be a reasonable followup commit

i think the right place for it is /etc/rc.d/ntpd though, or at least that's how other services seem to do it

/etc/rc.d/ntpdate could be changed also

llfw/freebsd-src cde92be not tested

hm, it's a bit more complicated because the way svcj works breaks rc.d/ntpd and it starts with no command line arguments

i think because it assumes precmd can override the environment, and i guess svcj breaks that

can I use sched_4bsd with FreeBSD 13+? assuming HT disabled

why do you want this briandaed ?

because ule is starving my processes

the flow is like this (not created by me): parent app is spawning up to thread count processes, they are to finish in given time limit (up to 30 secs), the problem is they use pipe to communicate and for some reason go to sleep, scheduler 'gives' time to newly spawned processes and 'forget' about those spawned previously, they have no chance to finish in expected time, when run alone there is no problem

I've studied what I've found about schedulers, watched excelent yt videos from Marshall McKusick and for me everything boils down to starving processes by ULE

briandaed: SCHED_4BSD is still there if you want it

ivy: I guess so, so compiling kernel with 4BSD enabled, and kicking off ULE, while HT disable should make it work?

s/disable/disabled

i have no idea if that'll fix your problem, but that is how you enable SCHED_4BSD, yes

ok, I'll make some test under bhyve, should be sage

s/sage/safe

thanks all

hm, will setting $SRCCONF in the environment work? src.conf(5) says "the make(1) variable SRCCONF", but it should take it from the environment, or no?

`make -DSRCCONF=/some/path` I would assume

Barnerd: right, but i don't want to type that every time i build

MAKEFLAGS='-DSRCCONF=/some/path' should work

haven't tried, but man.freebsd.org/cgi/man.cgi?make says so :D

if it works with make SRCCONF=..., it should work from the environment though, right? that normally works for setting make variables

i wonder what's the easiest way to test it... enable ccache and see if it uses ccache, i guess

SRCCONF=/some/path make -VSRCCONF would tell you if it worked

and works indeed

right, i know make takes variables from the environment usually, i'm just not sure if ${SRCCONF} is special. it does seem to work, though

Hi all - any pointers on where to find some real-world feedback from people running U.2 nvme drives on FreeBSD 13 or 14 in production?

Last time I researched this a few years back there were some issues with hotplug and some general glitchiness, but that was the very early days of nvme.

kevans: thank you very much for your help the other day, my upgrades went well and everythings working here. Much appreciated!

spork_css: I use FreeBSD on NVMes all the time with no problems. I don't hotplug, though.

ivy: there are small diffrences if make takes a variable from the environment or if it is specified as an argument, but most of the time they work the same; I think it only matters if the makefile uses = to assign the variable, but not sure