[2021-10-01T02:32:32Z] <ryoshu> illiliti: I was told that we want a daemon for monitoring
[2021-10-01T02:32:56Z] <ryoshu> as we don't want to allow multiple queues, unprivileged that make wired memory
[2021-10-01T02:33:09Z] <ryoshu> with a daemon we get normal memory management for messages
[2021-10-01T02:33:15Z] <ryoshu> distributed to users
[2021-10-01T02:39:01Z] <illiliti> what's the problem with multiple queues? fyi, linux allows unprivileged users to monitor events via netlink without any daemons. why netbsd can't simply allow to do the same thing?
[2021-10-01T02:40:51Z] <ryoshu> user-space buffering instead of kernel-space, but it is for consideration
[2021-10-01T02:41:49Z] <ryoshu> no problem with setting a limit on the number of users from user-land
[2021-10-01T02:43:17Z] <ryoshu> illiliti: regarding subsystem, we have devclass https://nxr.netbsd.org/xref/src/sys/sys/device.h
[2021-10-01T02:43:24Z] <ryoshu> we can pass it to userland
[2021-10-01T02:43:41Z] <ryoshu> and then we can add a subclass, for certain types of devices, like discrimination of input ones
[2021-10-01T02:48:39Z] <illiliti> interesting
[2021-10-01T02:48:54Z] <ryoshu> I think this makes all we really need
[2021-10-01T02:49:18Z] <ryoshu> https://susepaste.org/de3213bd my internal API
[2021-10-01T02:50:28Z] <ryoshu> subsystem->devclass, add devsubclass
[2021-10-01T02:50:37Z] <illiliti> looks good
[2021-10-01T02:50:50Z] <illiliti> what is *driver?
[2021-10-01T02:51:07Z] <ryoshu> kernel driver
[2021-10-01T02:51:25Z] <ryoshu> it is returned by drvctl so it would be a waste to drop it
[2021-10-01T02:51:38Z] <illiliti> ok
[2021-10-01T02:52:05Z] <illiliti> btw, openbsd has similar struct https://github.com/openbsd/src/blob/master/sys/sys/device.h#L53
[2021-10-01T02:53:31Z] <ryoshu> it should be a BSD thing
[2021-10-01T02:55:42Z] <ryoshu> I abandoned the idea to cache the state of devices in userland; it's prone to races and hard to lock it reliably I decided to always probe the data from the kernel behind the API calls.
[2021-10-01T02:57:14Z] <illiliti> yeah, this is good decision
[2021-10-01T02:57:28Z] <illiliti> caching is complicated
[2021-10-01T03:01:19Z] <illiliti> do you think it would be better to port devd or implement monitoing stuff to devpubd?
[2021-10-01T03:01:20Z] <ryoshu> now, I need to decide whether 1) the public api is devicetree.h, write libudev in pkgsrc for poor man compat 2) keep devicetree.h as internal api and export a netbsd specific udev.h that is sufficiently compatible with linux 3) do (2) + optionally add libudev compat harder versions for mimicking hwdb, /sys and netlink/socket
[2021-10-01T03:02:35Z] <ryoshu> I would like to switch all users of drvctl(4), including devpubd to devicetree(3)/udev(3)
[2021-10-01T03:02:57Z] <ryoshu> devd is freebsd specific, no plans to port it
[2021-10-01T03:04:38Z] <illiliti> sysfs, netlink and hwdb is unneeded
[2021-10-01T03:05:21Z] <ryoshu> but would a linux-style/like <udev.h> be superior over <devicetree.h>?
[2021-10-01T03:05:47Z] <ryoshu> going netbsd-only way is hard and prone to rejects in upstream for patches
[2021-10-01T03:08:11Z] <ryoshu> if you can/want to write a version for other kernels, it might be easier
[2021-10-01T03:08:52Z] <ryoshu> I don't know your future API plans
[2021-10-01T03:09:27Z] <testuser[m]> Hi
[2021-10-01T03:10:13Z] <ryoshu> I will try with option (2)
[2021-10-01T03:12:00Z] <illiliti> i'll publish the lib soon. i already implemented basic stuff for linux, netbsd and libudev backends
[2021-10-01T03:13:58Z] <illiliti> ryoshu: btw, why devicetree if we have drvctl? devicetree depends on daemon?
[2021-10-01T03:15:16Z] <ryoshu> I just wanted to pick an internal name, no dependencies on a daemon
[2021-10-01T03:15:38Z] <ryoshu> I think it's good to avoid a name libudev, for more proper compat lib; so no libudev linking with libudev
[2021-10-01T03:16:01Z] <ryoshu> for the same reason I want to pick <udev.h> instead of <libudev.h>
[2021-10-01T03:16:39Z] <illiliti> for consistency sake?
[2021-10-01T03:16:56Z] <ryoshu> libdevicetree offering udev.h, on top of that libudev-netbsd and offering libudev.h for emulating /sys and others
[2021-10-01T03:17:05Z] <ryoshu> for easier porting
[2021-10-01T03:17:18Z] <ryoshu> this is my idea
[2021-10-01T03:17:55Z] <ryoshu> dragonflybsd picked name devattr or such
[2021-10-01T03:17:58Z] <ryoshu> libdevattr
[2021-10-01T03:18:14Z] <illiliti> i don't like this idea. it's confusing
[2021-10-01T03:18:49Z] <ryoshu> do you prefer to see the lib named libudev?
[2021-10-01T03:19:54Z] <illiliti> my idea: libdevicetree offers devicetree.h and libudev-netbsd offers libudev.h. libudev-netbsd uses devicetree.h underhood
[2021-10-01T03:20:24Z] <illiliti> libdevicetree offering udev.h is just confusing
[2021-10-01T03:21:18Z] <ryoshu> do you think this API https://susepaste.org/de3213bd is good enough to use in 3rd party software?
[2021-10-01T03:21:26Z] <ryoshu> like libinput
[2021-10-01T03:23:27Z] <illiliti> you need to provide device type
[2021-10-01T03:23:36Z] <illiliti> keyboard, mouse, ...
[2021-10-01T03:24:07Z] <ryoshu> yes, this is in progress (devclass + devsubclass)
[2021-10-01T03:26:38Z] <illiliti> also, people usually prefer fd for polling instead of function
[2021-10-01T03:27:07Z] <ryoshu> and use poll(2) or similar?
[2021-10-01T03:27:14Z] <illiliti> yeah
[2021-10-01T03:27:17Z] <illiliti> fd is useful because you can embed it into event loop
[2021-10-01T03:29:28Z] <ryoshu> I will change that. Looking at libinput source code, it's all clobbered with evdev+udev together
[2021-10-01T03:32:16Z] <illiliti> yeah, the code is unreadable mess just like systemd source
[2021-10-01T03:32:54Z] <ryoshu> and evdev api uses /sys-related calls
[2021-10-01T03:37:23Z] <illiliti> i'll purge them when lib will be ready to use
[2021-10-01T03:37:29Z] <illiliti> for now, see how libudev-devd implemented this
[2021-10-01T03:43:04Z] <illiliti> what does devicetree_init() do btw?
[2021-10-01T03:43:53Z] <illiliti> it uses globals underhood?
[2021-10-01T07:01:27Z] <GalaxyNova> Hey!
[2021-10-01T07:06:52Z] <testuser[m]> hi
[2021-10-01T07:10:39Z] <GalaxyNova> I wonder why plan9 didn't catch on like unix did
[2021-10-01T07:10:40Z] <GalaxyNova> like
[2021-10-01T07:11:04Z] <GalaxyNova> 20 years after unix was released there were already 20 unix-like operating systems
[2021-10-01T07:11:17Z] <GalaxyNova> but now we don't see any love for plan9 :(
[2021-10-01T08:04:34Z] <aosync> there is love for plan 9
[2021-10-01T08:04:44Z] <aosync> join #cat-v to see it
[2021-10-01T08:05:39Z] <aosync> also people in the unix world are more and more aware of what is plan 9 and 9front is more active than ever
[2021-10-01T08:08:50Z] <aosync> Plan 9 has been relicensed with MIT earlier this year
[2021-10-01T17:05:41Z] <vulpine> is there a port of birch for plan9?
[2021-10-01T17:23:37Z] <testuser[m]> You mean a port of bash
[2021-10-01T17:28:44Z] <riteo> hiiii!
[2021-10-01T17:30:35Z] <testuser[m]> hiiiiiiiiiiiiiiiiiiiiii
[2021-10-01T18:16:27Z] <aosync> birch is an irc client made in bash
[2021-10-01T18:18:10Z] <akira01> hey guys
[2021-10-01T18:18:27Z] <akira01> anyone get this in kernel 5.14.9?
[2021-10-01T18:18:39Z] <akira01> https://termbin.com/yfbhu
[2021-10-01T18:31:11Z] <riteo> I mean, as long as those are warning
[2021-10-01T18:31:15Z] <riteo> s/warning/warnings/
[2021-10-01T18:31:15Z] <cotangent> <riteo> I mean, as long as those are warnings
[2021-10-01T18:31:37Z] <riteo> i don't think it matters that much, I guess they'll fix it up upstream eventually
[2021-10-01T18:32:03Z] <akira01> Yeah maybe
[2021-10-01T18:32:41Z] <riteo> do you guys know any alternative to flowgorithm? The closest thing I found is raptor (it also should run programs afaict) but it's windows only (sort of) and at least it should require me mono
[2021-10-01T18:33:46Z] <riteo> the issue with most diagram builders is that they can't "run" the code they represent, I can't find anything more than RAPTOR that does that
[2021-10-01T18:37:56Z] <riteo> you know what, I don't need to actually run them, you know, school stuff. There's literally only flowgorithm and RAPTOR afaict and they're both pretty much only for windows.
[2021-10-01T18:38:14Z] <riteo> s/I don't need/I don't think I need/
[2021-10-01T18:38:14Z] <cotangent> <riteo> you know what, I don't think I need to actually run them, you know, school stuff. There's literally only flowgorithm and RAPTOR afaict and they're both pretty much only for windows.
[2021-10-01T18:38:39Z] <riteo> yeah nvm, sorry
[2021-10-01T18:40:49Z] <tleydxdy[m]> if you school ask for it, probably better to just use that. perhaps on a school computer
[2021-10-01T18:41:42Z] <tleydxdy[m]> tbh I never really find those things intuitive or helpful
[2021-10-01T18:42:02Z] <riteo> they were actually pretty chill with the fact that I use a unix-like OS
[2021-10-01T18:42:28Z] <akira01> the problem with kiss is missing packages
[2021-10-01T18:42:37Z] <riteo> they said that alternatives were fine, so thinking about it I don't think they'll really care that I can't run them
[2021-10-01T18:42:40Z] <tleydxdy[m]> yeah, perhaps some sort of visual debugger?
[2021-10-01T18:42:54Z] <riteo> akira01: nah, that isn't a big issue imo, I can package everything I need
[2021-10-01T18:42:56Z] <tleydxdy[m]> so you can write the code and have flowchart generated
[2021-10-01T18:43:06Z] <tleydxdy[m]> rather than the other way around
[2021-10-01T18:43:26Z] <riteo> that would be interesting, but would be weird to explain to my teachers lmao
[2021-10-01T18:43:28Z] <akira01> riteo: i mean yeah you can do a normal setup
[2021-10-01T18:43:52Z] <riteo> idk, I'll talk with them ig
[2021-10-01T18:43:53Z] <akira01> but is missing some packages for a develop setup
[2021-10-01T18:44:09Z] <riteo> oh wait I thought you meant installing windows, sorry
[2021-10-01T18:44:42Z] <riteo> i get what you mean, but IMO the real big missing thing is java, for which I have plans myself (although I wish dylan implemented custom download hooks)
[2021-10-01T18:45:07Z] <akira01> yeah java is a big thing
[2021-10-01T18:45:15Z] <riteo> but other than that it isn't really *that* unbearable
[2021-10-01T18:45:38Z] <akira01> we can port java, alpine and void did this
[2021-10-01T18:45:51Z] <riteo> yeah, the biggest issue rn is that kiss is download-first
[2021-10-01T18:46:06Z] <akira01> yeah
[2021-10-01T18:46:27Z] <riteo> imo custom download hooks should fix this issue, but dylan still hasn't implemented it, altough he teased this feature
[2021-10-01T18:46:43Z] <riteo> maybe he forgot or he's just naturally busier since summer ended idk
[2021-10-01T18:46:54Z] <akira01> i think he is busier
[2021-10-01T18:47:06Z] <akira01> i emailed in some past days
[2021-10-01T18:47:24Z] <akira01> but no response
[2021-10-01T18:47:34Z] <riteo> oh give it time
[2021-10-01T18:47:50Z] <riteo> he replied to me in a week or so
[2021-10-01T18:47:53Z] <akira01> is hard to port gimp when glib is missing a feature that he just drop with rm
[2021-10-01T18:48:10Z] <riteo> nothing stops you to readd it
[2021-10-01T18:48:15Z] <riteo> just fork the package
[2021-10-01T18:48:26Z] <akira01> yeah is simple that
[2021-10-01T18:48:31Z] <akira01> but i mean
[2021-10-01T18:48:53Z] <akira01> how can i port this without this big problem?
[2021-10-01T18:49:02Z] <riteo> ehhh, I'm pretty sure that gimp falls into the heavier side of software, I'm not even sure they'd accept it in community
[2021-10-01T18:49:16Z] <riteo> so I don't think it's that big of a problem, it's just... Relative?
[2021-10-01T18:49:52Z] <akira01> maybe will not accept but if i made a repo
[2021-10-01T18:50:00Z] <akira01> will need to rebuild glib
[2021-10-01T18:50:06Z] <akira01> and this is a shit
[2021-10-01T18:50:14Z] <riteo> wait, what feature did he drop exactly?
[2021-10-01T18:50:20Z] <akira01> one sec
[2021-10-01T18:51:46Z] <akira01> sorry
[2021-10-01T18:51:52Z] <riteo> no worries, take your time
[2021-10-01T18:51:56Z] <akira01> https://github.com/kisslinux/repo/blob/master/extra/gtk+3/build
[2021-10-01T18:51:58Z] <akira01> here
[2021-10-01T18:52:06Z] <akira01> actually is gtk+3
[2021-10-01T18:52:06Z] <riteo> wait, that isn't glib
[2021-10-01T18:52:09Z] <akira01> line 85
[2021-10-01T18:52:11Z] <riteo> oh now I get what you mean
[2021-10-01T18:52:14Z] <akira01> yeah lol
[2021-10-01T18:52:23Z] <riteo> no wait, I've still not clicked the link
[2021-10-01T18:52:27Z] <riteo> I referred to the sorry
[2021-10-01T18:52:32Z] <akira01> i get little confused
[2021-10-01T18:52:45Z] <akira01> but yeah
[2021-10-01T18:52:48Z] <akira01> is gtk3
[2021-10-01T18:52:49Z] <riteo> oh now I read that line
[2021-10-01T18:52:55Z] <riteo> > It has no use at all.
[2021-10-01T18:52:56Z] <riteo> lmao
[2021-10-01T18:53:04Z] <akira01> missing gtk-encode
[2021-10-01T18:53:12Z] <akira01> yeah is just bullshit thing
[2021-10-01T18:53:20Z] <riteo> who knows, maybe it's an old thing
[2021-10-01T18:53:21Z] <akira01> but gimp need this for build
[2021-10-01T18:53:24Z] <akira01> gosh
[2021-10-01T18:53:36Z] <akira01> i mean the upstream need this
[2021-10-01T18:53:42Z] <akira01> not tested with stable
[2021-10-01T18:53:50Z] <riteo> well that line is more than a year old
[2021-10-01T18:54:13Z] <riteo> it might easily get removed if it gives actual problems, kiss changed *a lot*
[2021-10-01T18:54:24Z] <akira01> is this a little problem in kiss
[2021-10-01T18:54:37Z] <akira01> is not well universal packages
[2021-10-01T18:55:24Z] <akira01> and if dylan says no, we need to rebuild the package
[2021-10-01T18:55:25Z] <akira01> lol
[2021-10-01T18:55:31Z] <riteo> nah, it's complicated
[2021-10-01T18:55:50Z] <riteo> again, gimp/gtk+3 is on the heavier side, let's remember that fribidi has been purged from the main packages
[2021-10-01T18:56:07Z] <riteo> it's not an absolute thing, stuff changes while trying to balance simplicity and praticality
[2021-10-01T18:56:24Z] <riteo> we're already on the simpler and less pratical side than usual, that's prone to happening
[2021-10-01T18:56:28Z] <riteo> s/happening/happen/
[2021-10-01T18:56:28Z] <cotangent> <riteo> we're already on the simpler and less pratical side than usual, that's prone to happen
[2021-10-01T18:57:13Z] <akira01> i get
[2021-10-01T18:57:30Z] <akira01> but later or not kiss will need to port the bloat thing
[2021-10-01T18:58:54Z] <riteo> well the point is not to do that
[2021-10-01T18:59:13Z] <riteo> just to have a simple base (hell, even just core) which to extend freely
[2021-10-01T18:59:38Z] <riteo> you can, and if you need *should*, port bloat, just not in the main repos
[2021-10-01T19:00:07Z] <riteo> maybe not even community, to avoid the eudev thing
[2021-10-01T19:01:38Z] <riteo> anyways I gtg rn, cya later!
[2021-10-01T20:30:04Z] <riteo> hii! I'm back!
[2021-10-01T20:35:01Z] <ryoshu_> hi
[2021-10-01T20:43:14Z] <aosync> hi
[2021-10-01T21:43:24Z] <riteo> welp, I'm messing up with my laptop for now, cya later!
[2021-10-01T23:34:34Z] <ryoshu> hi illiliti
[2021-10-01T23:35:00Z] <illiliti> hi
[2021-10-01T23:35:47Z] <ryoshu> _init() initializes globals
[2021-10-01T23:36:40Z] <illiliti> hmm
[2021-10-01T23:37:25Z] <illiliti> not sure if it's suitable for libraries
[2021-10-01T23:39:44Z] <ryoshu> I was thinking about it and I prefer to have one thread reading drvctl(4)
[2021-10-01T23:39:53Z] <ryoshu> and distribute events to N readers
[2021-10-01T23:40:24Z] <ryoshu> OK. I'm going to try to finish something usable this weekend.
<!DOCTYPE html><html><head><meta charset="utf-8" /><meta name="viewport" content="width=device-width, initial-scale=1.0"><link rel="canonical" href="gemini://gemini.ctrl-c.club/~phoebos/logs/kisslinux-2021-10-01.txt" /><title>gemini://gemini.ctrl-c.club/~phoebos/logs/kisslinux-2021-10-01.txt</title><style>.c{max-width:80em;margin-left:auto;margin-right:auto;}.l{margin:0;color:lightgray;}.m{margin-top:0;margin-bottom:0;}.b{display:list-item;list-style-type:disc;list-style-position:inside;}</style></head><body><p class="l">-- Leo's gemini proxy</p><p class="l">-- Connecting to gemini.ctrl-c.club:1965...</p><p class="l">-- Connected</p><p class="l">-- Sending request</p><p class="l">-- Meta line: 20 text/plain; charset=utf-8</p><p class="l">-- Response ended</p><p class="l">-- Page fetched on Sun Jun  2 10:19:09 2024</p></body></html>