01:44:13 binary updates would be off the table, current mishaps are relativly uncommon 01:46:42 once it's released updating to RELEASE is effortless 02:36:04 anyone ever zfs send a bunch of data, and receive it on another machine? 02:36:59 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) 02:43:10 zfs send mypool/blah@snapshot | ssh otherhost sudo zfs recv otherpool/foo 02:43:47 you could use netcat or something else, sure 05:06:44 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! 05:12:57 some people even use multiple connections to increase speed 05:15:24 darwin: https://man.freebsd.org/cgi/man.cgi?ifconfig 05:41:22 perhaps I need to write an programme 08:11:47 is it intentional that you can't bind() to an 'inet6 anycast' IP address? this seems to make anycast addresses rather useless 08:12:33 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 08:19:43 hmm, apparently yes: https://cgit.freebsd.org/src/tree/sys/netinet6/in6_pcb.c#n215 08:26:23 seems like this comes from RFC2526, and the restriction was removed in RFC4291 08:54:21 https://github.com/freebsd/freebsd-src/pull/1618 09:24:50 you don't contribute to freebsd by making pull requests on github 09:25:09 deadlocked: yes you do? this has been an accepted way of submitting patches for well over a year 09:25:55 see https://cgit.freebsd.org/src/tree/CONTRIBUTING.md 09:25:55 you don't contribute to freebsd by making pull requests on github in the real world, just in the clown world 09:29:22 FreeBSD needs all the contributors it can get 09:29:51 if good quality patches come via github then that's a good thing 09:31:09 as the doc says, github is preferred for small changes 09:42:35 you go to the bar to meet bar women 09:42:42 you go to github to get github-tier contributions 09:43:12 if you think the riff-raff is worth all the extra headache... :/ 09:47:56 doesn't seem like anyone answered my question. has anyone used quBSD(https://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 09:48:02 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 10:11:18 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 10:13:37 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 10:14:41 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 10:45:05 it's not about how much they're able to contribute, it's what they contribute as well, or maybe even moreso 10:46:05 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. 10:46:55 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 10:47:22 without equal amounts of effort guiding said contributions, it devolves into an unmaintainable mess 10:57:05 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 10:58:57 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 11:01:48 well anyway, the linked PR seems fine to me. i read the RFCs and it's valid. 11:02:30 kinda ironic that bsd used to be the reference ip implementation but it didn't implement a change from 19 years ago... heh 11:36:59 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? 11:37:19 (because the latter would potentially be attractive) 11:38:48 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 11:39:17 you need to manually switch at that point if you don't want to stay on main 11:39:53 OK, that probably wouldn't be too bad given I'd have to be building base myself 11:40:41 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? 11:40:48 you don't need to build it yourself if you don't want, there are semi-official pkgbase packages: https://wiki.freebsd.org/PkgBase - however, you can run into issues with the src build and ports build not being in sync 11:41:48 that's hard to say without trying it, a lot of fixes from main get backported to stable and would be in 14.3 11:41:55 but not all of them 11:42:25 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 11:44:30 OK, I will report the issue on the bugtracker. 11:48:54 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 11:50:42 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 12:15:35 ivy: it's broken in 14.2-RELEASE, a snapshot of 14.2-STABLE I tried, but 15.0-CURRENT reaches the installer fine 12:16:48 nimaje: I write 14.2-STABLE because this is the name of the snapshot directory. Is this wrong? 12:17:03 https://download.freebsd.org/snapshots/amd64/14.2-STABLE/ 12:30:19 oh, hah, tried another GPU and 14.2-RELEASE boots fine 12:36:09 (offending card is Radeon Pro W5500) 13:25:10 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 13:25:20 is there some other jail restriction that stops that from working? 13:35:58 curiously security.jail.param.allow.settime is 0 in the jail even though jls -n shows allow.settime 13:39:31 ah, i think i see the problem 13:58:56 https://github.com/freebsd/freebsd-src/pull/1619 - i'm quite enjoying service jails so far... 14:23:52 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 14:25:52 not a bad idea, but not strictly necessary for this one imo 14:26:20 I think there's a broader argument to be had about whether we should encourage ntpd in a svcj 14:43:37 nimaje: i don't use ntpd so i didn't do anything related to that, but that would be a reasonable followup commit 15:51:51 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 15:54:04 /etc/rc.d/ntpdate could be changed also 16:00:05 https://github.com/llfw/freebsd-src/commit/cde92beb2713c3f30a81b9c69bd2545d723f930d not tested 16:40:03 hm, it's a bit more complicated because the way svcj works breaks rc.d/ntpd and it starts with no command line arguments 16:41:28 i think because it assumes precmd can override the environment, and i guess svcj breaks that 18:09:12 can I use sched_4bsd with FreeBSD 13+? assuming HT disabled 18:18:33 why do you want this briandaed ? 18:18:59 because ule is starving my processes 18:21:48 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 18:24:19 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 18:26:00 briandaed: SCHED_4BSD is still there if you want it 18:26:29 ivy: I guess so, so compiling kernel with 4BSD enabled, and kicking off ULE, while HT disable should make it work? 18:26:57 s/disable/disabled 18:28:01 i have no idea if that'll fix your problem, but that is how you enable SCHED_4BSD, yes 18:28:32 ok, I'll make some test under bhyve, should be sage 18:28:37 s/sage/safe 18:28:59 thanks all 18:48:42 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? 18:50:18 `make -DSRCCONF=/some/path` I would assume 18:50:39 Barnerd: right, but i don't want to type that every time i build 18:51:26 MAKEFLAGS='-DSRCCONF=/some/path' should work 18:51:35 haven't tried, but https://man.freebsd.org/cgi/man.cgi?make says so :D 18:52:39 if it works with make SRCCONF=..., it should work from the environment though, right? that normally works for setting make variables 18:53:10 i wonder what's the easiest way to test it... enable ccache and see if it uses ccache, i guess 18:54:02 SRCCONF=/some/path make -VSRCCONF would tell you if it worked 18:54:30 and works indeed 18:56:40 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 19:00:41 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? 19:01:19 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. 21:20:02 kevans: thank you very much for your help the other day, my upgrades went well and everythings working here. Much appreciated! 21:37:44 spork_css: I use FreeBSD on NVMes all the time with no problems. I don't hotplug, though. 22:08:44 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