rawkode has quit [Quit: Connection closed for inactivity]
__monty__ has quit [Quit: leaving]
Guanin has quit [Ping timeout: 240 seconds]
Guanin has joined #nixos-chat
averell has joined #nixos-chat
emily has quit [Remote host closed the connection]
emily has joined #nixos-chat
drakonis has quit [Read error: Connection reset by peer]
drakonis has joined #nixos-chat
ajs124 has quit [Quit: Gateway shutdown]
das_j has quit [Remote host closed the connection]
das_j has joined #nixos-chat
andi- has quit [Remote host closed the connection]
andi- has joined #nixos-chat
<Church->
pie__: See bash is great glue
<Church->
But a horrible language for actual complicated stuff
endformationage has quit [Quit: WeeChat 2.6]
<pie__>
Church-: sure
<pie__>
im surprised i bothered at all
<pie__>
i guess sometimes its still terser than python and easier than haskell
<Church->
pie__: I wrote some horrible bash earlier in Jenkins to glue together Jenkins and salt-stack
<Church->
So dang gnarly
<Church->
But it works!
<MichaelRaskin>
piu__: kind of not nice to be so unsure of which definitions are the interesting ones to even need Prolog to keep track of all the combinations
<MichaelRaskin>
oops, pie__:
<pie__>
'xD
<MichaelRaskin>
I wonder what is the most usable tiling Wayland composer based on wlroots without Sway's annoying ideas that it should be run in a very specific way.
<pie__>
man people not wanting nixpkgs to be a biig monorepo makes me :(
rardiol has quit [Ping timeout: 265 seconds]
<MichaelRaskin>
One could think people would have learnt from nixos repo re-merge
<MichaelRaskin>
(in SVN the entire trace repo worked as a monorepo in practice)
<colemickens>
Hm. What are Sway's requirements about how it's run that are prohibitive any more?
<MichaelRaskin>
it's annoying that it needs root privileges but cannot simply take a privilege-drop target, and it expects logind, and I am not sure if it will balk if I launch it with redirection from a fresh vt
<MichaelRaskin>
Trying wayland would mean enough annoyances around porting the layout from xmodmap that with sway it is probably not worth it
<yorick>
MichaelRaskin: it doesn't need root privileges
<yorick>
it needs logind or cap_sys_admin
<yorick>
and it does not balk if you launch it with redirection from a fresh vt
<MichaelRaskin>
At least something
<yorick>
it also does privilege dropping if you setuid it
<MichaelRaskin>
cap_sys_admin being not root privileges is a bit of a fiction
<yorick>
it also supports elogind
<yorick>
MichaelRaskin: the things it wants to do require that privilege, what do you expect it to do about it?
<MichaelRaskin>
I want it to behave as any reasonable daemon that requires effectively-root privileges and have an option to be launched as root with an argument for privilege-drop user?
<yorick>
MichaelRaskin: setuid it and it will privilege drop back to the user you run it as
<yorick>
like most reasonable daemons
<yorick>
having the nonprivileged user in a sway config would be weird
<MichaelRaskin>
Command line is also fine
<MichaelRaskin>
Maybe even better
<yorick>
MichaelRaskin: you want to run sudo sway --user $(whoami)?
<yorick>
I really don't see the advantage over setuid if you go that route
<MichaelRaskin>
I do not want it to drop back to my user, no thanks
<MichaelRaskin>
I run the admin-requiring stuff via a sudo-equivalent, yes
<yorick>
MichaelRaskin: I think wayland mostly expects your compositor to run as the same user as you
<MichaelRaskin>
It's that bad?
<yorick>
at the very least it will have to drop to your user for any processes it spawns (like terminals)
<yorick>
and you probably don't want your terminals to be two sudo's away from your login shell
<MichaelRaskin>
Oh right, this bullshit architecture integrates keybinding manager and OpenGL work
<yorick>
exactly
<clever>
related, the rpi has a hardware compositor
<MichaelRaskin>
Hmm. I guess I could actually bear it not being able to launch a terminal at all
<clever>
basically, you give the hardware a list of rects, with xywh, and then say if it has scaling or not, the xy to render at, and an optional wh to scale to
<clever>
and optional axis swaps or flips (90 degree rotation only)
<MichaelRaskin>
clever: what form does the actual content buffer take?
<clever>
and it will then composite all of the layers together in hardware, and render out the hdmi, composite, or dsi
<clever>
MichaelRaskin: the pixel format for reach rect is also configurable
<yorick>
clever: I think a lot of desktop GPUs do that, too
<MichaelRaskin>
But you give it pixel bufferS?
<MichaelRaskin>
Isn't it just polygon teture painting?
<clever>
MichaelRaskin: it must be a rect, not a polygon, for this part of the hardware
<clever>
MichaelRaskin: and you can specify as many as you want
<clever>
they can also have alpha channels
<clever>
so the mouse pointer could be one of these rects
<MichaelRaskin>
So this is a slightly restricted normal billboard painting, I guess
<clever>
previously, it was exposed over the dispmanx api, via firmware mailboxes
<clever>
but now the linux kernel drives it directly
<clever>
also, the final composited image, is never saved anywhere (under normal conditions)
<clever>
it generates it, one scan line at a time, and then shoves the pixels directly into a fifo
<clever>
and the hdmi phy consumes that fifo
<MichaelRaskin>
That doesn't seem unique
<clever>
i dont know how, but the dispmanx api also had a "screenshot" like mode, that could capture the entire composited output
<clever>
and there is also an "offline dispmanx" mode in the firmware, to do all composition in software (i think), which allows more complex scenes
<MichaelRaskin>
Well, you can render to screen or render to a frame buffer…
<clever>
yeah, but its not fully documented right now
<MichaelRaskin>
Maybe the kernel driver version just wants to debug the useful mode first
<clever>
i suspect the rpi foundation added the drivers to linux
<MichaelRaskin>
Well, they might lack the perfect leverage over HW manufacturer
<clever>
MichaelRaskin: from how things work, i believe the rpi foundation has signed NDA's with broadcom
<MichaelRaskin>
Well, even under NDA the documentation your get is neither complete nor precise…
<clever>
the schematics are very obviously missing large chunks of useful details
<clever>
ive had to reverse engineer things from photos and bash scripts, lol
<clever>
and the docs only cover certain parts of the chip, from the rpi1 era
<clever>
the linux source now documents some parts better then the official docs
__monty__ has joined #nixos-chat
vika_nezrimaya has joined #nixos-chat
drakonis_ has joined #nixos-chat
drakonis has quit [Ping timeout: 250 seconds]
drakonis has joined #nixos-chat
drakonis_ has quit [Ping timeout: 245 seconds]
vika_nezrimaya has quit [Ping timeout: 268 seconds]
drakonis_ has joined #nixos-chat
drakonis has quit [Ping timeout: 246 seconds]
Taneb has joined #nixos-chat
<Taneb>
I've been spending a little time trying to package Oolite (a space game) but I'm having trouble understanding their makefiles
<yorick>
Taneb: what about them?
<yorick>
Taneb: also this is way too offtopic
<Taneb>
yorick: I'm venting rather than asking for help, really
<Taneb>
Something something GNUStep and unfamiliarity
drakonis_ has quit [Ping timeout: 252 seconds]
drakonis_ has joined #nixos-chat
drakonis_ has quit [Ping timeout: 276 seconds]
drakonis_ has joined #nixos-chat
drakonis has joined #nixos-chat
drakonis_ has quit [Ping timeout: 246 seconds]
drakonis has quit [Ping timeout: 246 seconds]
drakonis has joined #nixos-chat
drakonis has quit [Ping timeout: 250 seconds]
drakonis has joined #nixos-chat
drakonis has quit [Read error: Connection reset by peer]
drakonis_ has joined #nixos-chat
rardiol has joined #nixos-chat
rardiol has quit [Ping timeout: 276 seconds]
ajs124 has joined #nixos-chat
BugeyeD has joined #nixos-chat
BugeyeD has left #nixos-chat [#nixos-chat]
drakonis has joined #nixos-chat
endformationage has joined #nixos-chat
drakonis_ has quit [Ping timeout: 245 seconds]
<infinisil>
Say I want to run a program that fetches the same resource for updates every 60 seconds
<infinisil>
But I don't want it to be exactly 60 seconds, but completely random. However it should still be 60 seconds on average over time
<infinisil>
Is there a way to have a stateless algorithm that does this?
<infinisil>
Or what's the nicest way to achieve this
<infinisil>
I feel like the answer might be to wait a poisson-distribution amount of seconds after every trigger
<__monty__>
infinisil: Depending on what you're after generating the requests on a poisson distribution could work. Random numbers on any distribution could work tbh.
<infinisil>
Hehe
<__monty__>
It sounds very poisson yeah.
<infinisil>
Hm, any random distribution?
<infinisil>
Nah that wouldn't work, take a random distribution with range 0-60, and it chooses 0 in 100% of the cases
<__monty__>
Yeah, depends on how stateless you want it to be. But a uniform distribution centered on the average you want would do for example.
<__monty__>
Well, depending on the distribution you do need to solve for the parameters.
<infinisil>
__monty__: I guess the goal is that the resulting distribution over time is uniform
<infinisil>
And not all uniform distributions for the waiting time seem to achieve this
<__monty__>
A distribution that only picks one value ever would mean it'd need to pick the average you're after every time.
<__monty__>
Ah, because you're doing a running sum?
<infinisil>
Am I? I don't think so
<__monty__>
You'd have to pick a value from the uniform distribution every clock minute. Not as soon as you sent the last message.
<__monty__>
That might literally mean the "next" request happens before the "previous."
<__monty__>
If you look at the time between requests I think you want poisson.
<infinisil>
I think a uniform distribution for the waiting time can't work: If the resulting request pattern should be uniform, there could be arbitrary large delays between subsequent triggers. This means the uniform distribution for the trigger delay has to stretch to infinity, which then certainly won't have an average of 60 seconds
<gchristensen>
tbh i'd throw this in as a systemd service and tell it it doens't need to be precisely executed at the given schedule and let systemd do it :P
<infinisil>
gchristensen: Hehe yeah, there's some option for that
<ajs124>
Why do you want this kind of distribution anyways?
<__monty__>
Yeah I think staggerings built-in to both systemd and cron?
<infinisil>
__monty__: So it really sounds like something poisson-like, though there's other distributions similar to poisson I think, it might not be exactly poisson
<infinisil>
(though I feel like it is)
<__monty__>
You should simulate this : )
<infinisil>
ajs124: Was looking at an rss fetch script that does that every 60 seconds precisely and started to wonder what the best way is to lessen the load on the server (with many people)
<__monty__>
I'm fairly certain a uniform delay of 30-90 seconds started every minute would get you what you're after. And it'd be easy to substitute a normal distribution if you want something that tends to be closer to 60.
<infinisil>
__monty__: Then long delays can't happen though
<__monty__>
Sure can, if you allow the range in the distribution.
<infinisil>
But they can't be arbitrarily long
<__monty__>
They can.
<__monty__>
It just gets exceedingly improbable.
<infinisil>
Oh, I didn't see the normal distribution part
<infinisil>
Hm, so a normal distribution centered around 60 seconds, cut off at 0 and filled up so area is 1 again
<ajs124>
(Not trying to derail all the nice math talk, just wondering if you're solving the right problem.)
<ajs124>
Why is it important that it actually executes every 60s on average, if it's just rss? Polling rss that often seems kind of weird in the first place, tbh.
<__monty__>
Yeah, longer delays are probably a better way to reduce the load.
<infinisil>
Yeah, just a thought experiment really
<infinisil>
And I mean, even with 1 hour delays, if there are 10^10 people this would be problematic too
<__monty__>
Or push.
<__monty__>
Let's throw DHTs or Blockchains at this proble!m!
<__monty__>
: )
<infinisil>
But really the idea is to be able to say "pull this often" and it does it in some automatic random uniform way
<infinisil>
No!
<gchristensen>
at 10 billion people fetching your RSS feed, the distribution almost doesn't matter :P
<ajs124>
infinisil: Blockchain is definitley the way to go here, don't fight it.
<infinisil>
gchristensen: *grabs calculator*
<infinisil>
That's 2777777 requests per second, add some load balancing and CDNs and you're good!
<__monty__>
Yes, proper multicast would probably be a better solution at that scale. One that ironically works better the less the requests are staggered : )
<infinisil>
Also, I guess just doing `wait(random(0, 60))` before the program starts would avoid all such problems too, as everybody starts at different initial times
<infinisil>
Okay so for the final solution to my original problem, I think this is how you need to generate the amount of time to wait:
<infinisil>
60*(-ln(random(0, 1)))
<infinisil>
Where 60 is whatever the average time should be
<infinisil>
Which is pretty damn simple!
<MichaelRaskin>
What do you want to achieve, and over what timespan?
<infinisil>
Instead of pulling a resource every fixed 60 seconds, pull it randomly such that it's still 60 seconds on average, but as random as possible
<MichaelRaskin>
If «as random as possible» means «maximum entropy», then uniform over [0;120] is best…
<MichaelRaskin>
Of course, your preference about «average» might indeed be geometric average
<infinisil>
MichaelRaskin: With as random as possible I mean that there's no way to somewhat predict when the next pull will happen
<infinisil>
That sounds like a reasonable definition
<MichaelRaskin>
Nope, it doesn't
<MichaelRaskin>
Not in the continuous case
<infinisil>
What's the problem with it?
<MichaelRaskin>
«no way to somewhat predict»
<MichaelRaskin>
Defining the notion of a good prediction in the continuous case requires making choices!
<infinisil>
MichaelRaskin: Well, if I can predict "the next pull is going to happen in the next 10 seconds" then that's a prediction
<infinisil>
And with [0;120] that would be possible by examining past data and it turns out that no pull happened for 110 seconds
<MichaelRaskin>
This criterion doesn't really allow comparing exponential distribution and inverse-square one
<infinisil>
I don't see how that matters
<MichaelRaskin>
Well, there are many distributions where your criterion doesn't say which is best
<MichaelRaskin>
You basically say «I want each value to be possible in principle»
<infinisil>
MichaelRaskin: You mean there are other distributions that have this criteria?
<MichaelRaskin>
A lot of them
<infinisil>
Well, I'm happy with one solution then :)
<infinisil>
Alright, enough time wasted, time to watch some youtube videos
<worldofpeace>
(I'm envisioning some sort of amv videos 😃)
<gchristensen>
America's Mathiest Videos?
<infinisil>
gchristensen: usually refers to anime music video, but I'm kind of surprised how worldofpeace would know I watch anime (though not many amv's)!
<MichaelRaskin>
I can just mention that in Russia there was a joke «This is #anime? So, how do I patch KDE2 to build it under FreeBSD»
<gchristensen>
ah yes it is the most wonderful time of the year -- the deadline for signing up (or changing health insurance coverage plans) is arriving, and the website to do so is broken
<gchristensen>
so seasonal!
tilpner has quit [Remote host closed the connection]
<infinisil>
MichaelRaskin: Hehe yes, heard of that
tilpner has joined #nixos-chat
<infinisil>
For videos, I've recently been addicted to SixtySymbols and DeepSkyVideos
rardiol has joined #nixos-chat
<gchristensen>
do we have any places which might be a natural hook for running `desktop-file-validate` on a package's .desktop files?
ajs124 has quit [Quit: Gateway shutdown]
<infinisil>
gchristensen: In makeDesktopitem?
ajs124 has joined #nixos-chat
<gchristensen>
oh man I meant for this to be in -dev :)
<worldofpeace>
infinisil: I think it's a fact I picked up. but also found it humorous slightly if you were like watching some seasonal amv or ha, perfect blue.
<worldofpeace>
gchristensen: nope
<worldofpeace>
typically projects can handle that as like meson check to run.