ChanServ changed the topic of #kisslinux to: Unnofficial KISS Linux community channel | https://kisscommunity.org | post logs or else | "An idiot admires complexity, a genius admires simplicity." -- Terry A. Davis
<ryoshu>
illiliti: I was told that we want a daemon for monitoring
<ryoshu>
as we don't want to allow multiple queues, unprivileged that make wired memory
<ryoshu>
with a daemon we get normal memory management for messages
<ryoshu>
distributed to users
<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?
<ryoshu>
user-space buffering instead of kernel-space, but it is for consideration
<ryoshu>
no problem with setting a limit on the number of users from user-land
<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.
<illiliti>
yeah, this is good decision
<illiliti>
caching is complicated
acheam has quit [Quit: connection reset by purr]
acheam has joined #kisslinux
<illiliti>
do you think it would be better to port devd or implement monitoing stuff to devpubd?
<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
<ryoshu>
I would like to switch all users of drvctl(4), including devpubd to devicetree(3)/udev(3)
<ryoshu>
devd is freebsd specific, no plans to port it
<illiliti>
sysfs, netlink and hwdb is unneeded
<ryoshu>
but would a linux-style/like <udev.h> be superior over <devicetree.h>?
<ryoshu>
going netbsd-only way is hard and prone to rejects in upstream for patches
<ryoshu>
if you can/want to write a version for other kernels, it might be easier
<ryoshu>
I don't know your future API plans
<testuser[m]>
Hi
<ryoshu>
I will try with option (2)
<illiliti>
i'll publish the lib soon. i already implemented basic stuff for linux, netbsd and libudev backends
<illiliti>
ryoshu: btw, why devicetree if we have drvctl? devicetree depends on daemon?
<ryoshu>
I just wanted to pick an internal name, no dependencies on a daemon
<ryoshu>
I think it's good to avoid a name libudev, for more proper compat lib; so no libudev linking with libudev
<ryoshu>
for the same reason I want to pick <udev.h> instead of <libudev.h>
<illiliti>
for consistency sake?
<ryoshu>
libdevicetree offering udev.h, on top of that libudev-netbsd and offering libudev.h for emulating /sys and others
<ryoshu>
for easier porting
<ryoshu>
this is my idea
<ryoshu>
dragonflybsd picked name devattr or such
<ryoshu>
libdevattr
<illiliti>
i don't like this idea. it's confusing
<ryoshu>
do you prefer to see the lib named libudev?
<illiliti>
my idea: libdevicetree offers devicetree.h and libudev-netbsd offers libudev.h. libudev-netbsd uses devicetree.h underhood
<illiliti>
libdevicetree offering udev.h is just confusing
<cotangent>
<riteo> I mean, as long as those are warnings
<riteo>
i don't think it matters that much, I guess they'll fix it up upstream eventually
<akira01>
Yeah maybe
<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
<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
<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.
<riteo>
s/I don't need/I don't think I need/
<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.
<riteo>
yeah nvm, sorry
<tleydxdy[m]>
if you school ask for it, probably better to just use that. perhaps on a school computer
soliwilos has joined #kisslinux
<tleydxdy[m]>
tbh I never really find those things intuitive or helpful
<riteo>
they were actually pretty chill with the fact that I use a unix-like OS
<akira01>
the problem with kiss is missing packages
<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
<tleydxdy[m]>
yeah, perhaps some sort of visual debugger?
<riteo>
akira01: nah, that isn't a big issue imo, I can package everything I need
<tleydxdy[m]>
so you can write the code and have flowchart generated
<tleydxdy[m]>
rather than the other way around
<riteo>
that would be interesting, but would be weird to explain to my teachers lmao
<akira01>
riteo: i mean yeah you can do a normal setup
<riteo>
idk, I'll talk with them ig
<akira01>
but is missing some packages for a develop setup
<riteo>
oh wait I thought you meant installing windows, sorry
<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)
<akira01>
yeah java is a big thing
<riteo>
but other than that it isn't really *that* unbearable
<akira01>
we can port java, alpine and void did this
<riteo>
yeah, the biggest issue rn is that kiss is download-first
<akira01>
yeah
<riteo>
imo custom download hooks should fix this issue, but dylan still hasn't implemented it, altough he teased this feature
<riteo>
maybe he forgot or he's just naturally busier since summer ended idk
<akira01>
i think he is busier
<akira01>
i emailed in some past days
<akira01>
but no response
<riteo>
oh give it time
<riteo>
he replied to me in a week or so
<akira01>
is hard to port gimp when glib is missing a feature that he just drop with rm
<riteo>
nothing stops you to readd it
<riteo>
just fork the package
<akira01>
yeah is simple that
<akira01>
but i mean
<akira01>
how can i port this without this big problem?
<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
<riteo>
so I don't think it's that big of a problem, it's just... Relative?
micro_O has quit [Ping timeout: 252 seconds]
<akira01>
maybe will not accept but if i made a repo