gchristensen changed the topic of #nixos-chat to: NixOS but much less topical || https://logs.nix.samueldr.com/nixos-chat
<drakonis> https://rocket.chat/ now this one's something i'd like to have an official nixos instance
<ashkitten> drakonis: how is that better than matrix?
<drakonis> its self hosted foss slack
<ashkitten> so's matrix. or at least it's getting there
<drakonis> it has the security
<ashkitten> plus matrix federates
<drakonis> it does too
<drakonis> aint that the coolest
<drakonis> i think matrix's thunder was stolen
<drakonis> huh it has an irc bridge
<drakonis> neat
<drakonis> the most surprising thing is that it was developed in brazil
<ashkitten> drakonis: ah, cool
<ashkitten> i think matrix is more focused on the federation, single room, and e2ee aspects
<ashkitten> plus p2p in development
<drakonis> it has e2ee
<drakonis> it isnt mutually exclusive
<drakonis> its interesting tho
<ashkitten> drakonis: didn't say it didn't have that
<ashkitten> just meant it's matrix's focus
<ashkitten> whereas rocket.chat seems more focused on replicating the slack experience
<ashkitten> which is also fair
supersandro2000 has quit [Disconnected by services]
supersandro2000 has joined #nixos-chat
taktoa[c] has quit [Ping timeout: 260 seconds]
manveru has quit [Ping timeout: 260 seconds]
jackdk has quit [Ping timeout: 240 seconds]
jackdk has joined #nixos-chat
taktoa[c] has joined #nixos-chat
manveru has joined #nixos-chat
<colemickens> ,locate bin mkdir
<{^_^}> Found in packages: toybox, busybox, coreutils, klibcShrunk, coreutils-full
vika_nezrimaya has joined #nixos-chat
vika_nezrimaya has quit [Remote host closed the connection]
vika_nezrimaya has joined #nixos-chat
<samueldr> been playing a bit with execline, any tip to help understand what is happening?
<samueldr> when something is failing with one of its provided binaries the failure mode is just to print the usage
<samueldr> I'm thinking maybe there would be some way to trace the execution?
<samueldr> found out my current problem... `prog...` isn't optional
vika_nezrimaya has quit [Remote host closed the connection]
cjpbirkbeck has quit [Quit: Goodbye, take care]
kalbasit has joined #nixos-chat
<samueldr> hmm... `nix-build -E '{}'`
waleee-cl has quit [Quit: Connection closed for inactivity]
<energizer> does `dd` take longer in the size of the image or the size of the destination disk?
<energizer> im dding nixos onto a big sd card and it's taking forever
<energizer> (then again my computer is busy)
cole-h has quit [Ping timeout: 240 seconds]
<etu> energizer: If the destination is bigger doesn't matter, if it's smaller you will run out of space and it will fail
<etu> energizer: Have you specified blocksize? Also do you run it with the progress output?
<etu> energizer: Example, you can add these two as arguments: bs=8M status=progress
<energizer> etu: oo i didnt know about status=progress
<energizer> hmm it says `2840875008 bytes (2.8 GB, 2.6 GiB) copied, 108 s, 26.3 MB/s`, which is the file size, but it didn't finish
<energizer> it's just stuck
<energizer> this is how you get those progress bars that wait at 100%
<energizer> ok, eventually finished
<ldlework> drakonis: ^
<ldlework> i implemented circle packing lol
<etu> energizer: It's probably syncing then
<etu> energizer: Like, the copy of the file is done, but it's still buffered so not actually fully written to the device
<ldlework> Taneb ^
<etu> One can always run the command "sync" to make sure to sync a dd write, I wouldn't be surprised if sync finished exactly at the same time as dd (dd was waiting for sync to be done) or way after dd (dd wasn't waiting for the sync to complete)
<samueldr> oflag=direct,sync # is what I usually use
supersandro2000 has quit [Quit: The Lounge - https://thelounge.chat]
supersandro2000 has joined #nixos-chat
<etu> samueldr: I never remember how to type that out without looking at the manpage and just run sync in a second shell :p
<samueldr> oflag=[tab][tab]
<samueldr> o for output
supersandro2000 has quit [Disconnected by services]
supersandro2000 has joined #nixos-chat
<colemickens> Do you think GTK4 would get more adoption if it supported Android?
<colemickens> I keep reading more and more reviews of Flutter and have my own "Great Idea for a Mobile App" that I'd actually invest time into... but Flutter and GTK+ are the only toolkits that stand out to me and one of them is basically abanonware-walking for all we know
neeasade has joined #nixos-chat
<eyJhb> Having stuff that generates 3 GB output "log" files, and having znapzend take backups every 5 minutes does not go hand-in-hand
<philipp[m]> Can you pipe it into journald and have it logged in binary form?
cole-h has joined #nixos-chat
<tilpner> You can tell an upgrade is going well if it involves studying nixpkgs, nix primops, and rw-remounting the nix store
<sphalerite> eyJhb: is this displaylink again?
ma27[m] has joined #nixos-chat
<sphalerite> welcome ma27[m]!
<jD91mZM2> I'm having such a hard time trying to make my config do anything and everything lol. I'm trying to generalise it by splitting it into modules so I can use it for more machines, but not only is it a slow and painful process, it also complicates the way to set up a new machine. I really can't decide what the best way to do it lol
<jD91mZM2> btw that double-lol is just me trying to mask my pain :)
<tilpner> Well, I coerced it into passing activation, but this is my only try at getting the new initrd-ssh to work
<tilpner> So if I don't come back, that's what happened
tilpner has quit [Quit: tilpner]
tilpner has joined #nixos-chat
<tilpner> \o/
cjpbirkbeck has joined #nixos-chat
tilpner has quit [Quit: tilpner]
tilpner has joined #nixos-chat
waleee-cl has joined #nixos-chat
<philipp[m]> Congrats!
<philipp[m]> Also not really looking forward to that part... but I'll just wait for my server upgrade anyway until my murmur module patch is merged. https://github.com/NixOS/nixpkgs/pull/102015
<{^_^}> #102015 (by pstn, 6 hours ago, open): nixos/murmur: add murmur group, don't run as nogroup
<eyJhb> sphalerite: No no, this is Omnet++, it fucking sucks
<eyJhb> Aww murmur
<eyJhb> I haven't heard that in a long time
<eyJhb> I really should have a scratch dir, that I backup on its own, that I can just nuke
<tilpner> philipp[m]: I saw your PR, helped me diagnose why nginx failed to start up, but I ended up just disabling mumble
<philipp[m]> Not an option for me. The murmur is one of the most used services on my server.
<philipp[m]> Also I'm afraid people will start using discord, as soon as the mumble quality of service declines and then I have to mess with discord.
<eyJhb> philipp[m]: What is not to love about Discord with the big bloated UI, CPU hugging, beast?
<philipp[m]> And the nice centralised infrastructure financed by venture capital!
<eyJhb> Yes!
<eyJhb> But at least the mute/deafen the music bots!
<eyJhb> :D
<eyJhb> Do your murmur have music bot? ;)
cbarrett has quit [Read error: Connection reset by peer]
sudocurse has quit [Read error: Connection reset by peer]
cbarrett has joined #nixos-chat
sudocurse has joined #nixos-chat
<philipp[m]> Only when I want it to.
<philipp[m]> So basically never.
<philipp[m]> tilpner: Setting up your sshd in initrd was straightforward though? No problems?
<tilpner> No, there were a bunch of problems
<philipp[m]> Oh dear...
<tilpner> It did work first try, but I would suggest waiting as long as you can before upgrading, in the hope that any outstanding fixes land in time
<philipp[m]> Hahaha!
<tilpner> (And it had to work first try, because getting a second try can be very time consuming for headless servers)
<eyJhb> sphalerite: But I am close to getting a buddy of mine onto NixOS!
<eyJhb> But he... He does use DisplayLink as well...
<tilpner> philipp[m]: Specifically, I hit #101462 #93694 #98100
<{^_^}> https://github.com/NixOS/nixpkgs/issues/101462 (by wizeman, 6 days ago, closed): 20.03 -> 20.09 regression: unable to deploy new (20.09) configuration due to initrd secrets of previous (20.03) configuration
<{^_^}> https://github.com/NixOS/nixpkgs/issues/93694 (by colemickens, 14 weeks ago, open): A single bad generation prevents systemd-boot-builder.py from building later generations
<{^_^}> https://github.com/NixOS/nixpkgs/issues/98100 (by mweinelt, 6 weeks ago, open): boot.initrd.network.ssh.hostKeys expects hostkey on target machine
rajivr has quit [Quit: Connection closed for inactivity]
<tilpner> philipp[m]: Your PR was just merged. Needs backport, or are you on unstable?
<sphalerite> tilpner: I'm backporting it right now :)
endformationage has joined #nixos-chat
<tilpner> <3 sphalerite
<{^_^}> sphalerite's karma got increased to 114
<philipp[m]> tilpner: I and at least two other people I know need it backported.
vika_nezrimaya has joined #nixos-chat
<philipp[m]> The bugs all don't seem to affect me in my setup.
neeasade has quit []
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-chat
vesper11 has quit [Ping timeout: 240 seconds]
<energizer> `rsync -a --remove-source-files src-nvme-usb3.0/ dest-nvme-usb3.0/` reports 40MB/s. nvme write speed is supposedly 2GB/s, usb 3.0 transfer speed is supposedly 5Gbit/s(=625MB/s). none of my cpus are pegged. any guesses on the bottleneck?
<gchristensen> this is real hardware?
<energizer> yes
<gchristensen> nvme is just a protocol
<gchristensen> I have an nvme device reading at a solid 8MiB/s
<energizer> maybe there's better words for it then; i'm talking about M.2 SSDs "M.2 PCIe Gen3 x 4 Interface. Built to the PCIe 3.1 specification / NVMe 1.3 Compliant."
<gchristensen> are you using usb 3.0 capable cables?
<energizer> yep
<energizer> (good question)
<cransom> the transactions per second, are they super high? is it for some reason transferring extremely small blocks?
<cransom> the drive itself could also be using super slow chips.
<cole-h> Maybe iotop will be useful in this case?
<tilpner> Could use fio to narrow down if it's rsync-related (fio might be way too flexible to get confident best results, but it might be feasible to get better-than-rsync results)
neeasade has joined #nixos-chat
<cransom> iostat 1 would be illuminating too.
<energizer> just switched the drives to another computer, now running at 300MB/s
<samueldr> the more I'm playing with execline, the more clumsy I find the execution
<samueldr> the concept is quite nice
<samueldr> doing error checking with it is clumsy at best
<samueldr> and unless I'm terrible at reading docs, there is no way to do the equivalent of `set -e`
<samueldr> so any commands you run in succession has to be checked for errors manually?
<eyJhb> Does Nix have a Raspberry Pi compute cluser?
<eyJhb> cluster*
<energizer> that would be nice, and shouldnt be impossible. piwheels built most of pypi on 20 raspis.
<energizer> and iirc needs ~5 to keep up
<samueldr> energizer: no
<samueldr> oops
<samueldr> eyJhb: no
<samueldr> too lazy to write two letters before tab-completing :)
<samueldr> but, which raspberry pi vintage are we talking about?
<samueldr> since for aarch64 there's much better than raspberry pi [3, 4] that's already being used
<samueldr> and armv7l/armv6l is problematic at such a smaller scale, there are better solutions that can be used, but still require setup and more work
<samueldr> for armv6l/armv7l the main issue with the pi is storage and ram
<samueldr> (if we can abstract away the cpu speed as just requiring more time to build)
endformationage has quit [Quit: WeeChat 2.9]
<eyJhb> Just had someone offer to a lot of Raspberry Pi's apparantly
<eyJhb> RPi4, 4 GB
endformationage has joined #nixos-chat
<energizer> i normally use /boot /root partitions with a bunch of subvolumes under root. if i want to do that on a raspi, i'd need to boot the nixos.org aarch64 image from one sd card, build my system and write my layout onto a different sd card. but there's only one sd card slot. how does this work?
<samueldr> you can use a usb adapter to install onto
<samueldr> then when you boot into *that* system you swap the cards around
<energizer> if it can boot from usb, why can't i just put the nixos.org image on the usb in the first place?
<energizer> so i wouldnt need to swap them
<energizer> raspi4
<samueldr> energizer: I might have not explained it right
<samueldr> but assuming you don't want to boot from usb, but you can
<samueldr> you would (1) boot the nixos.org provided image from SD, install over USB, powerdown and (2) unplug usb, unplug SD card, put the SD card that was previously used via USB in the sd slot and then boot from it
<samueldr> when `nixos-install` works, or more generally, when the Linux kernel uses a block device, it doesn't matter whether it's USB or via SD
<energizer> oh
<samueldr> it's when the device boots that it matters
<energizer> i see
<samueldr> but yes, the raspberry pi 4 *also* can boot from USB
<energizer> i need a usb sd card writer
<samueldr> (and the 3 family with some caveats)
<samueldr> energizer: alternatively you could install to a usb drive, and `dd` from that usb drive onto an sd card
<samueldr> treating the usb drive as a dumb intermediary
<energizer> got it. thanks
vesper11 has joined #nixos-chat
vesper has joined #nixos-chat
vesper11 has quit [Ping timeout: 240 seconds]
<sphalerite> eyJhb: I'll take them.
<sphalerite> samueldr | any commands you run in succession has to be checked for errors manually?
<sphalerite> *flashbacks to C*
<samueldr> AFAICT yes
<samueldr> I mean, I have under a few hours of "experience", which is mostly trying to understand the way-too-terse manuals without any examples
<samueldr> but it looks like you have to use `if` to exit; which will in turn exit unhelpfully with the error code
<samueldr> `ifelse` to print something helpful
<samueldr> ifelse { test -e /bin/sh } { foreground { echo "/bin/sh exists in the sandbox... aborting!" } exit 1 }
<samueldr> though, what annoys me maybe the most: no "tracing" à la `set -x`
<gchristensen> not the horrible manual? :P
<samueldr> perfect manual when you already know execline
<gchristensen> lol
<samueldr> so if you don't print helpful errors, you just don't really know where it failed
<samueldr> not sure if I'll keep on using execline for my experiments
<samueldr> for now it's still a yes, but it might be only to get to something better
<samueldr> I really want to like it though, maybe it needs a fork with more features
<gchristensen> I think I'd rather dive in to oil
<gchristensen> personally
<worldofpeace> samueldr: thanks for sharing, I was also considering execline, and it does look to be nicer, but no "tracing" sounds incredibly annoying
<samueldr> though I don't oil
<samueldr> I really want to move out of "fiddly scripting" land and into something that has strong... I can't find the right word...
<samueldr> execline feels functional
<samueldr> (though it's not I think)
<samueldr> I really don't care for anything sh-like anymore
<samueldr> and ideally, for my experiments, I want something that is somewhat composable
neeasade has quit [Remote host closed the connection]
<supersandro2000> Looks like shell. Why not use set -e?
<samueldr> [...]
<samueldr> execline is not shell at all, though the site really fails at showing off what it _is_
<samueldr> the sunset rapidly coming up earlier and earlier every day is really getting on my cat's mood
<samueldr> I assume that's why she's been angry I'm not giving the food yet, even though it's not the time yet
<worldofpeace> gchristensen: u just gave me the image of u diving into a vat of literal oil
<samueldr> semantics is the word I wanted earlier
<samueldr> one thing I quite like from execline (but get bit by) is how environment variables aren't available automatically in the scope
<worldofpeace> samueldr: I had the same issue with mine in the past. she'd give me these judgey eyes and violently massage me 😸
<samueldr> mine screams
<worldofpeace> oh darn.
<samueldr> and I'm assuming it's sun related because it's been happening earlier and earlier
<worldofpeace> samueldr: there's like a global scope still, right?
<V> violent massaging...
<samueldr> worldofpeace: yes
<samueldr> worldofpeace: but variables are not mixed up with environment variables in the same scope
<worldofpeace> V: and persistent caressing when I try to sleep in 😀
<V> aww
<worldofpeace> samueldr: that's for sure nicer than the bash situation
<samueldr> and the environment is not cleared (unless you do it), so it's not causing issues with newly launched programes
<samueldr> programs*
<samueldr> so I don't need to importas PATH PATH for childs to know about PATH
<samueldr> there is a clear distinction between variables and environment
<samueldr> though really, not being verbose is probably its fatal flaw :/
<samueldr> taking a peek at oil, oil would be good if I still had the desire to write shell
<abathur> "the desire to write shell" feels like one of those, uh, things
<abathur> a paradox
<abathur> that
<abathur> :)
<samueldr> yeah
<abathur> I *like* shell in a weird way, but I'm not sure I've ever had the desire to write it :)
<gchristensen> I don't want any shell scripts from somebody who wants to write it
<samueldr> similar feelings here, though "I once liked shell" is how I would phrase it since somewhen this year
<samueldr> I don't know, I would rather have shell scripts from someone that embraces is than someone that has no desire to learn it
<samueldr> embraces it*
<gchristensen> okay fair I want that person to not write shell b/c they have learned it well enough to not want to
<samueldr> ugh, is, it, one letter apart, how more confusing can it be to type?
<abathur> right
<samueldr> yeah, though this year I've been shown things that showed me that things I thought I knew were wrong, and is just terrible and now I'm really up for excising shell from my life :)
<abathur> I'll take credit for this until proven otherwise :D
<samueldr> that is just plain gross
<abathur> publish a bash book, get a blurb: "I'll never write shell again." --samueldr
<samueldr> "If you bought this book, sorry" — samueldr
<abathur> yeah, that conditional bit about set -e is a gotcha
<abathur> that's part of why I'm not actually a big fan of "bash safemode"
<samueldr> so there's no way to abort on command failures in functions AFAICT
<abathur> it still isn't safe; it's still hard to reason about; it protects you from some things but not from others
<abathur> I don't think it's the function doing it, if I read it right
<samueldr> and in fact that's the second big fail for execline in my book
<abathur> it's just that you're putting it in a conditional structure
<abathur> fn && blah, and set -e doesn't exit on failures in a conditional
<abathur> *I think
<samueldr> yeah
<samueldr> yes
<samueldr> that's worse in fact
<samueldr> because *contextually* your function can continue running accidentally
* abathur prefixes and postfixes all bash knowledge with *I think
<abathur> right
rajivr has joined #nixos-chat
<abathur> shellcheck is good, I'm on the fence about "safemode"
<abathur> which is a frustrating position to take, I generally just keep my nose out of the "ALL MY SCRIPTS BEGIN WITH SAFEMODE" parts of HN "how to shell gud" threads
<abathur> because there;s not much positive advice to give
<abathur> and for a lot of people safemode is probably still more-sane? but it's hard to know; it still has a weird squishy logic that I find simultaneously fun and frightening :)
<samueldr> yeah, it's cromulent for "shell as a list of commands"
<samueldr> for "shell as a programming language", it won't help
<abathur> I've been saying safe and I meant strict
<abathur> yeah
<abathur> you did a good job of expressing it I think, the bit about someone who embraces it
<abathur> it's not so much about thinking it's amazing
<abathur> but it *is* about not thinking understanding shell's quirks is beneath you
<samueldr> I had some hopes for execline when I finally got how it worked, but after using it... not sure
<samueldr> unless you're one of those developers that don't care about error messages
<samueldr> in that case, it's quite nice
<abathur> I haven't tried it
<abathur> though I did think when you mentioned it that I'd never heard of it
<samueldr> I like its principle of operation
<abathur> but when I googled it, I did see that I'd already visited the link
<samueldr> basically the concept is all of the tools end in "execve(rest of args)"
<samueldr> and some tools will have "execve(some of the args)" at some points (e.g. branches and loops)
<samueldr> so an execline "script" is just a big huge argv array
<samueldr> (with some parsing to strip comments and some rules about quoting)
<samueldr> so if you look at execline, it's missing a bunch of things!
<samueldr> that's because it will rely on posixish commands like `test` being available
<samueldr> (or any other)
<abathur> nod
<samueldr> the elegance of these semantics is neat, but it sorely lacks in ways to handle errors that are ergonomic for the developer
<samueldr> oh, and since it all just execs, you could e.g. call `unexport PATH some-tool` and it works without going into more in-depth execline
<samueldr> many of the utilities can be useful standalone
<abathur> I guess the utility is constraint?
<samueldr> hm?
<samueldr> the utility of execline [scripts] or unexport?
<samueldr> for execline, I would say strong semantics are helpful
<abathur> of execline scripts I guess; execline itself
<samueldr> and the way it ends up execing into the next tool in the "chain" of commands
<abathur> but I suppose I'm just wondering what it's big advantage over <write in any normal langage and exec other programs> vs <write execline> is, and I'm imagining that as being ~shell-like brevity/semantics, but with less magic?
<gchristensen> iirc the limit of execline is the limit of argv
<samueldr> maybe different magics
<abathur> ah
<abathur> so trading interactive-oriented magic
<abathur> for script-oriented magic?
<samueldr> maybe
<samueldr> I don't have *that* much experience with it yhet
<samueldr> yet*
<samueldr> I think the only magic really, other than the method of operation (using execve to treat the whole script as a kind of tape that advances one execve after the other with leftover varargs passed through)
<gchristensen> one problem I have with execline and oil is how many wildly niche tools can I bear to use
<gchristensen> especially when those tools have microscopic numbers of contributors
<abathur> nod
<samueldr> yeah, I'm thinking execline usage for me will only serve as a way to get something "better" [opinions may vary]
<samueldr> but the way it works I'm internalizing as a method for future tools
<samueldr> in fact I want to do it for bootlogd https://github.com/mobile-nixos/bootlogd/issues/3
<{^_^}> mobile-nixos/bootlogd#3 (by samueldr, 1 week ago, open): Fork and exec into true init
<abathur> I think Oil's got promise, but shells are a long game
<gchristensen> same
<samueldr> the context for my execline use as of now has been to play with "going from derivation to something useful without writing shell scripts"
<abathur> something I find interesting about Oil is I guess the promise of the moment, and combination of Nix
<samueldr> and from derivation as in `derivation {}` with as few seed binaries as possible
<abathur> by which I mean, like, I've got this premonition that Nix could be a really big lever for strapping oil to a rocket-ship by doing wild things like actually substitute it for bash
<abathur> and likewise, if Oil embraced that
<abathur> and paid some dividends back to the Nix ecosystem, whether that's performance or stability or specific features
<abathur> I just wonder if there's a weird symbiotic relationship in it I guess
<gchristensen> yeah I can also imagine that, abathur
<abathur> or more properly swap osh for bash I guess
<gchristensen> yeah
<gchristensen> which has caused me no problems so far btw
<abathur> nice
<abathur> how have you found the performance?