00:23:41 <FUZxxl> Greetings!
00:24:01 <FUZxxl> I recently noticed that FreeBSD no longer creates /dev/ada0p0 and similar device nodes
00:24:08 <FUZxxl> when did this change?  What can I do to reenable them?
00:28:41 <FUZxxl> (instead it now only creates /dev/diskid/... nodes which sucks)
00:28:51 <RhodiumToad> it creates both by default
00:29:04 <FUZxxl> not on this system (13.2-RELEASE
00:29:05 <FUZxxl> )
00:29:25 <RhodiumToad> what's the output of geom -t  ?
00:30:17 <FUZxxl> RhodiumToad: http://fuz.su/~fuz/text/geom-t.txt
00:31:23 <RhodiumToad> and  ls -l /dev/*da*  ?
00:31:40 <FUZxxl> # ls -l /dev/*da*
00:31:40 <FUZxxl> crw-r-----  1 root  operator  0x7d  8 Sep. 00:26 /dev/ada0
00:31:40 <FUZxxl> crw-r-----  1 root  operator  0x81  8 Sep. 00:26 /dev/ada1
00:32:46 <RhodiumToad> so. what's happening here is that zfs thinks it owns the whole of /dev/ada0,
00:33:25 <FUZxxl> this is correct, it does
00:33:29 <FUZxxl> I am asking about ada1
00:33:39 <RhodiumToad> and zfs also ended up tasting the p3 partition on ada1 via the diskid label before finding the direct ada1p3 entry, so it opened the disk that way, which disables the partition entries for ada1
00:33:41 <FUZxxl> (I said ada0p0 before as to not open questions about device numbers)
00:33:48 <FUZxxl> oh for fucks sake
00:33:51 <FUZxxl> why does it do this shit
00:34:05 <FUZxxl> why does opening the partition one way disable the other entries?
00:34:10 <FUZxxl> Shouldn't they be symlinks or something?
00:34:11 <RhodiumToad> this is why the installer turns off diskid and gptid if you install as zfs
00:34:35 <FUZxxl> well this explains why I have no swap at least
00:34:36 <RhodiumToad> it's to do with the "exclusive open" flag in geom
00:35:34 <RhodiumToad> zfs opens the partition exclusively, so glabel (providing the diskid/* entry) passes that down to its open of ada1,
00:35:42 <RhodiumToad> which prevents gpart from opening ada1 itself
00:36:10 <FUZxxl> this is a shit design
00:36:19 <RhodiumToad> not at all
00:36:35 <RhodiumToad> geom is a very good design, the problem is that zfs thinks it knows better
00:36:45 <FUZxxl> then ZFS must be patched
00:37:06 <RhodiumToad> (though to be fair, some geom classes have a similar issue)
00:38:40 <RhodiumToad> anyway, diskid and gptid can be disabled via sysctl
00:40:04 <FUZxxl> I want both
00:40:11 <FUZxxl> I want the issue fixed, not a workaround
00:42:03 <RhodiumToad> as far as I know, zfs doesn't have a way to tell it which provider to use by name (rather than by content)
00:42:33 <FUZxxl> I see the problem in that geom has to propagate the exclusiveness down to the root
00:42:43 <FUZxxl> when it should suffice to have this one partition be exclusive
00:42:49 <RhodiumToad> (and if zfs did open /dev/ada1p3, that would make the /dev/diskid/* entry for the disk go away, because again, exclusive open)
00:42:56 <FUZxxl> shit design
00:43:16 <RhodiumToad> the problem with your idea is this:
00:44:15 <RhodiumToad> if /dev/ada1p3 is open exclusively but gpart didn't propagate the exclusive open to /dev/ada1, then /dev/diskid/xxp3 could be opened as well, violating the exclusion
00:44:25 <FUZxxl> the problem is
00:44:47 <FUZxxl> that diskid appears to be implemented as an interposer
00:44:59 <RhodiumToad> diskid is part of the glabel class
00:45:07 <FUZxxl> instead there should be some sort of aliasing system
00:45:30 <FUZxxl> and diskid/whatever should be implemented by creating aliases for other geoms
00:45:33 <FUZxxl> so this issue does not appear
00:46:04 <FUZxxl> (normal glabel nodes cannot be aliases because they are shorter than the underlying provider as they eat a sector for the label iirc)
00:46:28 <FUZxxl> this could even be reflected by having /dev/diskid/foo be a symlink in devfs
00:46:37 <RhodiumToad> that's just one of the cases glabel implements
00:46:52 <FUZxxl> so?
00:46:59 <FUZxxl> what sort of reasoning is that?
00:47:49 <FUZxxl> that's like saying "oh we couldn't be arsed to do that right because this is one instance of a bunch of things we couldn't be arsed to do right"
00:48:10 <RhodiumToad> what I meant was that "normal" is not the wrong term
00:48:17 <RhodiumToad> *not the right term
00:49:59 <FUZxxl> RhodiumToad: I suppose sure they are all implemented the same way
00:50:07 <FUZxxl> shows that they maybe should not be
00:51:16 <RhodiumToad> glabel implements labels based on disk id, partition id, filesystem id, filesystem volume label, etc. and the explicit labels are just one additional option
00:52:04 <FUZxxl> you don't need to explain that to me
00:52:08 <FUZxxl> what point are you trying to make?
00:52:14 <RhodiumToad> also you'll note that DEV (which creates /dev/blah for geoms) is just another geom class
00:52:25 <RhodiumToad> the whole thing is highly modular
00:52:41 <FUZxxl> once again, you don't seem to be making a point
00:53:07 <RhodiumToad> the point is that there are reasons for the design
00:53:23 <FUZxxl> doesn't change that the design apparently has an idiotic flaw
00:53:46 <FUZxxl> just because a design is complex doesn't mean that it is unchangable
00:54:02 <FUZxxl> I see no technical reason why this cannot be fixed
00:55:18 <RhodiumToad> the design is not at all complex, it's very simple in fact
00:55:43 <FUZxxl> that once again does not change my point
00:56:11 <FUZxxl> just because a design is simple doesn't mean that it is unchangable
00:56:26 <RhodiumToad> adding the kind of aliases you're talking about would actually make it substantially more complex, because it's a major layering violation
00:56:50 <FUZxxl> you just need to find the right place to implement these
00:56:59 <FUZxxl> or rethink how the mapping of geoms to device nodes work
00:57:31 <FUZxxl> hardlinks are also a layering violation
00:57:33 <FUZxxl> yet they work
00:57:50 <FUZxxl> and I'm not even asking for hardlinks...
00:59:16 <RhodiumToad> right now a device node exists for each provider (that's not exclusively open by another class). for a provider to have multiple aliases in /dev would require some mechanism for getting all aliases suggested by classes further down the tree, and dealing with the resulting combinatorial explosion
00:59:33 <FUZxxl> so what
00:59:39 <FUZxxl> then such a change may have to be done
00:59:55 <FUZxxl> just because the design doesn't account for a solution to the problem right now doesn't mean it cannot be changed to do so
01:00:15 <FUZxxl> I'm sure nobody is going to DOS your system by creating too many nested aliases
01:00:45 <FUZxxl> plus you can resolve the combinatorial explosion by e.g. linking to paths in subdirectories that can in turn by symlinks
01:01:00 <FUZxxl> such that each alias is represented by a single symlink in the end
01:01:58 <RhodiumToad> that would require for example changing the way *pN and other suffixes work
01:02:02 <FUZxxl> e.g. (ignoring compatibility for now), one could have the canonical device node be /dev/ada1/p4
01:02:07 <RhodiumToad> right
01:02:16 <FUZxxl> and then have /dev/diskid/foo be a symlink to ../ada1
01:02:18 <RhodiumToad> which prevents you having /dev/ada1
01:02:48 <FUZxxl> I specifically said to ignore compatibility for now, but I guess you don't care
01:03:32 <FUZxxl> Now the design can be made compatible by having the system generate symlinks from the old names to the new path-like names when they are accessed
01:03:52 <FUZxxl> just like /dev/dsp is only generated when you access it
01:04:25 <FUZxxl> (of course you need to chose file names for the new stuff that do not clash with the old stuff)
01:04:59 <FUZxxl> e.g. if you access /dev/ada1p2 the OS parses the name and tells you "it's a symlink to dsk/ada1/p2"
01:05:08 <FUZxxl> and then the usual path resolution rules apply
01:05:27 <RhodiumToad> by all means implement it and see whether anyone likes it enough to allow it in
01:05:53 <FUZxxl> too much other stuff to do
01:06:01 <FUZxxl> and I am not familiar with the subsystem
01:06:42 * RhodiumToad has contributed small patches to geom code
01:07:06 <FUZxxl> nice
01:07:39 <RhodiumToad> specifically, the allow_nesting options in gpart
01:08:13 <FUZxxl> and quite useful
01:22:00 <RhodiumToad> hm. it looks like about half the infrastructure needed for what you want is already in place
01:27:27 <RhodiumToad> there's support for this case: a disk device driver (e.g. nda) can create an alias (e.g. nvd0 -> nda0)
01:28:44 <RhodiumToad> and geom classes will respect that by creating their own aliases (e.g. nvd0p1 -> nda0p1)
01:49:00 <xulfer> Hey all
01:52:17 <FUZxxl> RhodiumToad: sounds like it could work
01:52:52 <FUZxxl> so glabel would have to be modified to inject aliases into other geoms?
01:58:43 <RhodiumToad> something along those lines. but the trick will be to make it work more dynamically, I think currently it only checks for aliases when initially attaching the device
01:59:18 <RhodiumToad> basically it looks like enough work was done to allow the specific case of nvd -> nda
01:59:48 <RhodiumToad> (which is why I said its only about half the infrastructure, that's not counting the actual work of choosing aliases)
02:08:02 <FUZxxl> hm hm I see
02:14:37 <RhodiumToad> maybe exposing the aliases as a named attribute, and posting an attrchanged event when aliases are changed, and having providers react to that
03:09:46 <FUZxxl> could work
04:36:47 <adilix> hi all
04:45:35 <FUZxxl> hi
05:06:50 <kenrap> I hope the cybersecurity job I get will let me use FreeBSD
05:07:27 <kenrap> (in the future)
05:08:36 <kenrap> I wouldn't want to use Ubuntu or Parrot.
05:09:43 <FUZxxl> it depends
05:10:28 <kenrap> Although to make the boss happy, I could convince them that I can run them in Linux jails.
05:11:17 <kenrap> If the jails get compromised, easier to recover from
05:12:58 <kenrap> and use ZFS snapshots of the jail(s) for the forensics of them.
05:13:23 <FUZxxl> not if the kernel gets compromised
05:13:33 <FUZxxl> though this is the same situation as with Docker on Linux
05:16:08 <kenrap> Then I have to suck it up.
05:50:17 <xulfer> Hm anyone else use synth?  It's getting hung up on a port that has no pkg alternative.
05:50:30 <xulfer> namely textproc/obsidian
05:52:42 <FUZxxl> what do you mean by "no pkg alternative"?
05:55:10 <xulfer> there is nothing for it in pkg.  So in synths case (and maybe poudriers?) it seems to be skipping it because pkg complains about it.
05:55:38 <xulfer> don't think it's a bug.  feels like i'm missing something obvious here
05:55:44 <FUZxxl> oh you mean no package+
05:55:58 <xulfer> oh yes sorry
05:56:10 <FUZxxl> let me check
06:21:21 <RhodiumToad> it has a restrictive license
06:22:06 <RhodiumToad> what do you mean by "hung up"? it may need you to accept a license or somesuch
06:26:50 <RhodiumToad> (that's why there's no pkg for it, because packages are only built for ports whose licenses permit distribution of packages...)
06:32:06 <xulfer> I'm checking on that
06:32:39 <xulfer> on the accepting the license being a potential issue
06:34:58 <xulfer> Yeah it isn't even producing a package for it.  Which makes sense.  Is there no way around it then you think?
06:37:28 <xulfer> Mostly asking out of curiousity. I can install it by just using make just fine.  If there's a step that would enable me to let synth handle it in the future all the better.
06:40:54 <FUZxxl> xulfer: fix the license so FreeBSD can redistribute a binar
06:40:55 <FUZxxl> y
06:41:20 <xulfer> yeah thought as much
07:36:22 <angry_vincent> would /dev/dsp4 be the one for dev.pcm.4? ( in my case )
07:36:25 <angry_vincent> pcm4: <Conexant CX20590 (Analog 2.0+HP/2.0)> (play/rec) default
07:47:50 <RhodiumToad> xulfer: LICENSES_ACCEPTED+= whatever   in make.conf
07:48:40 <RhodiumToad> where "whatever" is the license name used in the port
07:49:09 <RhodiumToad> that satisfies poudriere, I dunno about synth
07:49:42 <RhodiumToad> angry_vincent: yes, though /dev/dsp* nodes are created on the fly
07:50:04 <RhodiumToad> angry_vincent: and /dev/dsp without suffix refers to the default unit
07:50:12 <angry_vincent> great
07:50:29 <angry_vincent> i am fiddling with sndio and hence the questions
11:35:15 <xulfer> ohh thanks
11:36:38 <xulfer> don't suppose anyone might be familiar with why i3 hjkl bindings don't seem to be working?
11:37:37 <xulfer> seems to be a common problem i guess?  worked for me before.  just checking to see if mayhaps anyone in here might know exactly what i'm talking about.
14:15:44 <dvl> S3 option added to bacula11 and bacula13 FreeBSD ports.
16:41:36 <scoobybejesus> anyone use syncthing on their freebsd box(es) and get the kqueue warning (notice)? https://forum.syncthing.net/t/warning-of-high-usage-system-slow-down-despite-small-amount-of-files/19994 . I'm curious if the knowledgeable folks here do any tuning/etc
16:41:37 <VimDiesel> Title: Warning of high usage / system slow down despite small amount of files? - Support - Syncthing Community Forum
16:57:52 <meena> hrm…
17:01:25 <meena> RhodiumToad might know something, but, RhodiumToad has been looking for some alternatives to kqueue for specific tasks
17:02:12 <meena> scoobybejesus: ^
17:03:21 <scoobybejesus> I'll keep an eye out!  Thanks!
17:09:26 <dstolfa> scoobybejesus: depending on what kqueue is watching, it can use a lot of file descriptors. the only thing a kqueue can tell you about a directory is that a file was created/deleted/etc on it, but it cannot tell you what file was modified and how. if you want to monitor all files within a specific directory recursively, and that happens to be many files, kqueue will use up a file descriptor for every
17:09:31 <dstolfa> single file because you will need to open it in order to listen for changes on those files. kqueue is really not a great way to monitor directories sadly.
17:10:13 <dstolfa> by contrast, inotify on linux can handle that fine, but because it treats the filesystem as a tree rather than a DAG, inotify breaks with hardlinks
17:12:18 <dstolfa> a couple of years ago i've extended kqueue to insert additional per-event data but the locking required was extremely messy (and probably racy) and the performance was likely unacceptable so i scrapped the whole idea of making it more generic to support filesystems
17:21:06 <scoobybejesus> i've got about 40k files in there now.  it grows fairly slowly, and the box is a little oversized for its load, but still. i'd like to think 115G of data wouldn't cause the system to run out of file descriptors and come to a halt  .. or whatever would happen
17:23:18 <meena> I'm surprised there's no tunable to raise any potential kqueue limites
17:48:13 <CueXXIII> hi, i wonder if there still is an upstream for ee. i tried to build it on linux out of curiosity and ran into some bugs…
17:48:22 <CueXXIII> or should i submit the patches to freebsd?
18:04:06 <pstef_> what kind of bugs? Or just system incompatibilities?
18:19:39 <CueXXIII> pstef_: it has an unguarded __FBSDID() macro in ee.c and when building with new_curse.c a struct gets declared twice
18:20:23 <pstef_> the latter might be a bug
18:26:58 <CueXXIII> pstef_: https://bsd.to/prvZ would be the patch to the 2nd issue
18:26:59 <VimDiesel> Title: dpaste/prvZ (Diff)
18:29:27 <pstef_> from our point of view, ee is supposed to have an upstream, but I can see that we've applied numerous fixes over the years
18:31:20 <CueXXIII> and the upstream page i found ( http://mahon.cwx.net/ ) seems to be down
18:32:39 <CueXXIII> last upstream version also was imported in 2010
18:33:06 <pstef_> I wonder how much has happened upstream since then
18:41:33 <pstef_> CueXXIII: what is the warning/error that you get without this patch?
18:44:30 <CueXXIII> pstef_: https://bsd.to/0vBq - since new_curse.h gets included in both new_curse.c and ee.c
18:44:31 <VimDiesel> Title: dpaste/0vBq (Plain Text)
18:45:58 <meena> pstef_: given that upstream is defunct, i don't think much has happened upstream
18:47:13 <pstef_> new_curse.c doesn't seem to get compiled under FreeBSD
18:48:06 <CueXXIII> pstef_: yeah, freebsd configures ee to build against ncurses
18:49:14 <meena> Also, we probably need to get rid of https://github.com/freebsd/freebsd-src/blob/main/contrib/ee/ee.c#L58 like we got rid of the others. but this is in contrib, which is the reason it wasn't axed
18:49:15 <VimDiesel> Title: freebsd-src/contrib/ee/ee.c at main · freebsd/freebsd-src · GitHub
18:50:58 <meena> So with upstream defunct, we'd move it to usr.bin/ee and remove new_curse.(c/h)
18:52:24 <pstef_> patches welcome :) Best sent via phab
18:55:23 <CueXXIII> meena: ah, so you are removing new_curse for good?
18:56:01 <meena> CueXXIII: i don't have commit, but that's what i would do
18:57:22 <meena> I am busy doing other things, for which i (luckily) also don't have commit (because I have no idea what I'm doing)
18:57:36 <meena> but! there's always reviews!
19:02:14 <pstef_> why remove new_curse?
19:04:28 <meena> if we're moving it usr.bin/ee and not using, that seems sensible, but maybe I'm shooting too fast from the hip here and not looking at the bigger picture
19:06:40 <meena> https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=ee-editor
19:06:41 <VimDiesel> Title: PKGBUILD - aur.git - AUR Package Repositories
20:07:20 * _xor is going through storage boxes
20:08:13 <_xor> So far I've found my original Walnut Creek FreeBSD CD sets (2.1.7, 2.1.8, etc). Red Hat Linux 5.0, some ZIP disks, a few JAZ disks. I also have my original Sun SPARC workstation.
21:19:49 <CrtxReavr> _xor, which sparc?
22:31:32 <rtprio> haha, i had a sparcstation10 5? maybe one of each