<genevino>
joepie91: wow, that sounds like a serious pulse bug to me, but still, you should be able to solve those recoding issues.
<genevino>
well at least i guess that's what's going on here.
<genevino>
sounds to me like some general "yea the device can do 48 so let's use that and resample trolololololololo" issue
<genevino>
joepie91: still, 1) you want to get some device that sounds proper and 2) i think it's likely that your problem can be solved with 100% pulse or at least 3) JACK
<joepie91>
genevino: what do you mean with "some device that sounds proper"?
<genevino>
the usual onboard devices usually sound terrible, but still, if you really wanted to, it should be able to solve that specific pulseaudio issue you have, and i admit that's getting hacky and weird and rusty and dirty
<genevino>
joepie91: anything with decent D/A converters
<joepie91>
genevino: the on-board chip worked fine previously and is fine audio-quality-wise, this is one of the more expensive on-board chips actually
<genevino>
joepie91: whatever your fancy i think
<joepie91>
I have no desire to replace it :)
<genevino>
yea if it sounds fine to you and you have no desire to replace it, i won't want to force you.
<genevino>
i'm not here to force hardware on you.
<genevino>
if that's what you're cool with use that, sure thing.
<genevino>
the whole topic of audio devices is like, it just goes deeper and deeper, and i'll probably lose your beliefs at some depth.
<genevino>
i can't and i don't want to force some vendor on you.
<genevino>
audio under linux was such a pain until pulseaudio arrived, and the only problems it solves are those of consumers, not producers.
<genevino>
not gonna argue with that, i feel you.
<genevino>
still, question remains how to solve your actual pulseaudio problem, right?
supersandro2000 has quit [Disconnected by services]
supersandro2000 has joined #nixos-chat
<genevino>
i'm in the very lucky position to own 2 devices that are entirely discontinued on any other platform but work JUST FINE with nixos.
abathur has joined #nixos-chat
LnL has quit [Ping timeout: 264 seconds]
LnL has joined #nixos-chat
LnL has joined #nixos-chat
<ashkitten>
hm, jellyfin 10.6.4 has some issues with syncplay
<ashkitten>
i hope those are resolved when 10.7 releases
red[evilred] has quit [Quit: Idle timeout reached: 10800s]
<ashkitten>
i have an issue with znapzend
<ashkitten>
it's failing to delete old snapshots because it's accumulated so many that the argument list is too long
<viric>
fatal: git-write-tree: error building trees
<viric>
but "git fsck" works all fine
jdnixx-M1 has quit [Ping timeout: 260 seconds]
emily has quit [Ping timeout: 260 seconds]
leons has quit [Ping timeout: 260 seconds]
emily has joined #nixos-chat
jdnixx-M1 has joined #nixos-chat
leons has joined #nixos-chat
<pie_>
,locate zdb
<{^_^}>
Found in packages: zfs, libzdb, zfsUnstable
<pie_>
wat. then why isnt it in my path
<sphalerite>
pie_: huh, it is in mine
<pie_>
oh none of the zfs tools are in the path there we go lol
<pie_>
oh my god
<pie_>
out of three systems i used the wrong shell twice and it just hit me
<pie_>
im like, wait this system doesnt even have zfs
<pie_>
...what...
<pie_>
my system, an ssh, and a nested ssh
<pie_>
i think not even color coded tmuxes might save me
<sphalerite>
colour-coded shell prompts?
<sphalerite>
Hostnames with ansi escape codes in them?? :D
<pie_>
no the problem here was kind of not even paying attention or something
LnL has quit [Ping timeout: 264 seconds]
<sphalerite>
hexa-: re NAS upgrade, what are your criteria? I bought a generic ITX NAS case made by supermicro recently and it's very nice. Still waiting for the ITX board (honeycomb lx2k) to arrive, but in the meantime I've been using it with my nanopi, and it works very nicely
<sphalerite>
ashkitten: ooooh, I had that problem a while back and deleted snapshots manually… oracle mode would have been a lot easier x)
<ashkitten>
heh, yeah. seems like it's a common issue.
<ashkitten>
i feel like it should automatically do that if the arglist is too long...
<hexa->
sphalerite: low power, remote management, capable of doing rebuilds by itself, SFP+ or 10GbaseT
<sphalerite>
hexa-: that sounds more like pro than prosumer to me :p
<hexa->
*cough* :D
<sphalerite>
hexa-: I'm guessing it needs to be 19" rackmount as well?? :D
<hexa->
no :D
<hexa->
I don't actually have a rack at home :)
<sphalerite>
not even lack? :o
<hexa->
see, prosumer! :D
<hexa->
lack is disgusting :p
<hexa->
the feet are hollow
<sphalerite>
that's what dübel are for :p
<sphalerite>
(can't remember the english word)
<hexa->
me neither :)
__monty__ has joined #nixos-chat
<pie_>
._. i need a NAS
<viric>
I'm moving lots of files these days, from git annex to plain btrfs
<viric>
snapshots saved me from data loss 3 or 4 times during that 'move'
<viric>
and reflinks made things fast
<pie_>
btw you know git annex has an irc channel? might be good to report issues <viric> mpf. git problem... error: invalid object 100644 ab06ddd5cb2db810e2728a66b906dc597adc1007 for 'filename'
<viric>
pie_: I found a post in their forum about that: remove index.lck
<viric>
I didn't think it was an annex problem, but git
<viric>
but I'll go there because I don't know how to do something
<hexa->
sphalerite: so I guess you don't have a good recommendation for me? :D
<pie_>
hexa-: #reddit-homelab might be an optio
<hexa->
fair
<hexa->
anyway, the closest I've found is an asrock rack x570d4u-2l2t
<hexa->
*but* there are no recent low power x570 cpus
<hexa->
and also the remote management comes with a bunch of issues
<hexa->
like they don't even have announced any 35W Vermeer models :<
<hexa->
and previously they have been OEM-only
<pie_>
either the issue is unrelated or zfs tools cant handle drives with duplicate UIDs and stuff
<pie_>
cant get zdb to recognize it either. kind of hard to redo the uids when you cant moun tthem because they are are mirrors of your root :P
<pie_>
i suppose i could spin up a vm if i can free some ram
<viric>
pie_: I was too bad managing where to put things, and every "info" or "list" command took long... deleting content was also difficult because it wants to ensure many things.
<viric>
pie_: I was using git annex with about 6 external disks
<viric>
deleting a file meant sync-ing all them or "--force"... maybe I was using annex wrong
<viric>
pie_: now I have 61GB in 'annex' objects while I have zero refs in the tree. They do not show up "unused". I have no idea what they are bout.
spacekookie_ has joined #nixos-chat
spacekookie has quit [Ping timeout: 272 seconds]
<ar>
>there are no recent low power x570 cpus
ixxie has joined #nixos-chat
<ar>
it would be nice if there was a socketable variant of the 4750U/4800U
<ar>
this thing's almost as fast as the 2700x (slightly faster in single-thread even), while just sipping power
AtnNn has quit [Ping timeout: 260 seconds]
AtnNn has joined #nixos-chat
kini has joined #nixos-chat
<sphalerite>
hexa-: sorry, had to disappear for lunch with the family
<abathur>
siraben I'm happy enough just using homebrew casks for the closed-source/auto-updating stuff. I happily fold the open-source ones into my nix config if/when derivations exist, but insisting on using Nix to install mostly precompiled closed-source gui apps that mostly want to auto-update anyways feels like swimming against the current to me
<MichaelRaskin>
You mentally included the phase of lifting the curse, I guess
<abathur>
?
<abathur>
oh, the koans
<siraben>
pie_: interesting, didn't know that Nix let you change builtins like that
<lukegb>
there are other cursed things you can override, like the semantics of the <channel> thingy as well
<pie_>
siraben: "sort of"
<lukegb>
__findFile, I think
<siraben>
lukegb: something like I did today: `nix-store -q --graph $(NIX_PATH=nixpkgs=https://github.com/OriansJ/blynn-compiler/archive/master.tar.gz nix-instantiate '<nixpkgs>' -A blynn-compiler)`
<lukegb>
siraben: right, but you can do fun things like if you have a monorepo, you can override the <> semantics to mean "a path relative to the root of the repo"
<siraben>
lukegb: how do you mean?
<lukegb>
siraben: nix eval '(let __findFile = nixPath: a: "hello I am ${a}"; in <lukegb>)'
<lukegb>
> let __findFile = nixPath: a: "hello I am ${a}"; in <lukegb>
<{^_^}>
"hello I am lukegb"
<siraben>
WAT
<MichaelRaskin>
You can override * but not +, though
<siraben>
but wait, that's illegal
<siraben>
MichaelRaskin: yeah because + has to handle concat, according to the logs
<siraben>
string concat*
<lukegb>
<lukegb> is (effectively, iirc) rewritten to (__findFile __nixPath "lukegb")
<infinisil>
Although, maybe let's go to #bottest or #nix-lang to spam the bot
omnd has joined #nixos-chat
lunc has quit [Ping timeout: 260 seconds]
omnd is now known as lunc
<siraben>
nix has units???
<__monty__>
No.
supersandro2000 has quit [Ping timeout: 260 seconds]
supersandro2000 has joined #nixos-chat
<supersandro2000>
It is unbelievable how often I freeze my linux box
<lukegb>
supersandro2000: by running nixpkgs-review? :p
<supersandro2000>
yes...
<andi->
run it less often
<supersandro2000>
I already set CPUQuota to 200% and MemoryLimit to 4GB
cole-h has joined #nixos-chat
<supersandro2000>
🤦I changed my PATH order and that is no longer applied...
sphalerite has quit [Quit: 'tis the season to be rebooting]
sphalerite has joined #nixos-chat
<supersandro2000>
I really like writing wrapper functions for such stuff in my dotfiles
<cole-h>
elvishjerricco: Have you played around with ZFS's zstd support yet? Wondering if I should switch to it (from "on") when I next reinstall (soon).
<elvishjerricco>
cole-h: I haven't. Others seem to like it though
rajivr has quit [Quit: Connection closed for inactivity]
<cole-h>
elvishjerricco: Another q: have you used ZFS on an NVMe? Any gotchas I should worry about?
<infinisil>
cole-h: Well it is straight up better in terms of compression, I don't think there's a reason not to use it
<cole-h>
infinisil: Do you use specific setting, or just `compression=zstd`?
<infinisil>
I'm just using `on`, but also not the latest version of zfs
<infinisil>
I wonder if zstd is the new `on`
<infinisil>
Looks like `on` is still lzjb/lz4
<infinisil>
cole-h: Oh but I am using zfs on an nvme, I don't think there's anything special to worry about
<cole-h>
Do you customize any options (aside from e.g. atime, compression, encryption, xattr, acltype, etc)?
<infinisil>
Nah
<cole-h>
Also elvishjerricco -- I'll finally be able to fix my mistake of not having a root dataset under the pool, and creating all my other datasets under that root (allowing incremental send / recv of encrypted stuff) :D
<cole-h>
infinisil: Not even ashift?
<infinisil>
I don't even turn off atime, I probably should
<infinisil>
cole-h: Nope
<cole-h>
Interesting.
<elvishjerricco>
infinisil: It's more likely than not that ZFS did not correctly guess your ashift
<infinisil>
How can I check?
<elvishjerricco>
infinisil: What does zpool get ashift pool say?
<cole-h>
Don't SSDs also lie a lot about their physical block size?
<infinisil>
elvishjerricco: 0
<elvishjerricco>
cole-h: Yea that's why it probably guessed wrong
<elvishjerricco>
infinisil: I think it's actually a per-vdev setting but I'm not sure how to check on one vdev
<infinisil>
Ohh, zdb -C
<infinisil>
Shows ashift: 9 for my NVMe
<elvishjerricco>
infinisil: Yea I guarantee that's wrong
<infinisil>
And this makes it slower?
<elvishjerricco>
infinisil: It's basically a read-modify-write amplification anytime ZFS tries to write a 512b block to what is probably a 4k or 8k sector
<elvishjerricco>
Which can be quite often for metadata blocks or small files
<elvishjerricco>
ZFS will start all records at the wrong alignment, which amplifies
<elvishjerricco>
infinisil: your drive is lying. I don't think there's ever been a consumer SSD that actually had physical sector size of 512b
<infinisil>
So I need to find the datasheet of my nvme?
<elvishjerricco>
Drives started to like about this because win XP would crash on non-512 disks
<elvishjerricco>
And the trend stuck for whatever reason
<infinisil>
Oh and actually that was the wrong disk, the NVMe shows 512 bytes for all numbers
<elvishjerricco>
infinisil: I've never found a reliable way to know the actual sector size but I haven't looked that hard. Ashift 13 is definitely safe but may be a bit wasteful. 12 is probably safe
<infinisil>
Well that sucks lol
<elvishjerricco>
Indeed
<elvishjerricco>
Just note that the big problem with 13 is that ZFS will ALWAYS do it's writes in 8K blocks or more. So a 1B file becomes 8K
<infinisil>
sudo flashbench -a /dev/nvme0n1 --blocksize=1024
<infinisil>
Though tbh, I'm not sure what to think of the results
<infinisil>
I guess I should probably just use ashift=12
averell has joined #nixos-chat
cirno-999 has quit [Ping timeout: 256 seconds]
<__monty__>
What happens when you use the wrong blocksize? Is it just inefficient or does it cause data loss/corruption?
<gchristensen>
inefficient
<hexa->
just inefficient
<gchristensen>
write amplification and what-not
<hexa->
faster wear-out :)
<__monty__>
So it's semi-important but also almost impossible to figure out the real size?
<hexa->
__monty__: see the flashbench remark
<hexa->
some block sizes are alot faster than others
<hexa->
which is a good indicator of the underyling block size
<hexa->
things will be slower if you have to do more lookups
<MichaelRaskin>
«An adversary is capable of launching a timing attack leading to disclosure of hidden information» Cryptography? Nah, hardware specs.
<viric>
MichaelRaskin: hey. I had a bitflip in btrfs metadata... ram, the checksum was ok
<viric>
MichaelRaskin: changing the bit with a hex editor made all work.
<viric>
I tried memtest86-efi and it caught a bitflip. Then I updated the bios, and memtest86 didn't fail anymore.
<viric>
what do you think, #nixos-chat? Would you trust that computer?
<sphalerite>
viric: how long did you leave it running?
<viric>
sphalerite: 3 runs of memtest86, all working
<viric>
the bios changelog (2017 -> 2020) had some versions with "Improved system stability"
<sphalerite>
heh
<samueldr>
trusting a computer? that's a lot to ask for
<MichaelRaskin>
It probably has a known-backdoored CPU, right?
<viric>
MichaelRaskin: rizen-3
<MichaelRaskin>
So, PSP, so, yes?
<viric>
no idea
<viric>
I don't think the bit flipped by a backdoor in this case
<MichaelRaskin>
True, that's just _another_ reason not to trust it!
<viric>
:)
<MichaelRaskin>
How quickly did you hit bitflips with the old BIOS?
<viric>
in memtest86, 1st run 2nd pass.
<viric>
out of memtest86, it hanged once a month maybe, too...
<viric>
I didn't think bios updates could be so beneficial (or original bios so broken)
<MichaelRaskin>
Passes are different patterns, right? I do not remember what memtest calls what
<viric>
it was not rowhammer
<viric>
08080808 gave 28080808
<MichaelRaskin>
Every load is a bit of a rowhammer!
<viric>
hehe
<MichaelRaskin>
The scary part is that it is not even much of a joke…
<viric>
whatever. I stay with it. I also run 'memtester' userland often without finding anything. But I didn't run that before. And I tried to downgrade the bios but they don't allow that.
<viric>
MichaelRaskin: I know I know
<viric>
btrfs has been very good so far. reflink & snapshots... so a saviour
<MichaelRaskin>
There is dropping the ball on integrity, then there is smashiong the ball into the floor from a heliocentric orbit
<viric>
and send&recv
<MichaelRaskin>
Maybe 3 runs are not enough for complete peace of mind, but I can easily believe they pushed either performance or powersaving so hard they ended up messing up the refresh even on the memtest load (which is kind of… what RAM is expected to handle easily…)
<viric>
that's my expectation too
<viric>
do you use memtester much? userspace.
<viric>
I never found a failure with it
<MichaelRaskin>
I do not
<viric>
I used rowhammer_test
<viric>
it hit the bitflip in some new computers we bought years ago, and we returned ram in warranty period. Next ram worked fine.
<MichaelRaskin>
Remember all this talk in the history class how mass manufacturing being about identical replaceable parts of consistent quality?
<viric>
I don't remember if they were the same model
<viric>
or brand
<viric>
we got 3 new computers with failing ram, and then we replaced the ram for all three and all worked
srk has quit [Remote host closed the connection]
srk has joined #nixos-chat
<sphalerite>
MichaelRaskin: didn't that myth die, at least for electronics, with binning?
<MichaelRaskin>
I do not think rnough people paid attention for the myth to die
<sphalerite>
tbf I think it's quite tricky to get stuff right with perfect consistency at the nanometre scale?
<MichaelRaskin>
Actually it's very hard at any scale, unless you have tools at a much better scale
<gchristensen>
nyquist but for consistency?
<MichaelRaskin>
Kind of Boltzmann
<MichaelRaskin>
Maxwell's daemon not being easily implementable is also related, I guess
<MichaelRaskin>
(if it is small enough to exploit some scale of fluctuations, it is also small enough to suffer of fluctuations of its own on the same scale)
<viric>
ffmpeg can send 'rtp' with udp.... what can receive that?
<viric>
for real time display of what ffmpeg sent
<MichaelRaskin>
presumably another ffmpeg instance?
<ar>
viric: gstreamer can do both ends
<ar>
though i don't have a pipeline syntax for that at hand
<viric>
hm
<viric>
something like ffplay... I've to find how to bind that.
<viric>
I hoped I could build a decent adhoc videoconference between two fixed ends with ffmpeg.
<energizer>
MichaelRaskin: is there something i can read about why the precision-manufacturing story is wrong? i'd love to learn about that
<MichaelRaskin>
I do not think it is wrong
<MichaelRaskin>
Consistency can go up usefully, and a lot, even without reaching perfection
<energizer>
MichaelRaskin: sphalerite: in that case, what is the "myth" you were mentioning above?
<MichaelRaskin>
Well, good consistency and perfect consistency no-QC-required are different things
<MichaelRaskin>
And who doesn't like to cut corners on QC!
<MichaelRaskin>
Oversimplifying good consistency to perfect consistency can easily create wrong expectations
cosimone has quit [Quit: cosimone]
<energizer>
mhmm
__monty__ has quit [Quit: leaving]
LnL has joined #nixos-chat
ixxie has quit [Quit: Lost terminal]
* colemickens
really loves this community
<colemickens>
abathur: nice :) I might have to see if it's easy to use in powerlevel10k... or really maybe I should look at your setup more, I suspect our prompt setups are similar, maybe I can forego powerlevel10k anyway.
<abathur>
:)
<abathur>
using zsh?
<colemickens>
I am
<abathur>
I'm not sure if the coproc I used for IPC is portable between them
ky0ko has joined #nixos-chat
<abathur>
or if it is trivial to make it compatible with both, or add a lilgit.zsh that uses the equivalent incantation