06:22:51 From Proxmox to FreeBSD - Story of a Migration - https://it-notes.dragas.net/2024/10/21/from-proxmox-to-freebsd-story-of-a-migration/ 07:36:30 nice stefanobsdcafe.. here i am using freebsd for personal reasons and everyone got professinal stuff. i feel stupid lol 07:58:23 I'm using it because I can't stand package politics with the 'gnome teams' and redhat having way to much influence of that whole ecosystem 07:59:31 nobody assumes freebsd to have systemd which is nice and the ports tree is made by people who actually just want to use software, not push other people to use or not use their software 07:59:49 even if it's not $CURRENT_THING 08:04:31 also linux audio is horrible 08:07:09 i wish freebsd's packetfilter was a good as openbsd's though 08:07:28 and freebsd takes months sometimes years to fix bugs where openbsd and linux only take weeks 08:26:41 hmm 08:27:06 sfox: why do you day it takes freebsd years ? 08:27:12 say* 08:27:22 huh? 08:27:46 01:25 < sfox> and freebsd takes months sometimes years to fix bugs where openbsd and linux only take weeks 08:27:47 because some of the bugs i'm tracking in the bugtracker 08:27:53 oh ok 08:29:12 i wonder why 08:29:31 priorities probably 08:29:41 Linux often maintains known bugs, because the rule is to never break userspace, and fixing many of the known bugs in the kernel causes userspace to break. 08:30:24 The consequence of having the kernel made in total isolation from every other component. 08:30:52 one of 08:30:58 funding 08:31:09 and in openbsd's case.. obcession 08:31:10 OpenBSD is the opposite of that. They will break just about anything in name of security. 08:31:11 probably 08:31:26 remiliascarlet: i never understood how can the kernel work with all the gnu tools if its isolated like that ? 08:31:55 but at the same time, you have to remember only 1% of the linux foundation's funding actually goes towards funding linux development 08:31:57 jb1277976: Which is why there's no such thing as consistency in the Linux space. 08:32:07 this is why linux audio is still screwed 08:32:18 got it 08:32:52 hence 1k distros probably lol 08:33:37 meaning there are peobably 1 thousand distros available 08:33:43 probably* 08:34:15 The point of Linux is to have it like a Lego set, which you put together with whichever parts you want, which as a concept is a really nice thing, but also results in having teams of developers with absolutely nothing in common with one other, and they don't even know each other, put together an full OS. 08:36:57 (Linux audio is just fine.) 08:40:17 hello, is there a way to monitor a progress of a freebsd-update install command ? 08:40:41 its just sitting and doing silently something for > 6 hous 08:40:45 *hours 08:41:42 yes I can see something from top and truss but .... having something more convenient is better 08:57:27 kfv: what happened? 08:57:43 kfv: what happened? 10:45:37 Alver: for certain values of fine including not fine 11:49:15 debdrup: I've been running Linux on desktop/laptop since the late nineties. I can remember a two or three cases where sound needed some mending. None of those cases are in the last... I dunno. Ten years or so. 11:49:43 As with everything Linux, it's easy to break if you want to. 11:59:49 nerozero: thats weird... 12:04:10 HER, ? 12:29:14 Alver: in my experience, linux audio is usable but i wouldn't call it "fine". merging channels can be a massive pain and equalizer software that does all the things that you can do on windows and mac just doesn't exist 12:42:54 nerozero: you can pass --debug to freebsd-update to maybe see more about what is going on, it's a shell script which calls other things so maybe it's a network problem or other issue 12:45:39 I found a better way to see almost exactly the progress percentage, step 1: truss -p 2>&1 | grep fstat 12:45:58 copy the file which is listed in fstat 12:46:25 then open vim $(find /var/db/freebsd-update/ -iname "*install")/INDEX-NEW 12:46:36 search for the filename 12:47:08 then look at vim % of the lines - this almost exactly represents the progress 12:55:24 so, it was making progress? just slow network? 13:02:30 aquamo4k, 6hours, bsd13.3 -> 14.1 13:02:33 done 13:02:44 file things ... 13:17:41 Alver: less than a week ago I saw someone complaining about it breaking 13:26:48 debdrup: If I look around for 5 minutes, I can find a dozen people complaining about literally any piece of technology in existance. :°) 13:27:16 But yes, I do suppose that if you have higher requirements than sound working on various outputs, it can get messy 13:27:34 I wouldn't want to try low-latency mixing stuff in Linux. I mean, it might just work, but... god knows. 13:28:18 I can switch sound on my laptop from builtin to bluetooth speaker or headphones to USB DAC back and forth without issues, but I only do "output" stuff. 13:29:12 To men, "equalizer" is an expensive term for "modifying the original sound to make up for crappy output devices". :°) 13:29:16 s/men/me/ 17:26:20 is it my imagination, or does anyone else have an issue with /bin/sh where if you tab complete "too fast," it deletes 2 characters? 17:31:44 let me try 17:32:20 working ok here on 15-current on aarch64 17:33:32 i cant reproudce everytime. usually its when i open a fresh xterm and try to do `cd /usr/lo`. maybe one out of every 30 times, rather than tab-completing, `cd /usr/loca` becomes `cd /u/lo` or similar 17:34:11 do you use any special term emulator or $TERM? 17:34:33 no. I have seen it on plain xterm and kde Konsole so i suspect it is something with /bin/sh and not the terminal emulator 17:34:38 i never noticed with csh 17:35:19 it only happens when i type extremely quickly. i wonder if its something about tab completing while the prompt is still printing 17:36:00 interesting indeed.. I have noticed character issues with ssh connections if I don't use bash... but I have seen odd things like that in Linux as well 17:36:23 not on direct terminal logins though 17:36:41 i will not complain though, as i much prefer bourne shell :) Just wish /bin/sh had a `history` builtin 17:36:49 heh indeed 17:59:12 has anyone tried the 9pfs client in 15.0 yet? 18:09:35 ivy: not I... working on a RK3588 unit atm... 20:04:45 well, i tried it... seems to work so far. we'll see if it randomly panics or something 20:04:57 if it works this is a huge feature for bhyve vms 20:05:50 Nod.. I just got my Rock5 running successfully now so now I have another arm64 machine to work on.. 20:08:05 sadly no arm64 bhyve here as GICv2 isn't support (yet?) 20:09:04 bummer 20:09:44 I have nothing but arm64 and risc-v here.. 20:09:58 That's why you hear me talk about nothing else 20:11:06 my desktop is arm64, but i haven't found any affordable option to replace our fileserver yet 20:11:09 I have one token x86-64 I guess but its an old gaming laptop 20:12:30 Is this channel ok for social? 20:13:02 Mexis: according to the topic yes.. 20:13:50 Sorry, yea 20:14:58 np at all to me... I like the atmosphere since I've been back.. I was gone for a decade or more... 20:15:19 (probably closr to 2) 20:16:08 there's also #freebsd-social if you want to talk about a lot of off topic stuff but a bit is probably fine here 20:19:18 hmmm, need to find some linux isos to download to test my new 9pfs-based qbittorrent vm 20:20:18 Tenkawa: What do you do for work? 20:23:16 Mexis: retired 20:24:07 I worked in sysadmin,dba, network admin and coding my entire career though 20:25:06 Now I just volunteer to keep the skills current and help out 20:25:24 (and of course have fun) 20:27:12 Yea right, your like a wize wizard 20:27:25 wise* 20:27:27 Tenkawa: i will add you to my wizard list if i have a question 20:27:55 Heh.. not as much wise as just been through a lot lol 20:28:10 but considering i know nothing about db or db admin. probably it wouldn't be hard there 20:28:21 did you learn everything through experience or books or tutorials? 20:28:28 johnjaye: experience 20:28:46 I went to school to for psychology 20:28:59 s/to// 20:29:51 i guess it's different if you have a sql or mariadb thing to work on 20:29:55 as opposed to just reading about it 20:30:12 indeed 20:30:22 (in my opinion) 20:30:44 I learn better by hands on training though 20:32:29 Alver: sure, but pcm(4) has worked in FreeBSD since 1993. 20:33:46 In that time it's been rewritten completely, been extended with many new features, been made fully OSSv4-compatible, and is still being worked on to this day. 20:34:59 How long does it take to become a fbsd contributer 20:35:21 Multi-channel audio with volume-per-channel and virtual channels, bit-perfect and low-latency support and high-quality resampling were all added post-newpcm rewrite. 20:35:22 Mexis: depends on what kind. if you want to manage a port i think you have to go to the #freebsd-ports channel and ask 20:35:41 Mexis: literally no time at all, just submit some patches 20:35:44 drivers 20:35:49 Mexis: as long as it takes to write and contribute a patch i guess :). if by "contributor" you meant having commit access, that varies 20:36:24 but you don't need commit access to contribute patches 20:37:00 out of active, wired, buffer, cache, laundry, inactive, and free, what memory metrics can i sum to get a result which is equal to the total memory in the system? i tried summing everything and the result was greated than total memory, after removing buffer, it looks better 20:37:04 Mexis: there's no real timeline; if your goal is to contribute to FreeBSD, then do that. If you contribute enough that the work of the committer is significant enough, they can "punish" you (in the sense of "no good dead goes unpunished") with a commit bit 20:37:47 ivy: I have ~/.bin/mem that I can upload somewhere, which might answer that question - hold on. 20:38:13 keep in mind that having a commit bit comes with responsibilities. if you're constrained by time or whatever else, it's perfectly fine to just contribute patches without that 20:38:15 i'm assuming 'buffer' must be a subset of 'cache' 20:38:25 ivy: http://people.freebsd.org/~debdrup/mem 20:38:26 or maybe the other way around 20:38:44 contributor without commit bit is still a contributor 20:38:53 it was originally freebsd-memory.pl 20:39:12 Mexis: focusing on becoming a committer seems to me to be missing the forest for the trees, as it were. 20:39:46 Find something that looks like it needs doing, and start contributing patches. 20:40:31 debdrup: i'm not sure this is right as the first section doesn't sum to total memory for me - it's not including cache/buffer? 20:41:59 ivy: well, hw.physmem is the physical amount of memory in the system, is that what you're looking for? 20:42:19 That's the OID from sysctl(8) as reported by the kernel. 20:42:43 debdrup: what i'm after is the specific metrics i can sum that, once summer, will equal hw.physmem 20:42:48 s/summer/summed 20:43:37 ivy: I don't believe there's such a metric, because of the gap 20:43:44 which by experimentation seems to be active+wired+cache+laundry+inactive but i don't really understand why those specific values work and why buffer can't be included 20:44:00 what do you mean buffer? 20:44:20 also, you're forgetting free there 20:44:48 yes, add free to that list 20:45:02 debdrup: buffer and cache are exposed by prometheus node_exporter, i'm not sure specifically where it gets them from 20:45:52 ivy: that seems like a thing that the source code should be able to answer? 20:46:17 ah, the 'total' metric here is not hw.physmem, it's available memory minus any gaps 20:46:51 right, and there's always a memory gap - although i'll be damned if i can remember what it's for 20:46:54 debdrup: the script gives me some values, what i'm wondering is *why* these are the correct values 20:48:20 It's a pity markmail is gone, that might've had some answers. 20:49:00 unrelated... 20:49:02 PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 20:49:03 73908 root 1 135 0 13M 3520K CPU7 7 44.4H 100.00% bc 20:49:10 did the bc ^D bug get replaced by another bug? 20:49:40 damn, bc's being kept busy :D 20:50:27 drat can't seem to reproduce this, i should have straced it before killing it 20:50:58 although that system is running an old build so maybe it's the same bug 20:53:17 https://github.com/prometheus/node_exporter/blob/e6a9cfbdcdaa21bf9676c6cd37bef8160227f423/collector/memory_bsd.go#L66 seems to answer your other question? 20:54:52 no, that doesn't explain why including both cache and buffer adds up to more than total memory, and neither does the linked wiki page 20:58:34 looking at this, i'm not especially sure that the values they're using are ones they should be using, either 20:59:40 i tend to trust the script by rse@ more 21:00:39 also, i still don't understand why you need a derived value when the system will outright tell you how much memory it has in total 21:01:21 because i want a graph that includes total and free memory, and if the values i'm graphing don't add up to the total memory, something must be wrong 21:01:50 e.g., that could lead to the system reporting more memory is in use than is available (nonsense) or reporting some memory is free when there's really no free memory 21:04:23 where did you get this "buffer" and "cache" from? 21:04:42 debdrup: https://github.com/prometheus/node_exporter/blob/e6a9cfbdcdaa21bf9676c6cd37bef8160227f423/collector/memory_bsd.go#L66 21:04:59 yeah, it doesn't explain itself very well 21:05:21 there's a unified buffer cache in freebsd, but that's not what it's talking about 21:05:44 the buffer_bytes parameter is part of the wired amount, as outlined on the wiki page 21:06:33 ah, i was about to say, my guess is vfs memory is probably already accounted in wired 21:11:09 https://cgit.freebsd.org/src/commit/?id=8950c0148b2 vfs.bufspace is apparently a count of the cached pages, so i don't know how relevant for the total amount that is, since it's already accounted for 21:12:57 dg@ and dyson@ are the people behind the unified buffer cache mentione previously, and implemented here: https://cgit.freebsd.org/src/commit/?id=0d94caffcad 21:16:10 i'm also not gonna assume prometheus adds things up correctly based on all those values in order to actually achieve a total 21:16:38 so maybe find out where the actual addition is being done 21:19:41 otherwise, the easier solution seems to me to be get the node exporter the ability to read the hw.physmem OID, because a derived value trying to sum up all of the things collected is gonna be wrong no matter how you go about it 21:20:13 even if you somehow weed out all the things that're doubled up if you add them all together, there's still the memory gap 21:20:39 you'll note the script by rse@ doesn't attempt to explain it 21:20:58 it trusts the system to know how much memory it has 21:22:04 "the missile knows where it is, because it knows where it isn't".. 21:24:13 i feel like i'm not explaining the problem well :-) it already gets total memory from vm.stats.vm.v_page_count which is fine. the problem is that when graphing various users of memory, the 'used' values need to add up to the 'total' value, otherwise that's a sign that values don't make sense. (which is fine, that works, i just didn't understand why cache couldn't be included) 21:25:03 for example, without this sanity check, it would not have been clear that 'cached' should not be included as that accounts the same memory twice 21:25:10 ivy: you do realize that you're never going to be able to account for individual users memory either, because of shared memory 21:25:29 no, by 'users of memory' i mean active, wired, etc 21:27:39 the 'used' is never going to add up to the 'total', because of the memory gap 21:33:02 the 'cache' is a compatability shim at this point: https://cgit.freebsd.org/src/tree/sys/vm/vm_meter.c#n405 21:33:15 so the node exporter probably shouldn't be using that 21:35:41 it was changed in favour of https://cgit.freebsd.org/src/commit/?id=c869e672086f98 21:41:16 https://cgit.freebsd.org/src/commit/?id=7667839a7ec here's the removal of the code, so you can get an idea of what it used to do 21:42:38 so as usual the answer "what does this do" or "why is this the way it is" is in the VCS 23:57:44 I am cleaning up. I look around packages to remove. How can I have a list of dependent packages?