01:01:07 <[0x1eef]> It would be a whole lot better if it it managed a standard FreeBSD configuration IMO. Then you could choose to use the web UI, or the shell. Even let the web UI manage some things, and the shell other things. Instead it is built in such a way that it doesn't work like a standard install. 01:11:51 <[0x1eef]> alepzi: it's not transparent though. It doesn't use /etc/rc.conf. Neither does it use /etc/pf.conf. So I don't think you'd learn much about how FreeBSD works under the hood. You'd learn how pfSense is implemented at best. 01:21:49 well ya that's what i'm saying. no black boxes, just easy configs of a regular freebsd for the noob to get from 0 to web gui firewall in a jiffy. obviate shit like pfsense and netgate 01:27:26 <[0x1eef]> There's probably a market for that. 01:29:08 it's not reolly obviating it 01:29:12 jst another competitor 01:34:43 not if it's all open and has easy setup and links to hardware that's known to be compatible, ready to go. maybe that's what opensense is? 01:36:25 <[0x1eef]> You can buy routers with pfSense preinstalled and ready to go. 01:40:57 to my knowledge pfs also ship an iso 02:44:06 does freebsd-update -b basedir/ fetch install need to be run as root or smth? it fails with dir does not exist or is not writable: /var/db/freebsd-update 02:45:08 fwiw /var/db/freebsd-update is root:wheel and drwx---------- 02:47:02 a non-root update? 02:47:15 ya i'm setting up a jail dir 02:47:31 don't want to do anything to the host system 02:50:28 can't run that inside jail? 02:50:45 that would make no host changes at all 02:51:05 trying to make it to a scripted bsdinstall base 02:51:23 so when i install the host in a vm, its jails are already there and ready to go 02:51:56 hmm 02:52:49 well it has -d 02:53:21 is that it? 02:55:00 that seems to run, but then it says at the end you must be root to run this 02:55:02 so not sure 02:55:14 it says 13.3 p1 is newest and doesn't need to be updated 02:55:24 is that latest? 03:04:18 alepzi: latest release of 13 series? 03:04:35 the answer is yes. 03:05:24 alepzi: you are running 13.3 and want to know if there recent patches available? I believe there is none. maybe you are looking for newer production releases? Please describe your objective. 03:06:46 check the rel engineering for details how the software releases are structured: https://www.freebsd.org/releng/ 03:06:47 Title: Release Engineering Information | The FreeBSD Project 03:31:43 This isn't true. There's 13.3-p1, for https://www.freebsd.org/security/advisories/FreeBSD-EN-24:06.wireguard.asc and https://www.freebsd.org/security/advisories/FreeBSD-EN-24:07.clang.asc. 03:36:09 V_PauAmma_V: I am confused by what you mean 'isnt true'. He said exactly 13.3 p1 is the newest. I understand this is correct statement. Please clarify if that is latest or any newer. 03:36:42 V_PauAmma_V: Is there a patch over 13.3-p1? 03:37:15 shouldn't be, my wireguard EN just landed like, last week 03:37:51 NO, you're right I just didn't read up after "recent patches" - which I think -p1 is, being 4 or 5 days old. 03:38:18 My fault. 03:39:13 s/after/past/ 03:40:15 V_PauAmma_V: np, many thanks for the update! 04:28:45 I'm kinda liking my "inception" setup as a work around to PR 278058 (I'd like no bug better, lol) 04:28:46 278058 – Simultaneous use of Bhyve AND vnet on network PCI devices causes network failure https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278058 10:13:02 When going from freebsd13 to 14, we're seeing a ~10% drop in throughput on a simple nginx (tls) server benchmark. I have been warned that some kernel work might do this to us, since we use "wrapped" jails - an outer vnet+epair jail and an inner "classic" jail. 10:13:44 Are there any "glaringly obvious" things we should change in nginx config to reap benefits of 14 and perhaps offset this regression, before I start complaining to kernel devs? :) 10:59:08 Ltning: maybe find out what the benchmak is using as an indicator of throughput? The use of a benchmark to determine performance is very specific to that benchmark and may not reflect reality. 11:00:18 and from what i am reading, youa re doing a freebsd 13 -> freebsd 14 host which contains a jail that has another jail in it? 11:00:26 are those jails still on 13 or they have been ugprade to 14? 11:21:44 The jails are 13, but I was warned that there are kernel things that are already suspects. 11:22:00 But not sure if userland being 13 should have any impact here? 11:22:19 Also well aware of the synthetic nature of benchmarks. That's both their weakness and their strength. 11:41:20 As opposed to them having a natural nature. Man I can't even imagine such a thing. 11:53:23 Ltning: that is possible, unless yyou have a specific situation. that will be a needle in a haystack situation 11:53:34 is this machine in production? and being used to serve customers? 11:55:18 i may be wrong in this approach but jumping from nginx all the way to the kernel being suspect, is a big leap.. in my head 11:56:22 if you need to build virtual machine images with the latest cloud-init, here's my repo: https://pkg.igalic.co/ 11:56:24 Title: Repository for net/cloud-init 12:35:25 xulfer: It's called a manned botnet ;) 13:03:48 voy4g3r2: Our production machines are still on 13, we're testing 14 on comparable hardware to see what we can expect. The reason I "blame" the kernel is *very* specific remarks from kernel people after my talk at EuroBSDCon last year where I detailed our "wrapped jails" concept. Apparently some optimisations that might backfire in our scenario. 13:04:35 And since we - despite being warned - didn't manage to get our act together and test this before/during the -BETA phase, I hardly find it fair to complain about that right now. Hence my hoping someone knew low-hanging nginx-optimization-for-14-fruits. :) 13:05:56 On the positive side, nothing seems to *break*, and it's still only ~10%, so it's entirely serviceable. And I suspect other concurrency-related improvements in 14 can help offset even that, since we're running "a handful" of such wrapped jails on each host, and Java code (apache-tomcat) is also known to be significantly faster on 14. 14:53:24 Ltning, If you were to run a benchmark program such as "iperf" to be a specific network I/O benchmark only (removing the rest of nginx) in both the old and the new do you see 10% as well? 14:54:07 And regardless if the problem is throughput then using a throughput specific benchmark would be a useful way to make a reproducer for a benchmark problem report ticket. 14:59:33 rwp: Yes, that is on the list of tests to run. 15:00:29 I could easily see that an I/O benchmark might be more than 10% by a significant amount if it avoids the rest of nginx. 15:00:53 On a not-related-at-all-note - seems like both electron28 and signal-desktop has disappeared (again). I cannot overstate how much I hate everything electron. 17:23:40 Ltning, Almost all of the new-school rolling release rapid turn massive churn projects have routine instability problems. 17:44:56 i'm setting up a jail and part of the process is to retrieve base.txz and expand it. question, if i already have the freebsd git repo cloned, is there any way to use that and skip the fetch, expand, update step pls? 17:48:43 alepzi: man 8 jail -- "Setting up a Jail Directory Tree"; you build and install userland in a specific destination directory. Not how I would do it, but if you want to start from a cloned git repo (which is source code only), then that's one way of going about it. 17:50:46 it is possible!! 17:50:50 tyvm 17:50:58 btw why is that not how you'd do it? 17:52:41 It'll take forever the first time, since it's building the whole system. If you do that, you want to add -j $(sysctl -n hw.ncpu) to the 'make world' step: "nice make -j $(sysctl -n hw.ncpu) world DESTDIR=$D" 17:53:27 ...or something like that. (sysctl -n hw.ncpu simply spits out the number of CPUs you have; that number can of course be specified directly instead, and depends on how much of your CPU you want to spend building :) 17:54:25 I'd rather download base.txz and expand it into some template-jail directory, and then "mount_nullfs -o ro