<clever>
gchristensen: have you ever gotten sudo to work inside a nix based docker image?
<clever>
sudo: PAM account management error: Authentication service cannot retrieve authentication info
<Shados>
Biggest zfs pet peeve remaining to me: ARC doesn't release memory fast enough for nix-daemon at its hungriest, so if I'm doing funky things that require e.g. evaluating a large nixos config twice, then I usually have to manually drop caches beforehand on smaller systems ._.
<clever>
Shados: ive run into problems where qemu can fail to allocate memory
<clever>
but if i grow slowly, it doesnt
<Shados>
yeah, it's the same problem
<Shados>
ARC isn't (yet, maybe) tightly integrated into the linux memory allocator. If it were directly hooked into the allocation path it could basically just hold the alloc request long enough to free the required memory, but it isn't. It just detects requests and starts freeing memory after they're made (assuming the requesting process is still alive).
<clever>
there is a min-free flag somewhere
<clever>
which ensures the lower bound on free ram
<Shados>
That's not a real solution though
<clever>
yeah
<Shados>
it's not even a solution to my peeve... nix-daemon being hungry can spike to multiple GB, and I don't want to waste that much cache
<Shados>
Actually, I used to have this same damn problem with java.
<Shados>
Because the JVM has pretty much identical behaviour in terms of freeing heap memory it has previously acquired, but which is now not actively in use
<Shados>
Once it gets its greedy littly paws on memory, it is very reluctant to let it go. Not at all pro-active about it.
<Shados>
*little
<clever>
ive found that if i set the max-heap too big, it makes the performance worse
<clever>
the jvm heap dips into swap, and then the GC thread starts hammering swap
<Shados>
Plus, the larger the heap, the more overhead there is to manage it
<clever>
so it needs to be big enough to hold the working set, plus overhead to GC less
<clever>
but not so big that it dips into swap
<Shados>
these days you can actually tweak the jvm's heap shrinking to be more aggressive, which is nice, but it wasn't an option when I actually needed it :P
<clever>
gchristensen: it might be due to a lack of unix_chkpwd in PATH
<manveru>
i read most of it... and i use DI sparingly, mostly useful for less flexible languages for testing
veske has quit [Ping timeout: 248 seconds]
<ldlework>
i don't know. statically typed languages have intrinsic difficulties with unit testing and late binding and the such. but it takes a flexible langauge/runtime to implement a useful DI container.
<manveru>
yeah :)
<ldlework>
manveru: i've been implementing a Unity-hacking/modding toolchain in C# and the site in ASP.NET Core which features DI prominently in its design
<ldlework>
so it's been something i've been thinking a lot about recently
<manveru>
most of my experience with DI comes from Ruby and Go, and while in Ruby you almost never use it, in Go it's actually pretty tricky to implement so it's useful without going fully type-less
<ldlework>
yeah Go is exactly what I was thinking
<ldlework>
the CLR has quite robust generics and reflection facilities and as such there are very well made and useful containers
<ldlework>
Go is like the opposite of that
<ldlework>
:D
<manveru>
indeed
<ldlework>
manveru: before this unity project i had used containers to some extent before, as I used a container in my Unity VR roguelike. i had mostly thought that it was useful so that i could write tests for my code without breaking my back. but in writing this new project i actually learned another useful quality of containers which i tried to describe in my article
<ldlework>
let's say you have a Foo which takes a Stream, and you only get these Stream instances at runtime, say Foo is a view in a website handling a form submission and the stream represents an uploaded file
<ldlework>
Well, lets say Foo also needs an IBar for whatever reason
<ldlework>
Do you register Foo in the container so you can automatically get Bars? But how do you pass the Stream you get from the framework? Do you just create the Foo manually and pass in the Stream? But now you gotta make your own Bar
<ldlework>
Well instead of just binding Foo as a concrete type in the container, you can actually bind a function type Func<Stream, Foo> such that you implement a small factory closure something like di => stream => new Foo(di.GetService<Bar>(), stream)
<ldlework>
So now, if you declare a dependency Func<Stream, Foo>, you'll be provided a function that takes a stream, and returns the Foo
<ldlework>
But you don't have to provide the Bar
<ldlework>
IE, the container gives you a factory that takes the runtime variants, and it provides what it can
<ldlework>
you work together :D
<ldlework>
but anyway this made me realize a nice gain for DI container is things like loggers and configuration
<ldlework>
if you want to practice good inversion of control, things shouldn't create their own loggers or configuration objects, or any dependency for that matter
<ldlework>
but that means you're passing loggers and configuration all over the place
<ldlework>
but now you can just declare an ILogger dependency, and register a factory for your type which recieves it's logger for free, but you can still pass in runtime variants
<ldlework>
i dunno if you're even still reading/following but that blew my fricken mind and i'm currently enjoying getting logging all over my program without having to pass it around it is glorious :D
<__monty__>
joepie91[m], ma27[m] and Moredread[m] seem to be.
<das_j>
oh, right...
* joepie91[w]
waves
<das_j>
on nixos anyone?
<joepie91[w]>
probably more than that
<joepie91[w]>
but not everybody uses the [m] suffix
<joepie91[w]>
das_j: yes. is your question how to get riot-desktop? :)
<ma27[m]>
das_j: yes
<__monty__>
Oh, I thought the suffix was enforced by the matrix-freenode bridge?
<joepie91[w]>
(the answer is - or at least was, when I last checked - to install it from the unstable channel)
<joepie91[w]>
__monty__: default, not enforced
<das_j>
no, the actual question is how well it works and how usable it is for day-to-day usage
<joepie91[w]>
aha
<joepie91[w]>
it works well, with a few caveats
<ma27[m]>
das_j: it depends on your use-case I guess. If you mainly use Matrix channels it's perfectly fine (also the freenode bridge seems usable), however some bridges may have a few issues
<joepie91[w]>
1) matrix.org is slow, a few seconds of latency is common; Riot can deal with this, but it can still be annoying at times.
<joepie91[w]>
2) the IRC bridge is a little unreliable and sometimes mis-orders messages
<ma27[m]>
for instance, I currently need to restart mautrix-whatsapp from time to time as it appears to lose the connection to my phone
<das_j>
Do they do a telegram-like history sync?
<das_j>
joepie91[w]: I'm not planning to use the bridge (yet)
<joepie91[w]>
dunno about "telegram-like", but yes, it syncs history across devices via the server
<das_j>
awesome! that's telegram-like ;)
<joepie91[w]>
there are still a few usability caveats to this for end-to-end-encrypted conversations
<das_j>
So looks like I'll have to set it up...
<joepie91[w]>
notably, cross-signing is not implemented yet, so each device pair needs to be separately verified for now
<das_j>
Would you use it as a slack replacement?
<joepie91[w]>
(which is why E2EE is not default yet)
<joepie91[w]>
das_j: yes
<das_j>
joepie91[w]: Not too bad imo
<das_j>
nice!
<joepie91[w]>
das_j: another thing is that stickers are still a little iffy to use afaik, something to do with how the integrations system works - this is not something I use personally, but I've heard some people coming from Telegram complain about it
<das_j>
Wait there are stickers?
<joepie91[w]>
yes-ish
<das_j>
oh my
<joepie91[w]>
it feels a little tacked-on at the moment, but the functionality exists :)
<das_j>
I'll have to set up a server once I finish my other thousand projects :O seems really nice
<joepie91[w]>
das_j: friend of mine uses Telegram and Matrix, just messaged them to see whether they have a moment to answer any questions :p
<das_j>
oh, nice
<joepie91[w]>
das_j: be aware that Synapse, the reference homeserver implementation, is currently a bit... high-maintenance
<das_j>
joepie91[w]: Looking at my setup, most components are high-maintenance
<joepie91[w]>
this is being worked on, and it's totally possible to run your own today, but it's not fire-and-forget
<joepie91[w]>
heh
<joepie91[w]>
das_j: I can strongly recommend joining at least the 'Synapse Admins' channel on matrix.org when you're running your own HS :)
<joepie91[w]>
there's work underway for a new reference implementation, Dendrite, written in Go instead of Python to address some of the performance issues
<joepie91[w]>
but it's not production-ready yet
<joepie91[w]>
also various other third-party HS implementations exist, in various states of production-readiness; Ruma, The Construct, etc.
<das_j>
sounds like synapse is the way to go :shrug:
<joepie91[w]>
unfortunately, for now, yes :)
<das_j>
I'm fine with that
<das_j>
I mean I use nix, looking at the code, we also have "various states of production-readiness"
<joepie91[w]>
I do like Matrix, but the current state of Synapse (and to a lesser degree, of Riot) does sit in the back of my mind as an ongoing annoyance :(
<joepie91[w]>
heh
<joepie91[w]>
fair point
<joepie91[w]>
das_j: yeah, I suppose that Matrix and Nix* are fairly similar in that respect
<joepie91[w]>
great concept, pretty solid underlying design, bunch of usability warts, and not quite there yet
<__monty__>
Heh, I like how only *one* phone's connected : )
<joepie91[w]>
lol
<andi->
samueldr: you are aware that there should be (At some point) some hotel vouchers with reasonable discounts for visitors?
<gchristensen>
looks comfortable!
<__monty__>
"Aaaaah, *which* one's ringing?!"
<joepie91[w]>
sort of like where's waldo, but with phones
<samueldr>
andi-: yes, kinda making lower/upper bounds in the budget
Jackneill has quit [Remote host closed the connection]
__monty__ has quit [Quit: leaving]
<das_j>
Is anyone running qemu with KVM in a nix sadnbox?
<das_j>
*sadbox actually
<andi->
das_j: i think everyone that runs tests or do you refer to some other use case? I've ran qemu KVM with systemd and restricted paths/devices so only qemu (with it's closure) and coreutils would be available in a dedicated network namespace.
<das_j>
andi-: So maybe the sandbox isn't the actual problem.... It currently fails when trying to run the aarch64 test on my x64 machine
<samueldr>
"with kvm", likely will not work with foreign architectures :)
Arahael has quit [Ping timeout: 258 seconds]
<das_j>
oof
<das_j>
any way to disable kvm in the test runner?
<ajs124>
das_j: I thought our other aarch64 test _do_ run? Isn't it only that one?
<das_j>
:O
<das_j>
well it didn't for a few weeks because it didn't change
<das_j>
you remember, the empty test script?
<das_j>
it's literally called "example"
<ajs124>
nvm, the other test doesn't actually do anything
<das_j>
aahh no nodes, yes
<gchristensen>
oh cool, github's emails are getting better and better for filtering
<gchristensen>
X-GitHub-Sender: Infinisil
<gchristensen>
X-GitHub-Recipient: GrahamcOfBorg
<gchristensen>
X-GitHub-Reason: mention
Arahael has joined #nixos-chat
<andi->
nice, did you discover that while fixing your fastmail migration?
<gchristensen>
yeah
<andi->
did it eventually move forward?
<gchristensen>
no, they canceled it
<gchristensen>
then I started a new one (despite the old one still saying in progress) and then a dev looked and canceled it again ... now I have one which says "Completed". they asked me to start a new one, now it says I don't have any in progress, one completed
<gchristensen>
I can see the total # of emails going up though, so I guess it is still going
<samueldr>
been a while since a column had full ticks
<andi->
remove tests until they all pass? :D
<gchristensen>
lol
<samueldr>
andi-: that's nixos :)
<samueldr>
well, my dashboard view over nixos
<andi->
i guessed so ;-)
<andi->
s3cmd has been running for ~12h trying to delete my DO spaces bucket.. The amount of progress/minute reminds me of the performance it had when first uploading the files...
<gchristensen>
fastest way to delete a bucket on S3 is to set a lifecycle rule
<andi->
let me try that on there..
<andi->
500 m(
<andi->
but the page is slow so it might have worked
<gchristensen>
oof
<andi->
listing the contents also fails.. Guess time to take a long nap and check back in the morning..
<gchristensen>
definitely a hint from the universe