00:20:51 babz: anyway, my /usr/src belongs to my user. I keep it in sync with git.freebsd.org, and push my own changes to codeberg.org 00:21:34 but because I don't want my machine to exclusively be used for building FreeBSD, I keep up to date via PkgBase 00:33:13 does anyone run thin jails inside thick jails? and i wonder what the overhead cost is for the middle jail? 00:40:55 I just do thick jails for everything these days… until podman becomes production ready? 00:41:32 how much extra disk and extra ram does it take to run a thick jail vs a zfs template cloned thin jail? 00:41:42 guesstimate 01:21:10 meena: ^ 02:55:09 openbsd has a convention of putting the main nic of a comp in the "egress" group. does freebsd have a convention like that? 03:14:51 has anyone seen where man pages require groff to be installed to be able to render? for example man cxgbetool 04:16:00 well lets see how this git pull request goes.. https://github.com/freebsd/freebsd-src/pull/1072 and lets see how bad it is.. 04:16:01 Title: A set of changes to manual pages that were identified to be out of alignment by chrisdavidson · Pull Request #1072 · freebsd/freebsd-src · GitHub 04:20:40 tap tap tap... this thing on? Just going through my list of apps to get working on freebsd, got to hexchat. Yay! 04:20:58 nice! 04:21:45 indeed, it is. So much cleaner than some other OSes. 04:29:54 openbsd has a convention of putting the main nic of a comp in the "egress" group. does freebsd have a convention like that? 04:31:18 i am not familar with that alepzi- 04:31:31 is there something in particular you are looking for, from open to free? 04:43:41 pledge() would be nice :3 05:02:19 voy4g3r2: nice work on the PR 05:03:34 voy4g3r2: some nitpicking review coming your way :D 05:03:44 uh oh... 05:06:39 does anyone run thin jails inside thick jails? and i wonder what the overhead cost is for the middle jail? 05:10:16 yuripv: thank you :) 05:10:34 i do not know if i am struggling more figuring out man pages.. or this damn git 05:10:59 yuripv: you bring up some real good points and that zzz one is just weird 05:11:08 zzz does NOT exist on armv7 but does on amd64 05:11:15 i have started to a major of the work on amd64 now 05:11:22 but you are changing the x86-only man page 05:11:37 guess it doesn't get installed on arm as well 05:11:42 yes, i thought i "fixed" that mistake 05:11:53 i am also breaking up pull reguest into smaller commits 05:12:10 it is my, hopefully right, understanding.. i can have multiple commits in one pull request, corret? 05:12:25 yes, you can 05:12:42 sweet, okay 05:12:45 and i prefer to err on the side of more commits if i'm unsure, because the committer can squash them if needed before committing 05:12:59 whereas 'un-squashing' a big commit is much harder 05:13:00 yeah, a few people highlighted that in the pull request 05:13:13 and also here too 05:17:01 yuripv: i appreciate the reviews.. its late here but will tackle these in smaller commits, i do appreciate the input/comments 05:18:53 voy4g3r2: also i noticed you had a couple of merge commits in the PR, you might want to read up on rebasing (git pull --rebase) to avoid those. it's not a big deal though, just that rebasing is more common than normal merging nowadays 05:20:53 yeah, that was a nightmare 05:21:07 i thought it was taken out, guess not.. but some light reading before bed, thank you! 05:34:36 voy4g3r2: one thing to share if you're still around. Splitting commits into smaller ones via unstaging specific hunks in a file can get tedious in general. For this situation it be might be better to soft reset your commit and make each file their own commit. 06:23:51 is AF_LINK the right address family to represent an ethernet interface's hardware address? 06:36:45 if we don't want any local logging can we just have remote logging configured in syslogd.conf and no local logging will happen? 06:37:06 handbook implied local logging is always required even when remote logging 06:38:18 i don't see any reason why that wouldn't work, but not everything in /var/log is created by syslog (some of it comes from daily, for example, like the *.today files) 06:40:31 how reliable is remote logging? likelyhood of getting messages dropped here and there? 06:41:22 each message is a single UDP packet with no acknowledge or retry, so messages will be dropped if the network is congested or if the remote host is down or busy 06:42:26 can you adjust the buffer size for remote logging or how does send queuing work? 06:42:36 the buffer size on the client, sending side 06:44:21 i've never tried that, perhaps net.inet.udp.recvspace would work on the receiving side 06:44:50 in practice how often do you see log messages dropping when there's machine and network capacity available? 06:45:30 never due to network congestion, often due to rebooting hosts or other maintenance work (so i would never rely on remote syslog alone, unless there was no other option) 06:46:03 ok sounds like there's a reason for a reliable log shipper then and just use syslog for local 06:50:29 does anyone run thin jails inside thick jails? and i wonder what the overhead cost is for the middle jail? 07:21:02 do we not have == for structs yet in C? that would be quite useful when dealing with basic data structs... surprised this isn't there given the other usability features we've got recently 07:25:27 * TommyC frolicks in C++ 08:08:53 Hi there, I'm start having SATA drives detach / periph destroyed again 08:09:27 This happening almost on all machines regardless of drive or system brand 08:11:31 zfs raid 0 - mirror become degraded, one drive become offline for couple of seconds and back online again 08:14:30 here is the sample from the log: https://bsd.to/0VPk#edit 08:14:31 Title: dpaste/0VPk (Plain Code) 08:15:56 you can find plenty of similar message in forums, eg: https://forums.freebsd.org/threads/random-drive-detachments-from-host.89135/ 08:15:57 Title: ZFS - Random drive detachments from host | The FreeBSD Forums 08:17:28 there is literally no issues with hard drives, drives where tested with all possible tests. 08:18:15 also, this never happen to the primary/boot drive, even if drives are switched 08:20:00 also old hard drives (5-7yo) which is still in the raid - never had this issue 10:03:56 meena: i went with Unlicense for netd because i prefer the text (it's a lot shorter than CC0) and more appropriate to software 10:08:15 interestingly Google forbids both CC0 and Unlicense 10:10:33 lw: it's not in here, https://docs.freebsd.org/en/articles/license-guide/#_acceptable_licenses so if you want to get it into base, you'll either have to negotiate with core@, or reticence 10:10:34 Title: FreeBSD Licensing Policy | FreeBSD Documentation Portal 10:10:56 meena: i'm not that bothered about it going into base but, if someone wanted to import it, they could simply relicense it under BSD 10:11:55 (if this ever happens, and there's an issue with that, perhaps i'll revisit this) 10:12:17 right. it's public domain, they could just do that 10:14:55 fwiw i'm not writing this with the intention of it being merged, i'd be fine if it was just in ports. mostly because i think the amount of bikeshedding needed for that to happen would be far more than i care to subject myself to :-) 10:15:15 i need to check you can completely disable rc(8)'s networking stuff though, if not i may end up submitting some patches for that 10:21:24 👍 10:27:37 lw: btw, if you're planning to use ucl for the config format, which, again, it's right there! do why not?! meka has some example code for for to go between nvlist and ucl: https://github.com/mekanix/freebsd-project/tree/master 10:27:38 Title: GitHub - mekanix/freebsd-project: Skeleton of ideal FreeBSD project 10:33:17 meena: i was hoping to avoid having any kind of configuration file 10:33:55 for now i'm going to use nvlist_pack()/nvlist_unpack() to store the state database... i suppose it could use ucl or something later if that seems useful 10:34:56 but the idea is you just configure it with netctl, there should never be any need to edit files 10:35:27 ah 10:36:32 perhaps ucl is useful to let people manually repair the state in case of bugs 10:38:52 * lw wonders if nvlist_pack() format is guaranteed to be stable 10:48:29 as there are nvlist_send() and nvlist_recv() and they don't note any compability constraints, I would guess they use the same format (except that you can send file-desciptors if you use unix sockets) and it remains stable, especially as there is a note that byteorder gets handled automatically and you don't have to worry about it 10:57:17 TommyC: whenever i write C++ code, i end up getting distracted trying to implement all the things the standard is missing, like Unicode strings and a coroutine-based event loop, and never get any actual work done. so i'm staying with C until those things get into C++27 or whatever :-) 10:57:51 basically, C lets me lower my expectations of what the language should do 11:04:05 hmm, my cache directory is 42GB. isn't that meant to be automatically pruned? 11:04:10 er, ccache directory 11:12:50 lw: uh...how are you getting those features in C? 11:13:59 i'm not, but in C i just don't expect them. in C++ i do since it's a better language and should do these things. :-D 11:14:21 (i know people are working on both of these things, they just aren't in yet) 11:15:33 lw: Well, the standard defines coroutines since C++20 which is ~4 years old now. I don't know much about Unicode so can't help you there. 11:15:50 If the compiler you're using isn't keeping up with the standard...well, can't help with that either. 11:16:09 yeah, it has coroutines, but you have to bring your own coroutine context, event loop, etc. i've implemented this myself at least partly but it's a huge amount of complex code and i never got around to finishing it 11:16:37 and none of the existing implementations i looked at really seemed very nice 12:19:12 kenrap: that is a good idea, i think the best way is to update a file and make a commit.. for each file... will save the smarter people latest of trouble 12:22:03 is there any downside of having rctl enabled? or why is the default that rctl is disabled? 12:40:01 kevans: playing around with netlink, it seems like bringing an interface up also generates RTM_NEWLINK. i wonder if this is supposed to be an 'interface was modified' event rather than specifically a new interface? 12:44:11 lw: git --rebase will require me to read a few times... i came tot he conclucion, makes sense.. multiple people are doing changes.. sometimes you want to commit a subset of yours, while someone else is working on it. BUt be careful rebase is not the holy grail.. it can be schrubbery and a black knight with no legs.. if not careful 12:44:26 the git/scm handbook.. oh boy 12:46:48 voy4g3r2: in this case it's not really that different from merge. the main difference is instead of the history being [old commits]-[your commits]-[merge commit]-[new commits], it becomes [old commits]-[new commits]-[your comments] - i.e. it reapplies your commits on top of the new commits, as if you'd done it that way to begin with 12:48:28 yeah.. i need to reread, that was not sticking in my brain 12:50:49 imagine it plucks your commits out of the history and puts them back at the top of the history 12:51:34 so your commits are always the latest commits on the branch, even when people have pushed new commits since then 12:53:51 yeah, rebase is just cherry-pick underneath 12:53:55 voy4g3r2: this might help, maybe it's easier to follow than the git manual: https://git-rebase.io/ 12:53:57 Title: Learn to change history with git rebase! 12:54:04 ah, so i can have commits over days/weeks and other people are doing their work.. and i go, well there stuff is cool.. so let me add to mine and make a pretty hisetory instead of a merge/branch nightmware 12:54:15 yeah, exactly 12:54:29 when you submit a PR you want your commits to be the latest commits on the branch, that's what rebase does 12:54:41 (it can also do a lot of other useful things, but this is the most important) 12:54:51 (well, until you start doing squash / fixup) 12:54:59 ah and in that PR history, it shows (which i was trying to do) a rebase 12:55:05 and me making a mess of things :) 12:55:23 rebases don't show in the PR history at all because they're invisible in the history, what shows in your PR is a merge 12:55:58 ah, i did try the rebase functionality in github and was like.. yeah i think this looks worse.. but i am nieve in this area to be quite honest 12:56:04 a merge being like a history entry that explicitly merges two branches together: your branch and the new upstream branch 12:56:18 i am just pushing forward as these man pages need to be cleaned and i am NOT looking forward to 12:56:22 "relearn" C :) 12:56:42 i wouldn't worry about this too much because it's possible for someone else to fix it, but it's worth learning at some point :-) 12:56:51 (since many projects expect PRs to be submitted this way) 12:57:20 yeah and i am starting to see why upstream is better to work on than 14 12:57:46 you could actually make changes on 14 and rebase them onto main if you wanted (but i don't suggest doing that, always easier to work on current) 12:57:50 because a few of these man pages do not make sense, as current has changed/modified/refined a lot of stuff.. so it will always be a chicken and egg thing 12:58:30 fwiw, if you decide to split these into separate commits, and you can identify which commits should be backported to 14 or 13, you can include 'MFC after: 2 weeks' in the commit message to indicate that 12:58:52 (this is one benefit of more, smaller commits) 12:59:54 ah, yeah i may look at that.. when work decides to STOP throwing meetings on my calendar... thankfully european collegues go home in 3 hours :) 13:01:30 i guess one last one.. i made a jail for this work (to minimize screwing up my server), i can just pull the -CURRENT branch even though working on 14.0.. and use the mandoc utility to "build" the man pages for a sanity check? 13:02:05 yuripv was making a few references to mandoc.. even found a bug in the html output vs man page output and links.. 13:03:19 you can try 'man ./manpage.1' but i'm not sure how you'd go about using the current mandoc on 14, i've never tried that 13:05:03 i really do not understand rtnetlink(4)... i'm subscribing to RTM_NEWLINK and i want to get IFLA_IFNAME in the message, how do i tell the kernel that? 13:10:08 ah, apparently you get this by default 14:20:54 how do i print aligned columns of data with libxo, without having to calculate padding myself? i can't seem to find anything about this in the documentation 14:36:51 @lw use column -t 14:38:50 i mean from C 14:39:26 it seems like using {Vh:} prevens padding from working... so {Vh:somevalue/%-30d} won't be padded 14:43:33 ah ok so you need to do it like this: "{[:8}{Vhn,hn-decimal,hn-1000:txrate/%ju}b/s{]:}" 15:42:48 lw: netlink messages apparently have flags that `route monitor` doesn't dump, what do those look like for all of these? 15:43:22 just digging through the kernel it's a little annoying to trace down how and whene these are generated 15:43:32 when, even 16:02:25 kevans: nlmsg_flags is 0 for all the messages 16:03:34 https://www.le-fay.org/tmp/30d/QXuaKm.txt 16:04:01 yeah I don't see how these are useful 16:26:24 kevans: tried printing out a couple more fields, there are a lot of different flag-type fields here https://www.le-fay.org/tmp/30d/YEewO6.txt 16:26:46 ifi_flags is presumably the flags ifconfig prints, i'm not sure what ifi_change is 16:29:45 nimaje: rctl is for resource management right? it's prollydisabled by default as not everyone uses it? 16:30:24 does anyone run thin jails inside thick jails? and i wonder what the overhead cost is for the middle jail? 16:37:36 alepzi-: but being enabled by default would make it easier to start using it and if it doesn't really have costs having it enabled, then that seems like a better default, so I'm asking for the costs that has, because I don't really expect costs from merely enabling it 16:49:45 nimaje: i agree. 16:55:32 https://github.com/freebsd/freebsd-src/blob/HEAD/sys/kern/kern_racct.c#L68 16:55:33 Title: freebsd-src/sys/kern/kern_racct.c at dfe30e41967f9b5112c42ca20ec2c366db74cef9 · freebsd/freebsd-src · GitHub 16:55:47 that's the default in all KERNCONFs 16:58:22 otoh, if we move people over to MINIMAL, they'd get used to adding stuff to loader.conf so it wouldn't feel like that big a deal 16:59:08 but why enable it if it's not in use? 16:59:27 just because it's easier to start using it? that's called proper configuration which isn't even hard 17:03:49 meena: if you want to get ppl to WANT to go to MINIMAL, do some serious benchmarks or whatever that shows it has a benefit 17:04:07 either reduced attack surface, better perf, etc 17:04:30 why isn't there a loader tuneable for ulimit and default that to disabled? most people don't set ulimits 17:07:11 alepzi-: MINIMAL boots significantly faster, for one. 17:11:50 but still, it would be nice if these things could be enabled without a reboot 17:13:01 I don't even see why it needs a tuneable, do I miss some costs of enabling rctl there? 17:17:08 alepzi-: a jail just existing doesn't really have all that much overhead on its own 17:17:44 lw: what a mess... hopefully melifaro can shed some light 17:21:37 kevans: a thick jail has atleast the disk requirement of a full base which is what, 1GB? 17:21:47 vs a thin jail zfs template clone which is basically 0 17:22:20 sure 17:22:27 then there's runtime cost, is there any ram or cpu overhead to a jail layer? 17:23:47 nothing significant; unless you're running closer to the order of thousands of these, I'd be surprised if you notice any impact 17:24:15 struct prison is relatively light, it has to be maintained in the allprison list just like any other 17:24:22 maybe 1% cpu and ram overhead vs running the binary in the host directly? 17:25:24 should be <<1% and nesting shouldn't add any addiional overhead 17:25:31 what's struct prison? 17:25:42 wow that low? that's almost free 17:26:11 yeah, I'd probably estimate lower as well... we don't exactly spend a lot of our time searching jails 17:26:24 struct prison is the internal representation of a jail 17:27:46 any potential footguns i should be aware of if i'm putting thin jails in thick jails? 18:29:12 On a Gentoo system I am able to mix "stable" with "testing" packages. Can I achieve this somehow with FreeBSD ports? Basically try mixing quarterly with latest via poudriere somehow? 18:29:26 By packages, I mean ports. 18:40:21 beastwick: that's not really how we roll… 18:41:35 but sure, you can duplicate the repo definition and have Fbsd-quarterly and Fbsd-latest and then run into all kinds of pain 18:43:40 Does anyone know if it is possible in FreeBSD to send raw commands to a ps2 port? 18:45:49 well, latest isn't really "testing" stuff that is in the ports tree should work, quarterly is just that you have less versions jumps and at more predicable times 18:46:57 but you could try building stuff from quarterly and cherry-picking from latest 18:47:36 On linux raw ps2 port voodoo is sort of possible in a very roundabout way by enabling serio_raw (which effectively disables atkbd), send the command to /dev/serio_raw and then remap the bus to atkbd ... i think on FreeBSD kbdcontrol can be similarly used to attach/detach a keyboard, but i'm not seeing an an obvious equivalent of serio_raw 19:41:24 jns: what does that achieve 20:36:59 Curious, does anyone here run quarterly userland, but also use a jail for certain "latest" packages? Is this a viable approach? I am split on running mostly quarterly with some cherry picking, or using a jail. My goal is to minimize manual work. If I cherry pick, I have to manually build against installed dependencies. I say to my self, it will only be for a small set of software, but truthfully - 20:37:01 it tends to grow. 20:44:14 or am I thinking about this wrong? 20:51:46 why not using the official pkg repo? then it shouldn't matter that much on the manual work side if you use quarterly or latest 20:54:43 nimaje I want to use mostly quarterly, but "backport" if you will some latest packages, just was curious if a jail could help me out here 21:03:42 depends, for the normal usecase of jails, putting services in a seperate system it should work perfectly fine 21:27:14 beastwick: latest packages are "backported" quite frequently, if there's serious bugs or security issues 21:30:02 see, https://freshbsd.org/freebsd/ports/branch/main?q=MFH 21:30:03 Title: FreeBSD / ports - FreshBSD 21:57:26 meena: what does what achieve? 21:58:57 jns: the thing you're describing. can you go a level above. what are you trying to advice 22:00:36 oh, sure,.. i have a rather exotic keyboard, it has a built-in vfd display, controlled with ps2 commands, and over 100 individually controllable led's and such... (and a bunch of extra keys) 22:01:12 i managed to make the extra keys scannable by slightly modifying the atkbd kernel driver, but that doesn't really help me with the extra leds or display 22:01:32 am i wasting my time if i try to get bhyve on bsd box.. to get -CURRENt operational? 22:18:28 meena: on linux i used to use this little script to write text to the display: https://linkerror.com/stuff/vfdwrite.sh.txt -- obviously won't work on FreeBSD because there's no raw serio, at last not as far as i know -- i just wanted to confirm i'm right about that, really... I'll probably end up having to write a driver 22:20:37 ls 22:20:41 err don't mind me 22:25:40 voy4g3r2: bhyve should work fine and running a freebsd vm with it should be easier than to run an android-x86 vm with it, do you have any problems? 22:44:52 Hello all, after installing Docker on FreeBSD 14, how do I start the Docker daemon? 22:45:59 nimaje: that is good to know 22:47:05 service docker start doesn't seem to start the daemon 22:48:25 signalblue: anything in logs? 22:49:06 meena: docker does not exist in /etc/rc.d or the local startup directories (/usr/local/etc/rc.d), or is not executable 22:49:34 that is the result of service start docker 22:54:43 hm, it only has bin/docker maybe it works without a daemon? 22:55:24 how so? 22:57:57 ah, it has an install message, you need docker-machine too, could be added in the pkg-descr too, so that people are more likely to see it 22:59:35 but that one too brings only an executable and no documentation, so no idea how it is used 23:07:02 nimaje: I assume you do not use Docker 23:13:23 Anyone happen to run OpenHAB on a Raspberry Pi? I swtich pkg to Latest to install 4.1.0, but there is a issue with com.sun.jnathat has no freebsd aarch64 support, only x86 and x86-64 from what I can tell from the log 23:13:36 pkg quaterly only has 2.5.something 23:14:16 I don't use docker, I just looked what these ports build and install 23:47:02 weust: how is Java not pursuing aarch64 Tier 1 support? isn't it supposed to be running on 14 billion devices, most of which are phones and most of which, by now, are aarch64? 23:47:41 signalblue: the pkg-message for docker mentions only installing the client, which can talk to remote host's daemons. 23:51:25 meena: it's supported arm64 for ages, maybe just not on freebsd? 23:53:15 lw: maybe 23:54:33 <_xor> What's the main difference between /usr/local/man and /usr/local/share/man? 23:54:47 _xor: the first shouldn't exist 23:54:54 anything installed in there is a ports bug 23:55:26 i think this was a bit unstandardised until recently though? 23:56:31 any potential footguns i should be aware of if i'm putting thin jails inside thick jails? 23:56:33 <_xor> Don't know, but I was just refreshing my memory on port macros related to man pages. During that process I noticed /usr/local/man and /usr/local/share/man, and wondered what the difference was. 23:57:08 <_xor> I have a bunch of files in /usr/local/man/*, looking up which ports put them there currently. Apparently, samba is one of them. 23:57:59 alepzi: you will consume more space than thin jails :) 23:58:11 <_xor> doas, sudo, pkg ,etc. Bunch of ports. 23:58:25 <_xor> Are you sure that it's /usr/local/man that's not supposed to exist? 23:58:27 _xor: the adventures of man pages :) 23:58:42 _xor: i'm fairly sure but i can't find where i saw that now 23:58:43 meena: java, imo, lost cross-platform when it started to ass architecture specific code 23:59:11 but, in this case I see OS's like win and, of course, linux with aarch64 included. and MacOS 23:59:52 ass architecture