gchristensen changed the topic of #nixos-chat to: NixOS but much less topical || https://logs.nix.samueldr.com/nixos-chat
<bqv> ditto
<gchristensen> my nixos config history is a single commit every 6 months, each with the message "shoulda committed more"
<cole-h> I feel personally attacked
<bqv> Flakes forcing me to commit to build really helps
<emily> it doesn't force you to commit to build though?
<emily> flakes with dirty trees works fine for me
<bqv> Well, mine does
<bqv> Or more specifically it won't let me switch to a dirty build
<MichaelRaskin> 2FA: really, that's how we enforce password manager use. Flakes: really, that's how we enforce committing the configuration.
<drakonis> this conversation goes places!
<gchristensen> cole-h: the universe hasn't ended yet, so plenty of time
<cole-h> :D
parsley936 has quit [Remote host closed the connection]
<infinisil> New bot feature!
<infinisil> ,escape ${}
<{^_^}> Escape this in '' strings with: ''${}
<{^_^}> Escape this in " strings with: \${}
<andi-> ,escape ${"foo"}
<{^_^}> Escape this in '' strings with: ''${"foo"}
<{^_^}> Escape this in " strings with: \${\"foo\"}
<samueldr> ,escape
<{^_^}> samueldr: Did you mean escape"?
<{^_^}> " double quote: \" backslash: \\ bash curly bois: \${} newline: \n tab: \t "
<samueldr> ,escape  
<{^_^}> Escape this in " and '' strings with:  
<infinisil> Damn you samueldr
<infinisil> Eh whatever, that's just a minor UX imperfection :)
<infinisil> ,escape ' '' ''' ${} " \
<{^_^}> Escape this in '' strings with: ' ''' '''' ''${} " \
<{^_^}> Escape this in " strings with: ' '' ''' \${} \" \\
<samueldr> yeah, infinisil, mostly trolling with fine and cromulent space characters
<infinisil> > unicorn
<{^_^}> "🦄"
<infinisil> > escape 🦄
<{^_^}> error: syntax error, unexpected $undefined, expecting ')', at (string):310:8
<infinisil> Damnit
<infinisil> Oh
<infinisil> ,escape 🦄
<{^_^}> Escape this in " and '' strings with: 🦄
<infinisil> Never mind :)
<infinisil> But I hope this will be helpful for answering the never ending questions about how to escape things
<aanderse> infinisil: just to confirm, there is no way to mkRemovedOptionModule for submodules, right?
<infinisil> aanderse: I don't think so no
<infinisil> ,escape
<{^_^}> Usage: ,escape <text> to show how to escape the given text in Nix
<infinisil> That's better
<lukegb> ,escape ';}"''""
<{^_^}> Escape this in '' strings with: ';}"'''""
<{^_^}> Escape this in " strings with: ';}\"''\"\"
KeiraT has quit [Remote host closed the connection]
KeiraT has joined #nixos-chat
endformationage has quit [Quit: WeeChat 2.6]
slack1256 has joined #nixos-chat
drakonis has quit [Quit: WeeChat 2.8]
<evanjs> When OfBorg is sick of your commits and ignores your build 😢
<evanjs> Nah but I’m assuming there’s a wave timer or something there
<evanjs> infinisil: yeah I came across that earlier today (maybe even part of the reason you mentioned that 😝 ) but string escaping is always, well... fun 😝
<evanjs> Looking at you, groovy... 🙄
slack1256 has quit [Ping timeout: 265 seconds]
<cole-h> Which PR/
<evanjs> cole-h: *scrolls up a bit to be sure* if you meant me, then #77714
<{^_^}> https://github.com/NixOS/nixpkgs/pull/77714 (by evanjs, 17 weeks ago, open): pythonPackages.pillow: 6.2.1 -> 7.1.2
maxdevjs has quit [Ping timeout: 265 seconds]
drakonis_ has quit [Read error: Connection reset by peer]
drakonis has joined #nixos-chat
<cole-h> Sorry, was clowning around. Taking a look.
<evanjs> Lol I mean same here in that regard. Like why am I up this late
<cole-h> Borg looks happy to me
<evanjs> Nani??
<cole-h> borg lgtm
<evanjs> *moves to check view*
<evanjs> Omfg
<evanjs> Yeah I guess I was sorta expecting it to appear in the comments
<cole-h> Just gotta click "Show all checks" lol
<evanjs> Yeah idk. Tired 😪
<cole-h> lol, borg hasn't done comments for a while now
<evanjs> Ah there they are as well lol
<evanjs> Ahhhh that might be why 🙃
<evanjs> Are these changes like documented somewhere?
<evanjs> So I can track or etc idk
<cole-h> Maybe? I only joined ofborg like ~2 months ago :P
<cole-h> I just know that we decided to move to GH checks + labels as opposed to spamming comments all the time
<evanjs> Ugh I mean I _could_ look at the irc from time to time, idk, would just be nice to have a newsletter for internals or something, idkkk haha
<evanjs> Yeah that makes sense
<cole-h> Feel free to watch https://github.com/NixOS/ofborg :D
* cole-h just added "see about making a CHANGELOG for ofborg" to his ever-expanding TODO list
drakonis has quit [Read error: Connection reset by peer]
<evanjs> Yeah I guess I was hoping more selfishly hoping for a more curated thing. Like thisweekinrust but for NixOS if that makes sense. Esp their “x commits were merged this week”
<evanjs> And I can get a rundown of big things that happened. Idk just ranting at this point tbh
drakonis has joined #nixos-chat
<evanjs> cole-h++
<{^_^}> cole-h's karma got increased to 54
<cole-h> Well, most of the ofborg improvements recently have been internals
<evanjs> Thanks for pointing me to the right place lol. And right right
<cole-h> Past few weeks there's been a little bit of a focus on cleaning up the logging so we can watch it more efficiently
<evanjs> That’s typically all that’s mentioned in the thisweekinrust PRs and etc
<cole-h> (Or more likely, so *I* can watch it :P)
<evanjs> Idk maybe I just really like the digest format they have.
<cole-h> Well, it's a lot easier when you have as many people working on that as they do
<evanjs> Right for sure
<cole-h> ofborg is really just gchristensen and LnL -- and more recently have I been added to the mix
<evanjs> Definitely aware of the difference in team sizes
<evanjs> Yeah sure I was thinking of OfBorg and NixOS as a whole in a sense
<evanjs> Like I’d consider OfBorg a critical part of nix atm
<cole-h> Definitely is
<evanjs> And in my picture of a nix newsletter, if we had “recently merged PRs”, such could be sourced from nixpkgs, OfBorg, etc
<cole-h> Would certainly be interesting.
<evanjs> For sure. I do like the few things we have right now in terms of newsletters, but there’s always room for improvement.
<evanjs> And room on my todo list... but that’s partly due to my lack of prioritization 🤪
<cole-h> Hehe
<cole-h> OK, time for bed. Catch you later :^)
cole-h has quit [Quit: Goodbye]
<LnL> that's a good point, if there are interesting changes we should submit them to the newsletter
<evanjs> LnL: yeah the latest example for me lately is the nixpkgs-channels “deprecation” that emily mentioned earlier. I had no idea we aren’t really using it anymore 😬
<evanjs> And yeah same. Night guys.
<LnL> right, that is something that kind of just happened
<srhb> Oh, I haven't heard of this, where can I read about that?
parsley936 has joined #nixos-chat
avn has quit [Ping timeout: 256 seconds]
<LnL> nowhere AFAIK
<srhb> can't find it in the scrollback. Maybe it's an illusion :-P
<srhb> Is there a way to have all flake follow certain inputs from the root flake unconditionally? Going through each one and specifying the inputs.follows for each one is tedious.
<LnL> if you look at the nixpkgs branches you'll see channels are also there now
<srhb> Oh, so what you're saying is that the _repo_ is deprecated, and they're just in nixpkgs now?
<LnL> I think so yes
<srhb> Ah, great. Panic averted. :-)
avn has joined #nixos-chat
<MichaelRaskin> Is
drakonis has quit [Read error: Connection reset by peer]
drakonis_ has joined #nixos-chat
cjpbirkbeck has quit [Quit: cjpbirkbeck]
avn has quit [Ping timeout: 260 seconds]
avn has joined #nixos-chat
<bqv> Hah, "channels are now deprecated" would be amusing to wake up to
<JJJollyjim> nixos: channels are now florps
<JJJollyjim> nix-build output goes sideways
<srhb> Closest thing I could find to a source: https://github.com/NixOS/nixpkgs/issues/71176
<{^_^}> #71176 (by edolstra, 30 weeks ago, closed): Merge nixpkgs-channels repo into nixpkgs
<srhb> So that's fine, just have to update some refs.
<srhb> (the channels-script still update the nixpkgs-channels repo explicitly since then, so all good)
<eyJhb> infinisil, gchristense, abathur thanks for the input! I have wanted for quite some time, to make a home intranet/API, where I can make a Web UI + Andriod app and put such things into it
<eyJhb> And as gchristensen, I also take time for breaks etc. anything else would be annyoing. Especially because normally people in my place would show up for work, and get paied to smalltalk as well
<eyJhb> Where I wouldn't sell myself short. But I should see if I can have good system, because I do have a lot of start stop at times
<eyJhb> sphalerite: what is the end goal?
<eyJhb> This is nice and frightining at the same time - https://gitlab.com/gitlab-com/support-forum/-/issues/1031
<eyJhb> Read the SSH part
drakonis has joined #nixos-chat
drakonis_ has quit [Read error: Connection reset by peer]
drakonis_ has joined #nixos-chat
drakonis has quit [Ping timeout: 256 seconds]
__monty__ has joined #nixos-chat
<eyJhb> Also, any good ways to manage keys such as backup keys, 2fa recovery keys, ssh keys, etc.?
<eyJhb> (Go __monty__ )
<__monty__> Oh, I'm the wrong person to ask about key management tbh.
<__monty__> Put them in a password store I guess?
<__monty__> 2fa keys in a separate offline store of course.
<eyJhb> Yeah, should set it up...
<eyJhb> Thinking keepass, with a key file + PW, then put at all in there. But would be nice if it was managed by cli however
<eyJhb> Maybe just use pass for everything
<srhb> I like bitwarden though I've yet to set up the cli properly.
<__monty__> Keep in mind that putting 2fa recovery codes in a password store next to your password effectively nullifies your second factor.
<JJJollyjim> ^^ i've been running a bitwarden-rs server for quite a while, it's really nice
<eyJhb> __monty__: basically need a printer and put it offline __monty__ ?
<srhb> I self-hosted for a while and then went with the upstream version
<srhb> Ideally I think I'd like to mirror it.
<JJJollyjim> monty: only for one of the ways your password can be stolen
<__monty__> eyJhb: Depends on how paranoid you are. A digital offline backup is fine imo.
<__monty__> JJJollyjim: Feel free to elaborate.
<JJJollyjim> if my google password is stolen via phishing
<JJJollyjim> but i don't give them my 2fa code
<JJJollyjim> i still have been saved by my second factor, despite keeping 2fa recovery codes in a password manager
<JJJollyjim> whereas obviously if my password manager is hacked, i'm fucked
<__monty__> Why would you not provide a 2fa code if you're fooled by the phishing though?
<eyJhb> JJJollyjim, srhb: I somewhat want to go for the self hosted, but my paranoia seems to think I cannet reuse a VPS for it, but it needs its own
<JJJollyjim> maybe i notice it's phishing halfway through
<__monty__> Yes, that'd be a single log-in or action that's valid for but still severe.
<JJJollyjim> or maybe my password is reused from another site
<srhb> eyJhb: I'm not one to judge other peoples' paranoia. :-)
<JJJollyjim> because i haven't finished changing all sites to generated passwords
<JJJollyjim> (not saying it's a great idea to keep 2fa codes in there but it's better than no 2fa at all imo)
<JJJollyjim> plus if you primarily use u2f/webauthn that's essentially phishing-proof
<__monty__> Not much effort to put the recovery codes on a usb pen drive though.
<JJJollyjim> i guess
<JJJollyjim> :)
<__monty__> On the same offline drive as your primary GPG key for example.
avn has quit [Ping timeout: 265 seconds]
<eyJhb> srhb: One must always feel a little judged, because I have no good way to take backups of the vault data. Still hate backups, no good way to do it... :(
<eyJhb> But I think I might look at BitWarden, and then take into account what __monty__ said about 2FA. Wanted to set everything up now! But.. Exams, sadly
<__monty__> eyJhb: Have you looked at borg or restic? It's not perfect but it gets the job done.
<eyJhb> Borg yes, but the last backup system I used was GPG, where a crontab ran each day on the servers, placed everything into /root/backup-date, tar, GPG encrypt and the put onto my server. Most servers I have do not have a lot of data
<eyJhb> So BORG is overkill
<__monty__> It's pretty simple to set up though.
<MichaelRaskin> __monty__: a password manager needs a database you hopefully take some care of, and a password that is hopefully harder to fish than the password to the service in question, so not a complete nullification
avn has joined #nixos-chat
<eyJhb> Beginning to think there is something seriously wrong with my computer. While copying paths from tha NixOS cache, my computer will freeze up...
KeiraT has quit [Ping timeout: 240 seconds]
<sphalerite> eyJhb: could also be IO starvation
<sphalerite> or RAM, knowing nix
<eyJhb> sphalerite: seems that it is the LUKS encryption that might be the problem. I have / encrypted
avn has quit [Read error: Connection reset by peer]
avn has joined #nixos-chat
KeiraT has joined #nixos-chat
KeiraT has quit [Excess Flood]
KeiraT has joined #nixos-chat
__monty__ has quit [Quit: leaving]
__monty__ has joined #nixos-chat
<bqv> just as i get comfortable with fish, i feel the insatiable urge to try xonsh...
<__monty__> bqv: Well that comparison is totally bogus.
<__monty__> bqv: Fish *obviously* has a pun in the name!
<bqv> haha
<__monty__> Hmm, what does "Rich history" mean?
<__monty__> Fish has the best handling of history I've experienced so far.
<bqv> i'm curious about that too
<bqv> i don't think it existed last time i attempted to use xonsh
<__monty__> Difference from fish sounds like "you can script it in python?"
<bqv> it sounds pretty small
<bqv> but that's actually insanely powerful
<adisbladis> I've given Xonsh a go a few times
<bqv> i watched this and now i have a hankering https://takoshell.org/
<adisbladis> Imo it's way too awkward to actually use
<bqv> i feel like if it's at all viable i'd rather just get used to it, cause learning how to efficiently python is more useful than random shell hacks
<adisbladis> Particularly I dislike loops in xonsh
<adisbladis> Let's say I want to iterate over lines or something like that
<adisbladis> There is a lot of syntax wrangling for that
<__monty__> I don't really need much fanciness from a shell. It's just a way to run programs which can be written in whatever language you want for me.
<bqv> as in python iterate over lines? seems simple enough from the tako video
<adisbladis> __monty__: You think so until you try a shell which actually has good facilities for looping
<bqv> which would that be?
<sphalerite> bash? lol
<adisbladis> Fish has excellent support for writing inline "shell scripts"
<adisbladis> It has proper multi-line editing
<__monty__> adisbladis: I already swear by fish. And I write the occasional loop.
<sphalerite> if xonsh is python, can't list comprehensions do the job?
<bqv> yeah, i've been on fish for the last few months, i still don't like shells
<bqv> sphalerite: yes
<adisbladis> sphalerite: It's hard to quantify what I think is wrong, but I always felt that Xonsh wasn't very good as an interactive shell
<__monty__> Fish's focus on UX and good defaults is really nice imo. Being customizable doesn't mean the default should be frustrating, looking at no one in particular <.< bash, zsh
<sphalerite> adisbladis: fair enough. I haven't actually tried it so I'm talking out of my … here
<sphalerite> I used zsh for a while, but am now back on bash out of, uh, laziness I guess?
<sphalerite> It's just nice to have it the same here as on every server I ssh to
<sphalerite> I might give fish another try someday
<adisbladis> After using fish for a decade using bash feels like...
<adisbladis> I don't know.. Going back a few decades
<bqv> fish is lovely, easily my favourite of the traditional posix-like shells
<bqv> i was an elvish user for a little while but that was way too young for real use
<adisbladis> I really want to like Xonsh
<sphalerite> any powershell users? :D
<sphalerite> and how is fish's structured data story?
<eyJhb> srhb: bitwardens cli is not human friendly :p
<bqv> i'm not new to the idea of using something you dislike because you know you'll thank yourself when you end up good at it and liking it
<adisbladis> sphalerite: I have used it, and while I like the object piping aspect the ecosystem is absolutely terrible and extremely verbose
<bqv> it's what i did with vim and emacs
<adisbladis> sphalerite: Fish structured data is one of it's weak points.
<bqv> adisbladis: maybe you'd like tako (see link i sent, it's a xonsh fork/strip)
<pie_> what is it with shellls and being bad at structured data
<sphalerite> adisbladis: oh, hm. Because that's part of why I might want to switch, to be able to handle structured data better
<sphalerite> maybe someone should build a shell based on jq
<pie_> or is it that once you have structured data its a real programming language
<sphalerite> /s. I think.
<adisbladis> pie_: Because (hot take) shell is a lowest common denominator race to the bottom thing
<pie_> maybe we'll get a good shell once people figure out programming languages
<pie_> XD
<adisbladis> Shell is actually absolutely terrible
<bqv> i feel like the shell situation is orders of magnitude more fsck'd
<sphalerite> maybe we'll get a good shell (hot take) once people forget about the classic unix tools.
<bqv> isn't that effectively what xonsh does? take all the stuff you'd do with cut/sed/awk and replace it with the python standard library
<bqv> not exactly more space efficient but certainly more modern
<adisbladis> Tbh if I manage to switch shells I'd probably end up using eshell
<bqv> don't
<bqv> it's a mistake
<adisbladis> ^_^
<MichaelRaskin> Shell has some things done well that other programming languages do badly.
<adisbladis> Why?
<bqv> maybe a side effect of my using exwm too, but it's far, far too easy to either run a verbose command and lock up emacs due to the text terminal limitations, or just break emacs
<MichaelRaskin> And also other cross-language call interfaces are also pain, so…
<bqv> i really wanted to like eshell, but having to force kill emacs three times a day is not productive
<pie_> bqv: well that sounds great :I
<bqv> god bless vterm :p
<__monty__> Aww, I got excited for a minute, though you were talking about an E-based shell : /
<bqv> well that was short lived https://hastebin.com/elamunekac.sh
<bqv> presumably programs.xonsh.enable is a requirement, guess i'll have to wait for the system to finish building...
<bqv> oh lord it's building gccjit, why
<ar> there's also elvish if you want a shell that's less terrible at structured data
<bqv> probably more efficient to just link this https://github.com/oilshell/oil/wiki/ExternalResources than start linking projects
<sphalerite> :D
<pie_> bqv: ooo
<pie_> bqv: i love related work sections
<armin> wow my zshrc is becoming a bit huge
<armin> just spent 20min refactoring code
<adisbladis> Except for the prompt it's all defaults
<adisbladis> That's a really awesome thing about fish, the defaults are so damn good
<bqv> in fairness, i think it's intentional that an unconfigured zsh is so bare it's basically interchangeable with bash
<__monty__> That may well be, but it's the wrong decision imo.
<__monty__> I'd even argue a fancier bash would be a good default on most distros.
<bqv> probably, but which project to go for would be the mother of all controversial decisions
<__monty__> I'm talking about simply enabling some bash functionality to be clear. Not mimicking fish or something.
<bqv> oh, right
<pie_> hot take: nixos is the bockchain of operating systems
<joepie91> false
<joepie91> NixOS is generically useful
<joepie91> :P
<adisbladis> false: NixOS actually has users
<adisbladis> IME most blockchain projects actually never ends up getting used by anyone
<Valodim> hot take indeed
<adisbladis> Hm
<adisbladis> Re xonsh
<adisbladis> Are there better completions somewher?
<adisbladis> somewhere*
<adisbladis> Like completing known_hosts
<bqv> currently fiddling with this list
<adisbladis> Whoa
<bqv> gonna morph it into a crappy ad-hoc flake
<adisbladis> You've already lost me on xonsh...
<adisbladis> Way too much setup
<bqv> none of that is necessary
<bqv> i just wanted direnv but it's not there by default
<bqv> but in fairness, it isn't for fish either
<adisbladis> bqv: Do you have ssh completions?
<bqv> assuming you mean host-completion, nope
<bqv> i've never actually used that though, didn't realise it was a thing :p
<adisbladis> Iirc that's been a thing for the entire time I've been using fish
<__monty__> I love the tab completion for paths on remote hosts.
<adisbladis> Yeah that's fantastic
<__monty__> And hmm, direnv works fine with my fish?
<bqv> i'm not sure how useful i find it conceptually. i like tramp-mode, but i feel like a shell isn't the place for that kind of stuff
<bqv> __monty__: presumably you had to eval (direnv hook fish) or something though, right?
<adisbladis> bqv: Typing `scp ./localpath remotehoste:somep<TAB>` is pretty nice
<bqv> cause the fish module is in direnv
<__monty__> I guess so.
<bqv> well, at least not having committed it to muscle memory, i woun't have to unlearn it
<bqv> i will have to relearn $() though
<gchristensen> okay so using the cgroup freezer works just as well with the added benefit of the processes having no idea they're being frozen
<__monty__> Just as well but no better?
<__monty__> Re the clipboard and other issues?
<gchristensen> hm? I just said how it is better :)
<gchristensen> ah clipboard was fxed with a clipboard managre
<__monty__> I'm not sure "processes having no idea they're frozen" is necessarily better though.
<__monty__> Programs that use the network might want to do something to the connections.
<gchristensen> oh it is, it fixes the "zsh thinks I hit ctrl-z" problem
<manveru> connections may die at any time anyway... not much different from suspend?
<__monty__> Oh, yeah. Hadn't considered shells would just pass those on.
<adisbladis> bqv: Hm, not a fan of all the -tabcomplete packages :/
<__monty__> manveru: I dunno, ssh timeouts are pretty annoying, think I'd rather have the program kill the connection. Not sure ssh actually does this but the reasoning doesn't change.
<manveru> xonsh lost me as soon as it mentioned python :P
<bqv> i suppose the tabcomplete thing could be done the same way as fish, with a system directory
<adisbladis> That's what I mean
<adisbladis> Writing completions manually like a caveman?!
<bqv> manveru: what language would you otherwise choose, out of curiosity? i'm not a fan of python much myself but i feel like this is where it excels
* adisbladis has a very complicated relationship with Python
<gchristensen> __monty__: you keep trying to find problems here, but I haven't had it happen in practice :)
<adisbladis> You could even call it an abusive relationship
<bqv> xD
<__monty__> gchristensen: I'm skeptical by nature.
<bqv> the good news is nature is doomed, so you won't be for long
<adisbladis> NameError: name '__xonsh_env__' is not defined
<adisbladis> God damn it xonsh
<bqv> did you just shell or enable programs.xonsh?
<adisbladis> shell
<bqv> cause i had issues with the former too
<bqv> not sure what the packaging story is
<__monty__> Too bad we don't have a quote bot "The good news is nature is doomed" : >
<adisbladis> Let's see what magic the xonsh module does..
<adisbladis> No magic what so ever it seems like
<bqv> huh, guess it's just broken then
<bqv> charming
<adisbladis> bqv: This was while trying to load powerline
<bqv> oh
<adisbladis> Seems like powerline is broken
<{^_^}> santagada/xontrib-powerline#25 (by wmayner, 37 weeks ago, open): NameError: name '__xonsh_env__' is not defined
<gchristensen> __monty__: a major benefit here is slack takes 0% CPU and lets me dedicate 100% of my CPU and battery to scrolling Twitter.
<bqv> well at least it's known :/
<adisbladis> The fork refered to in that issue works, but somehow powerline makes the tab completions worse
<bqv> :')
<adisbladis> Or... I don't know
<__monty__> gchristensen: Yes, that *is* awesome.
<adisbladis> nix run -f '<nixpkgs>' xonsh -c xonsh
<__monty__> Like an optimized quit/restart workflow.
<adisbladis> Has a "better" completion mode than running the pypi package
<adisbladis> I wonder why that is
<bqv> i really have no idea where to start with the issues but clearly the packaging is somewhat off
<adisbladis> bqv: I created my own env with poetry & poetry2nix
<bqv> i have the issue that i can't load anything from xpip because pip doesn't exist, which is slightly predictable but could be nicer
<bqv> ah ok
<adisbladis> http://ix.io/2ml9 (pyproject.toml) + http://ix.io/2mla/nix (shell.nix)
<bqv> it annoys me how simple that is
<adisbladis> :D
<adisbladis> bqv: If I create a testimonials section for poetry2nix that quote will definitely go in there
<bqv> heh
<adisbladis> Ah right, I think there are some optional dependencies that makes the prompt nice
<bqv> i'll be back shortly, partner is sending me to get wine and i'm hardly gonna say no
<adisbladis> Nice, you got your priorities straight
<adisbladis> http://ix.io/2mlc matches the nicer completions in nixpkgs :)
<manveru> bqv: basically any other language that doesn't require significant whitespace
<adisbladis> Xonsh has gotten a lot better since I tried it last
<adisbladis> But OOTB history is nowhere near fish
<adisbladis> I think the problem with xonsh is the same as emacs/nvim has, it's probably awesome but requires too much investment to get there
<neeasade> what will save is is oil shell
<neeasade> bash compatible with some extras
<adisbladis> Been there done that, it's terrible too
<neeasade> 𝚜 𝚊 𝚍
<adisbladis> Bash compatible is not a feature
<bqv> manveru: mm, i do feel like python wins on every alternative on convenience, nothing's as simple for rapid prototyping and ad-hoc scripts
<bqv> adisbladis: yeah that's my understanding too, but i'm willing to make that investment
<neeasade> I think it can be -- as a way to sneak into existing contexts/provide better failure information is why I see it as appealing
<manveru> bqv: for interactive complex stuff I just use pry. the rest is fine with bash/zsh
<manveru> Ooh, just found https://github.com/tombenner/ru which is like the best of both :)
<bqv> sh so you like ruby
<bqv> well, i guess that works, i just don't swing that way
<adisbladis> I'm far too stupid for ruby
<infinisil> Yay, firefox now remembers which WM workspace all windows were, so it restores them correctly when restarting!
<manveru> Btw is there some nice way to get the Minecraft service to work with mods?
waleee-cl has joined #nixos-chat
<bqv> that reminds me, adisbladis: what are you up to with xpra?
<bqv> cause i had some terrible half-baked plans to use it with exwm so i can restart emacs without killing my entire session
<neeasade> infinisil: baller
<infinisil> I love it when some small things suddenly start to work just by updating
<infinisil> This update was a good one, first emoji in terminal, then this
<adisbladis> bqv: I'm not using xpra at the moment
<bqv> ah ok
<neeasade> Emoji ☕
<bqv> i was github searching to see if anyone had done what i was thinking of before and came across references to it in your config
<adisbladis> bqv: It's not really all that useful for me
<adisbladis> Everything except the browser is emacs buffers anyway
<emily> tbh, i think python is a weird choice for a shell
<bqv> mostly same, but sometimes i have things open
<emily> it's not like it's good at concise data manipulation or compositional programming or ...
<emily> something like elvish is much more interesting
<emily> (this might just be because i'm a python-hater, but it really does seem way less suited to "interactive/explorative shell use" than "simple 50-line scripts that would otherwise be bash", which is what i mainly use the language for)
* adisbladis will probably stick to trying to avoid shell as much as possible
<adisbladis> I wonder how different the computing world would be if lisp machines licensing had been better....
<bqv> emily: i think i prefer python purely because it's already well-established, and we all already know it. elvish just means learning *yet another* language that may or may not even be good and has no transferrable skills/scripts
<bqv> (i say that having used elvish for longer than i have fish)
<neeasade> I've been using elisp/clojure in my smol utility scripts lately
<MichaelRaskin> adisbladis: I think portability to ever weaker hardware also mattered for UNIX
<adisbladis> Absolutely
<emily> bqv: yeah. well, I'd be happy with an existing FP language really; I know there's things like https://github.com/borkdude/babashka but haven't really used them at all
<emily> emacs people like eshell I guess
<bqv> i liked eshell until i extremely didn't
<bqv> and i considered a haskell-based shell
<neeasade> for the interactive experience, I still prefer bash + shell-mode -- lispy interactive shells just don't really stick with me for some reason
<bqv> but i do think python is just easier
<adisbladis> Ugh, haskell shell sounds terrible
<bqv> it's not about writing good code, and that's where python excels :p
<emily> lisp machine hardware is... overrated. it had some cool lisp-specific features wrt tagged memory and GC integration but it wasn't like the radical departure from imperative C-ish architectures people seem to think
<adisbladis> But I don't have a very high opinion of haskell
<neeasade> emily: babashka is really smooth FWIW
<emily> a modern lisp machine processor that can go to bat with a regular implementation on x86 would be about as ugly as the x86
<emily> haskell is great but I don't think it has the kind of reflection/extensibility/lightweightness you'd want for an interactive shell
<adisbladis> Me being a Haskell outsider I keep seeing broken Haskell builds in Nix all the time
<adisbladis> So from my perspective it seems brittle as hell
<emily> https://wryun.github.io/es-shell/ is great reading for anyone interested in higher-order functional shells
<emily> adisbladis: the nixpkgs haskell infra is kind of weird, but: that's mostly because most languages don't have entire package repositories mirrored in
<bqv> another one that just invents it's own language?
<emily> the haskell packaging in nixpkgs is very comprehensive and automated, it has all of stackage (iirc)
<emily> bqv: it's based on rc of unix tenth edition and plan 9 vintage
<emily> so, yes custom language, but with a heritage at least
<emily> (it's also quite old itself)
<adisbladis> emily: I maintain the emacs infra and we have less than 100 broken packages out of 15k
<adisbladis> Just as a data point
<MichaelRaskin> I think a large part of Haskell breakage is the culture of deliberate brittleness, i.e. setting the version upper bounds to exactly the value tested, no trust in semver
<adisbladis> While Haskell seems to cause havoc on every Stack bump
<emily> adisbladis: how many of those do things like depend on native libraries?
<emily> I don't think emacs packages are really comparable
<adisbladis> emily: More than you'd think
<emily> anyway haskell's packaging story isn't ideal in a bunch of ways
<bqv> adisbladis: haskell and elisp are very very different things...
<emily> in both ways related and unrelated to the nixpkgs integration
<adisbladis> Yes, I wasn't really trying to compare the two
<bqv> and there's very little guarantee that if something byte compiles it even works
<emily> it's... still rather ahead of the dynamic languages though
<adisbladis> Just saying from my perspective Haskell packaging seems like a dumpster fire
<bqv> i mean i've never used haskell through nix, and frankly from the things i've seen i'm not sure i want to
<bqv> but i wouldn't judge it based on that
<emily> I've never seen a language ecosystem with a package story that wasn't kind of a trash fire
<emily> even rust/cargo gives a bunch of awkwardness with nix
<bqv> go works quite well in nix, actually
<bqv> but that's kinda the only one
<emily> people are just bad at packaging because it's really hard, we should know that >_>
<emily> bqv: except for the whole https://github.com/NixOS/nixpkgs/issues/84826 thing
<{^_^}> #84826 (by nlewo, 5 weeks ago, open): Recommend buildGoPackage instead of buildGoModule in the nixpkgs manual
<bqv> oh, right
<emily> which i think there's still no real consensus on (but that's a more general thing rather than something that only applies to the go infra)
<bqv> "it works well because it's not very nix-y", basically
<emily> yeah. I tried to move some packages I maintain to vgo2nix and it didn't work because of limitations in vgo2nix :(
<emily> (not recognizing certain git tag names)
<adisbladis> emily: It's "funny" that vgo2nix caught on
<emily> so if you want to avoid fixed-output derivation stuff the current state of things is not ideal
<bqv> i honestly hate the *2nix tools
<bqv> can't wait for recursive nix to catch on
<adisbladis> Nooo!
<adisbladis> Recursive nix is _terrible_ ux
<emily> damn we're having all the arguments at once today
<adisbladis> Let's say you want to override something deep inside your dependency graph
<bqv> lmao
<adisbladis> Recursive nix completely breaks the ergonomics of overrides
<bqv> that's true
<emily> overrides are already pretty horribly broken with rec and let and the like
<adisbladis> Imo, Nix needs to become _more_ of a general purpose programming language so we can get more solutions like https://github.com/nix-community/poetry2nix
<adisbladis> Tooting my own horn here
<bqv> but in fairness, 1. i feel like overrides need to be specialcased for anything requiring IFD anyway
<emily> i feel like the whole system needs a rethink, at which point you could probably make overrides work
<bqv> and i got distracted and forgot what 2. was
<emily> nixpkgs already avoids IFD quite stringently
<emily> I think IFD is way worse than recursive Nix tbh
<adisbladis> Lukewarm take: Recursive Nix is just IFD in disguise
<Taneb> I don't really know what the difference between the two is :(
<emily> it's like more principled IFD
<emily> I mean, for one it doesn't happen at the evaluation stage
<emily> that's a pretty big deal
<emily> Taneb: IFD - evaluation depends on building things. recursive Nix - builds can depend on building things directly through Nix
<Taneb> Right
<emily> "ret-cont recursive Nix" - derivations can resolve to other derivations which are then built to give the final results. like tail-position-only recursive Nix, has some better static analysis properties, you can think of this like a monadic join
<bqv> interesting
<Taneb> That makes sense but I feel like I'm still missing some details
<emily> unfortunately I don't think anyone has figured out all the details around recursive Nix yet
<emily> there's an experimental implementation in recent Nix if you want to play with it though
<adisbladis> Another thing I don't like about recursive Nix is that it makes it impossible to inspect the build graph
<adisbladis> The leaf is just a huge black box
<adisbladis> I'm legit scared people will start using it for 2nix, because superficially it looks appealing
<adisbladis> Just like we have tons of IFD abuse now
KeiraT has quit [Remote host closed the connection]
<emily> I think it's valuable to support cases that require recursive Nix even though it's better to avoid it when possible
<emily> I like poetry2nix but unless you reimplement GNU Make in Nix you're never going to get the equivalent of basic ccache support
<emily> which is something that Nix really ought to be able to do and would be really convenient
KeiraT has joined #nixos-chat
<adisbladis> emily: Exactly :) I'm not saying recursive Nix is not valuable for anything
<adisbladis> But it's not a panacea to code generation
<bqv> the current state of affairs is really quite unpleasant as an alternative... i can't think of a time i didn't have an awful experience with a *2nix
<emily> I'd really like to get to a world where we can just track hashes, not a pile of generated code, into nixpkgs (and have caches cache evaluation results so that people don't have to download all of <package index> themselves just to access attribuets)
<emily> but it's definitely a long path and there are a lot of pitfalls along the way
<emily> and I don't want to just cheat and skip there by abusing fixed-output derivations like lots of nixpkgs does currently :(
<infinisil> What if the problems with IFD were fixed
<adisbladis> infinisil: That's impossible
<bqv> oh, so solve the problem of language repositories not having hashes immediately available by having the hashes in nixpkgs, so you can just use nix for everything
<emily> arguably, the problem is inherent
<emily> people want evaluation to not require building and to have a clean two-stage process
<emily> tbh I'm fine having things take place in an arbitrary number of stages but I get why it freaks people out
<emily> in my view, we already have an arbitrary number of stages, it's just we delegate all but the last to humans and manually commit the evaluation results (generated foo2nix code)
<infinisil> Why is a multistage process an inherent problem?
<adisbladis> infinisil: For one I like to inspect my build graph ahead of time
<infinisil> What if we had cached evaluation, even through substituters
<infinisil> What if Nix would expose the different stages explicitly
<emily> bqv: right. in nixpkgs you have the pointer to the external resources, the logic for turning it into nix packages, and the necessary hashes to pin it all deterministically (hopefully in another machine-managed file); hydra caches not only derivations but some of these evaluation stages so that the automatic derivation from the upstream packages can be more transparent to end-users
<emily> seems like me and infinisil are on the same wavelength :p
<emily> adisbladis: it's a matter of where you pick the "ahead of time", though; you don't statically know it at the time of foo2nix, and foo2nix is morally a build step that you just don't track with nix
<bqv> i like that
<infinisil> I really feel like IFD is in principle a good idea, it's just kind of bad to work with currently
<emily> I think it makes sense to have build graphs as statically analyzable as possible, and have tools for forbidding build graphs that aren't statically knowable, but still allow and support them
<emily> my general position is that although there's lots of valuable consequences of the evaluation/build split, it's ultimately somewhat artificial
<adisbladis> emily: By "ahead of time" I mean `nix-store -qR $(nix-instantiate foo)` should work without building
<bqv> i think that's the crux of why i don't like *2nix, it's just literally using you as a build tool for something that really could be done with nix, and there's next to no benefit to it being done personally by you
<emily> you can imagine a builtins.compileSomeC that doesn't involve any kind of forking at all and you'd want it to be cached just like regular builds all the same
<adisbladis> bqv: "not all *2nix" ;)
<emily> and indeed as people write more elaborate stuff in Nix we end up wanting similar things (see: evaluation cache)
<adisbladis> Some actually are implemented in Nix!
<adisbladis> Not many though :/
<bqv> fair point
<emily> my other general position is that Nix is not a very good language :(
<adisbladis> emily: What I'm hearing is we need to implement another language in nix
<bqv> why?
<emily> it's awkward that you have to use Nix to benefit from a lot of things, because the consequence is you have to write real code in Nix, and it really isn't good
<infinisil> Oh, I've brought up this before, but what if we had builtins.haskell which can do arbitrary pure things
<emily> no static types, terrible library, slow as molasses, useless error messages,
<bqv> i find almost every issue i have with nix as a language except for the lack of static typing is actually just a problem with nixpkgs
<infinisil> Then I think we could use that instead of IFD
<emily> I love Nix but if you look at it as a programming language it really is just not good
<bqv> infinisil: woah
<adisbladis> I actually kind of like Nix
<adisbladis> (The language)
<emily> infinisil: are you sure you don't just want to write ShakeOS? :p
<infinisil> builtins.haskell would run with SafeHaskell, with an interface restricted to some effects
<infinisil> which would allow you to fetch stuff from online in a pure way for example
<adisbladis> Hehe
<adisbladis> Somewhere I have an experiment adding sockets to Nix
<MichaelRaskin> Meh, Guix already exists
<emily> down with fetchurl tbh
<emily> every fetcher should be a flake input (or equivalent) instead
<emily> I'd rather see a world with no fixed-output derivations at all
* adisbladis pukes a bit
<bqv> one argument at a time, jeez
<emily> you can't complain about wanting to statically analyse your build graph and then allow arbitrary expressions to do HTTP requests!
<bqv> she has a point though...
<adisbladis> emily: I'm still very much on the fence on flakes
<MichaelRaskin> Do we even have support in flakes for real DVCSes?
<adisbladis> MichaelRaskin: "real DVCSes" meaning ?
* emily wonders how much work the "real" is doing there
<emily> I guess it depends on how real you consider git
<MichaelRaskin> Anything that doesn't discard what branch a commit belongs to
<bqv> why is that relevant?
<adisbladis> Git isn't real, none of this is real
<MichaelRaskin> Because we have fetch* in Nixpkgs
<emily> I really put everyone into troll mode huh
<bqv> adisbladis: it's ok, reflog
* emily takes off the ring of conflict
<MichaelRaskin> And maintaining that on the Nix level is a ton of work
<MichaelRaskin> Maintaining in Nixpkgs is much nicer
<emily> there's no reason flake fetchers couldn't be implemented in nix themselves
<emily> with some kind of trust model, blah blah, wave hands
<emily> (however then you get back to "Nix kind of sucks")
* adisbladis tried using flakes...
<adisbladis> I still don't know how to replace shell.nix with a flake
<bqv> i feel like against logical instincts, we should avoid the problem of "nix kind of sucks" for the time being
<bqv> adisbladis: i did that a few hours ago
<Taneb> I've been thinking for a while about experimenting with using jq instead of nix
<bqv> devShell.x86_64-linux
<Taneb> Because why not use a worse programming lanugage
<bqv> the nix dev-shell
<emily> adisbladis: nix dev-shell
<bqv> Taneb: i don't want you to elaborate
<adisbladis> So... I still want `nix-shell` to work
<bqv> good luck then
<adisbladis> And what attributes does `nix dev-shell` even run on
<bqv> see above
<adisbladis> Also that thing about arches being something I have to care about in my flake annoys me to no end
<bqv> it's a reasonable interface for the fact that system architecture is a universal input
<bqv> it's that or your flake evals but you get some weird build failure because some flake 4 chains deep doesn't support your arch
<bqv> i don't like it either, but i respect it
<adisbladis> I think it's bad design
<adisbladis> Nix is already hard enough without worrying about architecture support
<bqv> it's a poor solution to the problem, but we can't also just ignore the problem
<emily> :( i assume you also want to remove cross-compilation support from nixpkgs then
<emily> I don't think deliberately getting things wrong because it'd be more convenient to is good design (otoh the need to do the forAllSystems nonsense thing in every flake is pretty bad design I think)
<adisbladis> No, but I also don't see why it needs to be somethig that every flake hard-codes
<bqv> emily: take that ring off dammit
<emily> haha sorry :3
cole-h has joined #nixos-chat
<eyJhb> joepie91: can it really be, that executing a TS would take 1s? Can't it be compiled?
<Taneb> I should actually implement the idea I had for packaging Agda packages in nixpkgs
<emily> I'm not sure why you can't just offer a cross-platform package set
<emily> and refine it with per-arch ones
<emily> I guess because flake outputs are Literally Just Attrsets
__monty_1 has joined #nixos-chat
__monty_1 has quit [Client Quit]
<cole-h> Friends, it's time. I'm getting ready to install NixOS (on an unused hard drive to actually get the system set up before I truly migrate).
<bqv> cole-h: welcome comrade
* emily toots party horn
<emily> finally something we can all approve of
<joepie91> eyJhb: what is "a TS"
<eyJhb> Sorry, joepie91. A little too fast. Executing TypeScript
<eyJhb> Sitting with this - https://github.com/bitwarden/cli
<eyJhb> ANd a simple --help is 1.05s
<adisbladis> Down the rabbit hole you go
<joepie91> eyJhb: typescript compilation is normally a thing you do before release, the end user gets JS
<bqv> imagine not using nixos (seriously, can anyone still imagine what that's like?)
<cole-h> Quick question: is ZFS beneficial on an SSD?
<joepie91> if they actually are runtime-typescript-compiling it will be slow yes
<bqv> define "beneficial"
<cole-h> Installing to spinning rust for now, but eventually I'll move to my SSD and wanted to know pros and cons for SSD-ZFS
<emily> cole-h: sure
<__monty__> cole-h: Feature-wise, yes : )
<eyJhb> So we agree, it should be a lot faster than 1s?
<emily> most of the reasons you'd use zfs are the same regardless of what type of disk
<bqv> yeah
<cole-h> I imagine IO throughput will be slightly decreased due to being CoW, but anything else I should be aware of?
<bqv> it's beneficial to YOU, not necessarily for your disks
<joepie91> but 1s seems rather slow for just a start of a JS process
<joepie91> eyJhb: it's never going to be instant due to module loading but 1s seems too high
<emily> (checksumming, the device management, native encryption support, ...)
<eyJhb> I think the packaging in Nix might be wrong then. Are you a expert in this?
<emily> cole-h: make sure you set the right options when creating the pool, mainly :/
<emily> (and "the right options" isn't fantastically well-documented)
<__monty__> cole-h: Why? A changed block needs to be written regardless. And compression can mean you don't actually write as much.
<bqv> they can't be changed later?
<emily> not all of them
<bqv> yikes
<cole-h> __monty__: I was just intuiting -- if CoW doesn't actually decrease IO throughput in any meaningful way, that's great!
<bqv> what FS are you coming from?
<MichaelRaskin> bqv: I no longer use NixOS proper
<bqv> D:
<emily> cole-h: in particular you're going to want -o ashift=[depends on HDs/SSDs you're going to be using] -O compression=on -O xattr=sa -O acltype=posixacl at least for nixos, and some stuff to use legacy mountpoints as well. the wiki has some detail but also some bad advice :(
<bqv> MichaelRaskin: what did you move to?
<joepie91> eyJhb: don't know about a "lot", but faster, yeah, probably
<cole-h> bqv: Bog-standard ext4
<MichaelRaskin> I just write the Nix expressions for my bootscripts by hand
<bqv> oh! that's very cool
<MichaelRaskin> With overlay-style self:super: instead of module system
<eyJhb> joepie91: seems like it is just a long dev file, net build etc..vv
<eyJhb> joepie91: https://termbin.com/3bjcb part of it
<bqv> i'm extremely interested because somewhere up my todo stack is to replace systemd in nixos with s6
<eyJhb> So it is doing runtime compilation
<MichaelRaskin> I guess I could help you with some parts. But I use sinit.
<bqv> cole-h: granted i use btrfs not zfs, but i see no discernable difference between ext and btrfs, so you should see very little between it and zfs either
<joepie91> eyJhb: err, I'm a bit confused as to what you mean
<joepie91> eyJhb: that bundle is generated at runtime?
<bqv> MichaelRaskin: i'll bear that in mind
<eyJhb> The file I just linked, is what my bw points at, when I do a nix-shell -p bitwarden-cli
<eyJhb> (the entrypoint to bitwarden-cli)
<MichaelRaskin> Most of the system tasks are handled by a custom daemon in Common Lisp. Which uses crash-based updates just because I want to stress that it doesn't own the system, it just has access for doing some necessary work
<MichaelRaskin> Actually, nothing would conflict with also adding s6 supervising some daemons
<bqv> this sounds very interesting, have you considered genericising it for public use
<MichaelRaskin> Well, anyone can grab my repository and override whatever they don't like etc.
<MichaelRaskin> My own system is an override on top of a more generic system I tested inside a VM
<bqv> ah okay
<MichaelRaskin> But I optimise for my very specific tastes and do not implement any mechanisms necessary for other stuff
<MichaelRaskin> So far people sometimes read it as a curiousity or inspiration or a way to solve specific problems
<MichaelRaskin> I would gladly help you to set up something more generic based on a similar design — but I won't want to spend effort on trying to build a genericised version without some users providing input to the requirements list
<MichaelRaskin> The part that took effort is encoding my wishes inside the Common Lisp part…
<bqv> i love this, but yeah fair enough. i don't blame you, if i managed to get s6 working i likely also wouldn't put much effort into genericising it
<MichaelRaskin> I mean, probably the Common Lisp part is not what you would care about
<bqv> yeah
<MichaelRaskin> The rest is pretty generic, except I explicitly do not give a damn about declarative specification of mounts so a system comes with mount-partitions.sh
<MichaelRaskin> And also my initramfs is in hundreds of megabytes
<MichaelRaskin> Because any system where I consider using those scripts has multiple gigabytes of RAM, so why bother with optimising the initramfs
<eyJhb> joepie91: might have to look at it, it isn't very nice to do it that way
<bqv> i disagree with that on an ideological level
<joepie91> eyJhb: then I
<joepie91> oops
<joepie91> eyJhb: then I'm not sure how yoy are inetrpreting that as "runtime build"
<joepie91> you*
<MichaelRaskin> bqv: well, I want to split my system into many partitions
<joepie91> looks like the opposite; they've pre-bundled code which in practice should actually reduce loading time
<bqv> hmm
<MichaelRaskin> Which means that HDD chatter just to mount all that will have a lower bound whatever I do
<eyJhb> joepie91: it is just so slow, there must be something wrong with it :(
<bqv> well, i think i'd still consider that size unacceptable, but it makes sense
<MichaelRaskin> initramfs contents is wiped before running the actual system, so it is a on-boot-only cost, not an ongoing cost
<joepie91> eyJhb: not much I can help with atm unfortunately, I'm pretty busy shopping for a new PC :P
<MichaelRaskin> I would not want hundreds of megabytes constantly sitting in RAM for no good use
<joepie91> what a nightmare
<bqv> it's the cost of keeping it and previous iterations around that worries me
<MichaelRaskin> Well, yeah, I have a 2GiB /boot (UEFI) partition
<MichaelRaskin> initramfs is per-kernel, not per-generation, after all
<cole-h> Grr, parted is complaining that my linux-swap partition wouldn't be "properly aligned"
aleph- has quit [Quit: WeeChat info:version]
<cole-h> Screw it, no swap partition
aleph- has joined #nixos-chat
<gchristensen> okay so email is generally bad but I just got a good one
<gchristensen> Subject: Hello and thanks from another Christensen Hi, Ward Christensen here, inventor of Xmodem and Bulletin Board Systems (Yes! I'm old - turning 75 this year). LOVE the concept of NixOS.
<cole-h> lol
<emily> NixOS: xmodem approved™
<bqv> MichaelRaskin: yeah, true
<bqv> gchristensen: love it
<cole-h> gchristensen: Skimming through your "ZFS datasets for NixOS" while I prepare to install to a spare HDD :D
<MichaelRaskin> Great
<gchristensen> nice :)
bqv has quit [Quit: WeeChat 2.8]
<MichaelRaskin> bqv: I agree this is a trade-off, but 128 MiB or 2GiB /boot is something that will never matter on target hardware. Such initramfs also take some time to compress during the build. But on the other hand, I just say what I want and it gets packed there, same shape as in the notmal system!
<aleph-> gchristensen: Yeah I'm really wondering how ZFS will work with only 4GB of RAM to work with
<aleph-> That'll be interesting...
<aleph-> It should work technically. Just not always that great from what I gathered
<cole-h> emily: Is there any problem with letting ZFS guess the ashift, instead of explicitly setting it?
<gchristensen> aleph-: on my raspberry pi with 1g of ram, zfs has never been a problem for me
<emily> cole-h: (a) the upstream whitelist of hardware for ashfit is kind of minimal (b) if you are going to add SSDs to your pool then you need to get the ashift right for them upfront
<emily> oh actually it's per vdev, never mind
<emily> I wonder how that actually works with mixed devices
<aleph-> gchristensen: Nifty, cool. What's your pool size and dataset sizes look like?
<cole-h> I'm not planning on adding any disks, really. Once I've set up this test disk, I'll start over and do it again on my SSD
<emily> but anyway, for SSDs the question is basically whether you want ashift=12 or 13
<aleph-> Doing 5 8-10TB disks in a raidz2 I think
<emily> yeah, you can just leave it off for spinning rust
<aleph-> So 3 data, two parity
<emily> when you get the SSD, try to do a bit of research to find out whether the native blocks are 4K or 8K and pick 12 or 13 appropriately
<emily> unfortunately it can be hard to find concrete answers
<emily> (drives generally lie to the host, so you can't just look at what it reports)
<gchristensen> aleph-: it is just 1 device, a 32G mmc. I have to say though the device does not see a lot of r/w activity, but at the same time, ZFS's memory problems are mostly myths and FUD built around people using dedup when you should not use dedup
<gchristensen> (don't use dedup)
<aleph-> Eyep that's what I had read. Mostly FUD
<aleph-> Got this one storage admin telling me I'll be fucking myself if I don't have 8GB+ of RAM
<aleph-> Or some crud
<gchristensen> pretty much lies
<gchristensen> (don't use dedup)
<aleph-> Eyep, no need for me
<aleph-> Or compression for that matter
<gchristensen> oh use compression :)
<gchristensen> compression is pretty much in the "use it unless you know for sure through testing that compression is going to harm you" category
<aleph-> Got it, it doesn't impact usability?
<aleph-> Planning to transfer 4TB of data off the bat to this pool/dataset
<gchristensen> for many use cases it improves performance because you can do less IO
<aleph-> Nifty
<cole-h> Sanity check: I want my rpool on my actual linux partition, not the boot partition, right?
<aleph-> gchristensen: Next month gonna be expensive lol
<gchristensen> yeoah? :)
<aleph-> Buying a new/actual desk for new office, 1.5k in HDD's, and a sofa
<gchristensen> cole-h: right, so like sda1 is /boot, sda2 is the zpool
<aleph-> And probably a painting
<gchristensen> nice
<aleph-> Maybe a rug
<gchristensen> big month
<aleph-> Ya, renting out another room in this flophouse as an office
<cole-h> NixOS on ZFS wiki says $DISK-part1, which is my boot, so just checking. Thanks.
<aleph-> Want it to be rather nice
<aleph-> gchristensen: Thinking of doing an L-Shaped desk, maybe grab another smaller desk to slot in as a third side and have a kinda cubicle. Sofa for reclining, some paintings, shelving unit for holding servers + networking equip, move my mini-fridge in there, slap a rug down and add some paintings
<aleph-> The aleph-cave
<gchristensen> heck yeah
<aleph-> Yarp. Fiance is worried she won't ever see me again lol
<cole-h> Oh nice, systemd-boot is the default bootloader it looks like
<cole-h> Oh, for EFI systems
<gchristensen> systetmd-boot is efi only:)
<cole-h> I've already created my rpool -- can I enable encryption retroactively?
<gchristensen> encryption is a property of the dataset
<gchristensen> zpool create -O ... is setting a default option for all datasets created on that pool
<gchristensen> so you can st
<gchristensen> maybe I will erase and make my / encrypted with zfs ...
<cole-h> How does hardware-configuration know which disk to get the ZFS stuff from? All I see is the device pointing to rpool/... etc
<gchristensen> it causes the early boot stages to run a `zpool import rpool`, and zfs automatically scans the available to find rpool
<gchristensen> part of the design of zfs is you don't have to do special stuff to register more ram to your system, how can they make disks the same
<gchristensen> and here it is :)
<cole-h> Oh, I see.
<cole-h> Then, let's get to the `nixos-install`!
<elvishjerricco> cole-h: Note about encryption: It's generally advised not to enable encryption on the root dataset in ZFS, and to instead have a child dataset where your stuff actually lives.
<gchristensen> why's that? to me, that sounds like an accident waiting to happen
<clever> the native zfs crypto also doesnt obscure the names of datasets
<cole-h> elvishjerricco: Yeah, I just read that.
<elvishjerricco> In fact the only properties I *would* set on the root dataset are `compression=lz4` and `mountpoint=none`.
<cole-h> gchristensen: So that you can create unencrypted child datasets
<cole-h> AFAIK
<gchristensen> ah, yeah, that is the accident waiting to happen that I'm imagining :)
<etu> That's probably something I don't want :p
<elvishjerricco> That and because you can't ever change encryption settings; if you want to change them you need to make a new child and move things over
<elvishjerricco> gchristensen: You can also create unencrypted children of an encryption root anyway
<elvishjerricco> so the accident is just as possible regardless
<gchristensen> but not by default?
<cole-h> Well guys and gals, time to reboot the desktop. Let's see how this goes!
<gchristensen> I'd have to explicitly opt in to making it unencrypted, which feels less on-accident
<joepie91> people who appreciate good design might be interested in this little thread: https://twitter.com/joepie91/status/1262072684696961026
<gchristensen> and if I want to change encryption I'd could still make a new child dataset anyway, right? so I'd be in the same position, but without a possible footgun default sitting there
<elvishjerricco> gchristensen: You sure about that? I know if you `zfs receive` a dataset that was sent with its properties included, it'll default (silently) use the encryption settings of the sender; including unencrypted
<gchristensen> fair enough, but still -- seems safer and like you actuall ydon't lose *anything* by making it encrpt-by-default?
<elvishjerricco> gchristensen: Just making a new child leaves the old dataset with its old encryption settings, requiring its passphrase to load it, which is very inconvenient
<gchristensen> ah
drakonis has joined #nixos-chat
<gchristensen> this is all fine for me and my laptop use case
<elvishjerricco> I think there's other reasons that I'm just forgetting....
<cole-h> Also, when I boot, I see a FIRMWARE_BUG message, which seems to hint it's related to ucode -- is there a way to update this on Nix?
<cole-h> "TSC_DEADLINE disabled to due Errata: please update microcode to version: 0x22 (or later)"
<cole-h> ... I guess this should probably -> #nixos
<clever> cole-h: intel or amd?
<cole-h> Intel
<cole-h> (for now)
<elvishjerricco> gchristensen: Oh, another reason is that you can't receive into an encrypted root dataset.
<clever> cole-h: hardware.cpu.intel.updateMicrocode true;
<elvishjerricco> you have to make a child
<cole-h> Thanks.
<elvishjerricco> not a big deal but annoying for replication
<gchristensen> hrm
<gchristensen> meh :P
<gchristensen> to me, and only to me, all these sound like minor edge cases, and I have no qualms with encryption on root by default
<elvishjerricco> I just default to not using the root dataset for ANYTHING because it makes the pool less flexible
<elvishjerricco> Again, only properties I set are `compression=lz4` and `mountpoint=none`
<gchristensen> same
<clever> elvishjerricco: i also turn on snapshots
<elvishjerricco> clever: I don't even do that for the root dataset, only my "real" root child. This is because I have stuff like `/tmp` in their own dataset outside the "real" root
<clever> elvishjerricco: i prefer to have snapshots on by default, and opt-out for things like /tmp/
<elvishjerricco> clever: How do you opt out? What snapshot system do you use?
<clever> so any new dataset gets snapshots without having to think
<clever> elvishjerricco: the one in nixos, services.zfs.autoSnapshot.enable
<__monty__> joepie91: How strict are your size constraints?
<joepie91> __monty__: strict
<clever> elvishjerricco: it only snapshots datasets with com.sun:auto-snapshot=true set on them
<clever> elvishjerricco: so if you =true the root, all others inherit that prop
<joepie91> __monty__: there is a fixed amount of space between the shelf and the desk top
<clever> elvishjerricco: but you can also just =false the same prop on any child to opt-out
<joepie91> and a fixed footprint of the shelf itself
<elvishjerricco> clever: I uses znapzend and there's no way to opt out. With recursive mode I'm pretty sure it always does every child
<__monty__> joepie91: Not a couple cm of wiggle room?
<joepie91> __monty__: nope
<clever> elvishjerricco: sounds like znapzend needs better config
<joepie91> hence the challenge :)
<elvishjerricco> clever: Definitely. Its configuration is honestly quite bad :P
<clever> elvishjerricco: id prefer to have something that can work from the snapshots services.zfs.autoSnapshot is already creating, and it can always make a bookmark for each thing it sends
<elvishjerricco> gchristensen: One real world case where encryption settings need changing: By default, ccm is used instead of gcm, but gcm is much better.
<clever> elvishjerricco: you can also use a bookmark for an incremental send, and bookmarks have less storage overhead
<elvishjerricco> clever: Does autoSnapshot support replication?
<gchristensen> elvishjerricco: ah cool (btw -- the default is ccm now)
<elvishjerricco> Or do you need something else like syncoid?
<MichaelRaskin> joepie91: nice writeup, thanks. joepie91++
<{^_^}> joepie91's karma got increased to 12
<__monty__> I've heard cryptographers who were pretty wary of GCM>
<clever> elvishjerricco: it doesnt really have that option, that i can see, but nothing stops you from leeching off the snapshots it already made, and just doing an incremental send between 2 of them
<gchristensen> https://nixos.wiki/wiki/NixOS_on_ZFS has copy-pasted gcm though, and is why I say docs should always say "=on" if there is a "turn on the currently-thought-to-be-best" option "
<gchristensen> oh oops I got it backwards
<elvishjerricco> gchristensen: Well ccm is the default currently, but in future versions it will be gcm because it's much much faster and the ZFS people seem to think it's basically as secure
<gchristensen> "Unless you have any special requirements, either would be fine. Both modes are approved by NIST."
<elvishjerricco> __monty__: Let me find the PR where they changed it... there was some discussion about the security of it
<gchristensen> "GCM should be considered superior to CCM for most applications that require authenticated encryption. Because of the authentication that happens, GCM is not susceptible to the bit flipping and other attacks that can be mounted against counter mode or other stream modes."
<__monty__> Though NIST also came up with some curves : /
<MichaelRaskin> If only it was _them_ who came up with the curves!
<clever> elvishjerricco: from what i understand, every change to zfs has a transaction# of when that change occured (auto-increment, within a dataset)
<joepie91> MichaelRaskin: __monty__: for more context, this is my current parts list: https://tweakers.net/gallery/303320/wenslijst/?wish_id=2313576
<joepie91> where the price of the case looks kind of hilarious compared to the price of everything else, lol
<joepie91> lol
<clever> elvishjerricco: bookmarks and snapshots both just record the current transaction#
<elvishjerricco> clever: Yea, bookmarks are really nice for incremental backups
<clever> elvishjerricco: and snapshots also stop garbage collection from deleting things
<elvishjerricco> Only requires the latest snapshot instead of the latest two
<gchristensen> can't wait for znapzend to use bookmarks for sends :(
<clever> elvishjerricco: `zfs diff` and incremental sends, then just scan the entire dataset, for any block changed after a given transaction#
<MichaelRaskin> joepie91: I cannot get around to trying to repair my GB-BRIX… fitting space constraints is nice.
<clever> elvishjerricco: so you could have a util, that copies a given snapshot into a bookmark, then does incremental send between the last-sent and new bookmark
<__monty__> joepie91: : ( Ran into tweakers' annoying cookie dialog again.
<clever> elvishjerricco: and then let it leech off the snapshots services.zfs.autoSnapshot is already making
<clever> elvishjerricco: and it should continue to work, even if you manually go in and nuke half the snapshots
<joepie91> MichaelRaskin: that looks like a tetris nightmare, heh
<elvishjerricco> clever: Eh, znapzend works... well enough :P What I really want to do is make my own snapshot/replication service :P
endformationage has joined #nixos-chat
<elvishjerricco> Or I'd use sanoid/syncoid if syncoid would support older backup histories on the destination....
<MichaelRaskin> Nah, the problem is that one RAM slot apparently has soldering of the contacts give up
<elvishjerricco> __monty__: Here's the PR where they changed to GCM by default https://github.com/openzfs/zfs/pull/9749
<clever> elvishjerricco: yeah, i also want to make my own system
<{^_^}> openzfs/zfs#9749 (by AttilaFueloep, 21 weeks ago, merged): ICP: Improve AES-GCM performance
* joepie91 uploaded an image: Selection_999(078).png (93KB) < https://pixie.town/_matrix/media/r0/download/pixie.town/IzxooLFuPxRnBnycEWPZArea >
<joepie91> guess I'll be buying from sicomputers
<MichaelRaskin> And, well, I am bad at soldering. Maybe some hot-air re-melting could be done…
<MichaelRaskin> Heh.
<MichaelRaskin> Frankly, case costing 10% of CPU does not look completely unproportionally cheap
<MichaelRaskin> Hm, does PSU come with the case?
<MichaelRaskin> Because case does not specify wattage, and there is no separate position…
<gchristensen> unanticipated problem: when sway crashes, I have a ton of frozen cgroups which don't get cleaned up and then stuff is broken, like slack and firefox know they're already running but can't do anything about it.
<elvishjerricco> Looks like GCM has some minor theoretical vulnerabilities if you truncate the MAC. But ZFS does not truncate the MAC and there are no known issues with this method. However, CCM was chosen as default originally simply as a precaution. https://github.com/openzfs/zfs/pull/9749#issuecomment-570065780
<MichaelRaskin> gchristensen: just SIGCONT everything?
<gchristensen> even after unfreezing (I'm using cgroup.freeze instead of sigstop/sigcont now) it stays alive
<MichaelRaskin> And doesn't notice it's display server is missing in action?
<clever> elvishjerricco: what would you say if somebody was to use only a MAC as a fork of DRM to ensure only authorized binaries run?
<gchristensen> yeah pretty much
<MichaelRaskin> Cleanly designed interaction between applications and the server, they said
<elvishjerricco> clever: Doesn't that basically achieve what Apple-style code-signing achieves?
<__monty__> Isn't that the inverse of DRM, clever?
<elvishjerricco> but with extra steps :P
<MichaelRaskin> Shouldn't there be a socket connection that is broken and thus the applications crash on sigpipe?
<clever> __monty__: exactly :P
<clever> elvishjerricco: for more context, the rpi4 firmware is signed with an hmac-sha1, and i'm wondering if defeating that even counts as a violation of something like dmca and whatnot
<gchristensen> MichaelRaskin: not sure, I'll take a deeper look next time sway crashes (today it crashed during a meeting in which I had to take notes for legal duties as secretary :'))
<__monty__> Doesn't that only apply to distribution?
<elvishjerricco> clever: That's an interesting point.... I don't really know nearly enough about dmca
<MichaelRaskin> Strategic choice of time to crash!
<clever> elvishjerricco: and the email in this screenshot, claims its required for "safety certificates" .....
<elvishjerricco> clever: What on earth do they mean by "safety"?
<clever> elvishjerricco: exactly
<elvishjerricco> Regardless, codesigned firmware isn't exactly unusual practice. A bit surprised to see it on the pi though
<clever> elvishjerricco: my theory, is that a partially flashed SPI will result in garbage code getting ran on bootup
<clever> elvishjerricco: and they wanted an integrity check, to detect coruption
<clever> elvishjerricco: but the mask rom only has hmac-sha1 support, not checksums
<clever> and they never had this problem on past models, because SD cards are "more reliable" lol
<elvishjerricco> clever: Oof
<elvishjerricco> clever: What could this "second stage boot code" do wrong that start.elf couldn't?
<elvishjerricco> Is it just hardware initialization stuff?
<clever> elvishjerricco: i think its more, that a corrupt start4.elf would be detected by the elf headers not agreeing with other things
<clever> elvishjerricco: and they can always patch the bootcode.bin stage to do more checks if certain corruptions are detected
<clever> elvishjerricco: but the mask rom cant be patched, so there is only one protection they can enable
<elvishjerricco> Interesting...
<clever> elvishjerricco: bootcode.bin (prior to hmac-sha1 being on) had zero validation
<clever> elvishjerricco: just copy a blob into ram, and jmp to it
cole-h_ has joined #nixos-chat
<clever> elvishjerricco: for the rpi 1-3, the mask rom can boot from nand flash, spi, sd, and usb-device i believe
cole-h_ has quit [Client Quit]
<clever> elvishjerricco: around the 2 or 3 (not sure), they also added usb-host, with both mass-storage and ethernet support
<clever> elvishjerricco: the rpi4 completely changed both the usb and ethernet interfaces, so that support was removed, and the nand flash is also gone as well
<clever> elvishjerricco: so the rpi4 can only boot from 3 places, SD, SPI, usb-device
<elvishjerricco> clever: Wonder why they changed it like that
<clever> elvishjerricco: the whole rpi 1-3 era, also has a special "bootcode.bin only" mode
<clever> elvishjerricco: if you put only bootcode.bin and no other config files or firmware onto the SD, then you can get netboot support, even on an rpi1
<clever> elvishjerricco: my theory, is that they just made that the official way to boot the rpi4, bootcode.bin now lives on the SPI instead
<clever> elvishjerricco: and they can reflash it in the field, to add more features, like ethernet and usb-host booting
<clever> elvishjerricco: so they dont have to deal with bugs in the mask rom that need a whole new unit
<elvishjerricco> clever: Side note, I remember hearing that rpi was often too slow to get a usb disk running to be able to boot off it
<elvishjerricco> Is that fixed with the 4?
cjpbirkbeck has joined #nixos-chat
<clever> elvishjerricco: for the rpi3, there was a flag you could set in the OTP memory, to make it wait longer
<clever> elvishjerricco: for the rpi4, there is a whole bootconf.txt in the SPI, that lets you set things in a much cleaner manner
<elvishjerricco> clever: But it's still essentially a timeout?
<clever> elvishjerricco: i believe so
<elvishjerricco> clever: Wasn't their a uefi implementation for the pi at one point that handled this better?
<clever> elvishjerricco: there is a tianocore implementation, but its basically just a kernel.img that the closed-firmware has to first execute
<clever> elvishjerricco: so you must put the tianocore kernel.img somewhere that the firmware can still boot from
<clever> and the rpi cant even boot that until it finds start(4).elf first
<clever> and the rpi4 doesnt support usb boot yet (being release in about a week for testing)
<elvishjerricco> Sure. Still sounds useful
<clever> so you need start4.elf and a tianocore kernel.img on the SD card
<elvishjerricco> Put uefi on sd card, use it for booting whatever else you want
<clever> yep
<{^_^}> raspberrypi/rpi-eeprom#95 (by cleverca22, 12 weeks ago, open): SPI boot
<elvishjerricco> Probably more reliable than any firmware they'll release
<clever> this issue, is asking to add support for loading start4.elf and kernel.img from SPI
<clever> you could then put it on a hat
<clever> and not deal with SD at all
<elvishjerricco> Yea that'd be nice
<clever> also of note, the bootup process is a lot more complex now
<clever> elvishjerricco: for the rpi 1-3, bootcode.bin just needs to bring the lpddr2 controller online, and this source is enough to do that
<clever> elvishjerricco: once the ram is online, you can basically forget about the controller and it keeps working
<clever> elvishjerricco: but, the rpi4...
<clever> elvishjerricco: this is a file-listing for the SPI firmware
<clever> elvishjerricco: memsys??.bin, are firmware for the ddr4 controller, which has its own dedicated cpu core....
<elvishjerricco> Geez
<elvishjerricco> I guess that awesome cpu upgrade came with a lot of strings attached
<clever> elvishjerricco: and for extra fun, the strings inside memsys??.bin are all scrambled
<clever> after studying it, i figured out that its a byte-order problem
<clever> the VPU running bootcode.bin is little-endian, and is treating memsys??.bin as a dumb array of uint32_t's
<clever> it grabs each 4 byte chunk, then shoves it into a 4byte wide fifo (one of the MMIO registers)
<elvishjerricco> Lol what a hack
<clever> the 4 bytes then get copied into the ddr4 controller ram
<clever> except, the bytes get flipped in the process
<elvishjerricco> Yea
<elvishjerricco> Endianness, man. It'll getcha
<clever> and to save time at bootup, they pre-flipped them in the file
<clever> so the second flip, unflips it
<elvishjerricco> They probably should've just found a way to flip them in the build system :P
<clever> i think thats what they did
<clever> the blobs in the SPI image, are pre-flipped
<elvishjerricco> Ohhh you were talking about the binary not the source
<clever> so when the LE cpu reads it as 32bit chunks and flips again, it comes out correct
<elvishjerricco> That makes enough sense
<clever> elvishjerricco: i have ported LK over to the rpi4 vpu, and i confirm it runs at 3 of the 4 places, and will likely work in the 4th as well
<clever> you can either compile it as a bootcode.bin, sign it with the extracted keys, and then boot it via 1 of 3 methods:
<clever> recovery.bin on an SD (confirmed to work)
<clever> a tagged blob in the SPI (not yet tested, but likely works)
<clever> or push it over usb, with the compute-module tools
<clever> you can also compile it to a start4.elf, and let the official SPI bootcode.bin load it
<elvishjerricco> So it's still a reasonably hackable little board at the firmware level then
<clever> yep, once you extract the hmac-sha1 keys
<clever> which they may not want you sharing...
<clever> if you dont have the keys, you must start at start4.elf, which is unsigned
<elvishjerricco> clever: I'm a little fuzzy on how hmac-sha1 actually works... Did they actually publish private keys? Or is that not how hmac's work?
<clever> hmac-sha1 is a symetric signature, the same key is used for both signing and validation
<elvishjerricco> Ah
<__monty__> It's a MAC, not a signature.
<elvishjerricco> Oh got it
<clever> on the rpi4 specifically, there is a constant key in the mask rom
<clever> and then a "per device" key in the OTP
<clever> and the 2 keys get xor'd together, to make the real key used for hmac-sha1
<elvishjerricco> So then the hmac really is just for corruption detection, not any kind of code signing.
<clever> the original roku2 used it as the key for the entire device security (it used the exact same chip as the rpi1)
<clever> and assuming you never get execute on the chip, you cant know the key, so you cant sign custom firmware
<clever> and every stage validates the next
<clever> a buffer overflow exploit in a debug UI leads to temporary root, where you can then recover the keys, patch the sig-checks out of things, and re-sign them
<clever> the rpi4 is worse in that respect, it uses the same "per device" key on every device, lol
<clever> thats the only way to have one recovery.bin unlock every board
<clever> just think of the support nightmare you would have, if you needed to lookup the serial# and give them a unique recovery.bin
<clever> and how do you even get the serial# if its not booting?
<elvishjerricco> Lol that's a little silly, but alright
<clever> they clearly choose to opt-out on security, as much as the mask rom would allow
<clever> root@raspberrypi:~# vcgencmd otp_dump
<clever> 18:000008b0
<clever> 19:ffffffff
<clever> elvishjerricco: if you ask the firmware to dump the OTP, there is a fishy block of 8 censored registers
<clever> that would be the per-device key
<elvishjerricco> clever: What's the point of doing that?
<clever> elvishjerricco: the OTP hw isnt documented, so "nobody can read it"
<clever> elvishjerricco: compile LK to a start4.elf, boot it, run `otp_dump_all`, and you have the per-device half of the key...
<clever> did i say "nobody"? i meant everybody :P
<elvishjerricco> Lol
<elvishjerricco> wow
<elvishjerricco> I guess maybe they just want to be able to change that sort of stuff in future hw revisions without breaking anything?
<clever> but you still need to know the constant half of the key in the mask rom
<clever> which requires you to RE the mask rom
<clever> also, i have been told that there is already a rev2 of the rpi4 mask rom, with proper RSA signature support
<clever> full pub/priv key signatures
slack1256 has joined #nixos-chat
<clever> but thats not enabled on the units being sold
<clever> elvishjerricco: as for how the OTP works, its basially 64-ish registers, of 32bits each, where you can turn any 0 bit into a 1 bit
<clever> its probably some sort of fuse system i'm guessing, where you can just blow some weak traces by putting too much power thru them
<clever> and then test if its blown to read
<elvishjerricco> I feel silly.
<clever> ?
<elvishjerricco> The reason I used znapzend instead of sanoid/syncoid was because I didn't think I could keep an older history on the backup destination
<elvishjerricco> I can just run sanoid on the destination as well to keep older backups
<clever> ah
<elvishjerricco> -_-
<elvishjerricco> And now I want to migrate from znapzend, but that sounds like a massive pain
<clever> elvishjerricco: also, you dont even need to recovery the mask rom half of the key!
<elvishjerricco> clever: Why is that?
<clever> elvishjerricco: all hmac's are done by just xor'ing the key with a repeating 0x36, then doing hash(thatbuffer + payload)
<clever> then you xor the same original key with a repeating 0x5c, and do hash(2ndbuffer + 1sthash)
<clever> the mask rom left 2ndbuffer in ram
<clever> so, you can just recover the result of `xor(key, 0x5c5c5c5c...)`
<elvishjerricco> Ahh
<clever> and if you know how to undo an xor of 0x5c5c....
<ashkitten> just by xoring it again?
<clever> ashkitten: exactly!
<cole-h> lovesegfault: I have started my NixOS journey.
<clever> elvishjerricco: so, you could just boot a start4.elf file, and dump a ~20 byte range of ram
slack1256 has quit [Remote host closed the connection]
slack1256 has joined #nixos-chat
<clever> elvishjerricco: ive not given you the key, ive just given directions, and the rpi4 will create the key on power-up (it creates the key on every powerup)
<ashkitten> what's the context of this, btw?
<clever> ashkitten: the rpi4 boot firmware is signed
<clever> so if you want to run a custom recovery.bin file, you need this key to sign your own image
cole-h_ has joined #nixos-chat
<drakonis> this is an interesting thing
<drakonis> federated git hosting
<ashkitten> it doesn't mention federation at all in the faq
<ashkitten> the title is the only thing that mentions it?
<ashkitten> there's an actual git federation working group thing i think called forgefed but they've hopped between so many different places on the internet i couldn't tell you where to find them now
<ashkitten> it's legitimately astounding and they need to set up a website if they're still around because it's impossible to find where they're actually still talking
<ashkitten> correction: i found their website, it was very difficult to find. https://forgefed.peers.community/
<risson> Is there a stable implementation?
<risson> It looks like the only two mentionned on their website are for testing and/or demo
<ashkitten> i don't know
<ashkitten> you have exactly as much info as me
<drakonis> https://git.mysticmode.org/r/sorcia the instance
cole-h_ has quit [Quit: Goodbye]
parsley936 has quit [Remote host closed the connection]
parsley936 has joined #nixos-chat
<lovesegfault> cole-h: yuuuuus
slack1256 has quit [Ping timeout: 260 seconds]
<cole-h> lovesegfault: Could you walk me through how you set up your system? e.g. you clone nix-config somewhere... then what?
<cole-h> s/system/system(s)/
<lovesegfault> For my laptop:
<lovesegfault> 1. clone nix-config
<lovesegfault> 2. nix-shell
<lovesegfault> 3. morph deploy deployment.nix boot --on localhost
<lovesegfault> 4. reboot
<lovesegfault> on any other box
<lovesegfault> 1. morph deploy deployment.nix boot --on $machine --reboot (done from my laptop)
<__monty__> lovesegfault: After installing nix on the box, right? Or nixos rather.
<cole-h> OK, cool. First I need to get a gpg-agent running so I can pull down my configs... lol
<gchristensen> I think I want to detect a floating window and make it prevent freezing...
<lovesegfault> __monty__: correct, there's no bootstrapping done
<lovesegfault> One nixops closes a couple more PRs then I'll use that and it can bootstrap IIRC
<lovesegfault> *Once
<__monty__> Really? Sweet.
<samueldr> gchristensen: do you know what would be great? somehow being able to "swap out" a process group into a fresh swapfile up until it's thawed back
<gchristensen> oh so it could be launched _much_ later?
<gchristensen> or more so it is taking up 0 resources while it is frozen
<samueldr> yep
<samueldr> I'm thinking that it would be helpful in a situation where RAM is somewhat limited, like some of the phones for Mobile NixOS
<gchristensen> yeah that is a very cool idea
* samueldr is nerd-aiming the nerd-snipe
<samueldr> or even lower-end laptops could become more useful
* gchristensen reads up about memory-related properties
<gchristensen> the painful thing about the current behavior is I can't put on a background youtube video and read man pages
<samueldr> imagine being able to just get a chromebook with 4GB of ram and it being even more usable
<samueldr> yeah
<colemickens> cole-h: oh god is it finally happening!?
<MichaelRaskin> gchristensen: make an infinitisemal split frame for youtube?
<cole-h> colemickens: :DDDDD
<cole-h> Currently struggling through the GPG-SSH-TTY combo to get my hm stuff
<colemickens> also, reading scrollback, is sanoid/syncoid > znapzend a popular opinion? zfs backups are near the top of my nix todo list
<colemickens> cole-h: I tend to cheat and bootstrap with an already git-crypt-unlocked `nixcfg` repo.
<gchristensen> MichaelRaskin: under the current rules, unless it is in focus, it is frozen
<cole-h> >:( I copied over my gpg stuff and I'm still getting permission denied
<MichaelRaskin> Boring people, for whom the notion of current focus always have a single window
<MichaelRaskin> (I have keyboard focus independent of mouse and sometimes use and abuse that)
<infinisil> colemickens: I'm not very happy with znapzend, have been meaning to try out {san,sync}oid
<colemickens> I was rather surprised at how few results, random scripts, etc I found when looking for info on encrypted incremental remote zfs backups.
<__monty__> Encrypted, incremental, zfs, pick two?
<colemickens> Doesn't have to be, if I understand correctly.
<gchristensen> samueldr: it doesn't look like you can set a swapfile per process
<__monty__> In theory.
<samueldr> I kinda assumed so, I didn't remember seeing something like that in the options
bqv has joined #nixos-chat
<samueldr> can a process' memory be asked to be pushed to swap? it wouldn't be a per-group swap, but a swapfile could be made larger (or a new one) to hold it
<gchristensen> I think so, looking at that ... (I don'thave swap enabled right now, so not sure)
<samueldr> oh, neat
<samueldr> >> A value of "none" indicates that
<samueldr> this cgroup should never swap
<gchristensen> that patch never merged
<samueldr> yeah
<samueldr> this could be nice to put something like the WM in
<gchristensen> yeah
<gchristensen> you can set swappiness per cgroup
<gchristensen> you could set swappiness to a very high number on freeze
<gchristensen> might be easiest
<samueldr> right
<gchristensen> increase the number based on how long it has been since it was used (looking at my phone, I have apps unused in weeks)
<samueldr> I'm thinking that a more involved tool for that could track things like a stack of groups
<gchristensen> yea
<samueldr> what's deeper in the stack gets more and more frozen
<cole-h> Aha, just needed to reboot :D
<cole-h> gchristensen: Curious: do you administer your local systems with nixops?
<gchristensen> no
<__monty__> gchristensen: Haven't run into background compiles getting paused?
<gchristensen> wait, yes
<gchristensen> just not my laptop
<gchristensen> __monty__: yeah that is annoying
<cole-h> I'm thinking I want to do something similar to what lovesegfault is doing -- needing only to clone to bootstrap a system...
<__monty__> Nix commands are another candidate for things I'd like to run in the background.
<adisbladis> I do
<cole-h> But then I'll have to completely restructure my everything
<adisbladis> Hmm, gchristensen
<adisbladis> That's a good case for non-ssh transports
<gchristensen> oh no
<lovesegfault> cole-h: My setup is pretty clean, the only thing I don't handle well are secrets
<gchristensen> adisbladis: yeah good point
* joepie91 uploaded an image: Selection_999(080).png (101KB) < https://pixie.town/_matrix/media/r0/download/pixie.town/MiJekJrtRiwRutjCztuzphku >
* joepie91 uploaded an image: Selection_999(081).png (91KB) < https://pixie.town/_matrix/media/r0/download/pixie.town/FWRTZMUibEBEMTmwTNyDaEST >
<cole-h> lovesegfault: I'd be surprised if anybody handles secrets well :P
<joepie91> :(
<gchristensen> looking nice joepie91
<cole-h> lovesegfault: So to use hm as a nixos module, do you basically replace home.nix with `home-manager.users.<username> = { pkgs, config, ...}:` in the configuration.nix?
<joepie91> gchristensen: yeah, so expensive though :P
<joepie91> gchristensen: anyway with a lot of luck it'll all arrive tomorrow
<joepie91> one of the shops at least already managed to ship my order within 9 minutes of placing it, so that's a good start
<joepie91> the other claims to deliver tomorrow evening, buuuuut we'll see
<__monty__> cole-h: Yeah, though I keep the home.nix, import it. And you *do* need to disable at least one HM setting.
<adisbladis> joepie91: I used to work for a big online electronics shop. We could accomplish delivery <1h on occasion
<lovesegfault> curl | kexec
<lovesegfault> AWWWWW YESSS BABY
<lovesegfault> cole-h: pretty much
<joepie91> adisbladis: oh yeah I don't doubt that that's normally possible, BUT coronavirus and overloaded postal services :P
<adisbladis> joepie91: That wasn't normally done :P
<joepie91> lol
<adisbladis> Pretty much only for big clients that needed things urgently, most of the time it was done for the military
<joepie91> the fastest 'normal' option here is same-day
<joepie91> only a few stores offer it
<joepie91> order before 13:00, get it that evening
<joepie91> adisbladis: ah yeah I can imagine that being a special case :P
<adisbladis> The military orders were always weird :P
<joepie91> but this is just a boring consumer order
<adisbladis> "
<adisbladis> "We need this weirdo custom rackmounted server and we need 1500 of them stat"
<adisbladis> With super strange requirements because they are going into APCs and stuff like that
<joepie91> lol
<joepie91> "make it happen"
<cole-h> __monty__: At least one HM setting? The `home-manager.*` ones, right?
<joepie91> I assume the "I don't care what it costs" label was attached also?
<__monty__> cole-h: I think the one whether home-manager manages itself.
<adisbladis> joepie91: Nope. Most of the time they got really good pricing by default anyway.
<joepie91> ouch
<cole-h> and __monty__ just importing that is a pretty good idea... Does that just become `home-manager.users.<user> = import path/to/home.nix`?
<__monty__> cole-h: Yep.
<__monty__> cole-h: It's programs.home-manager.enable = false; I think.
<lovesegfault> samueldr: do you have a mental model of how to add support for a new SBC in NixOS/
<lovesegfault> *?
<lovesegfault> Just looking for a "rough" flowchart
<samueldr> kind of, though the first step is probably "get anything booting"
<lovesegfault> (cc. flokli who's annoying me to do that instead of fiddling with poopbuntu)
<lovesegfault> Guess I gotta learn how to flash this thing then
<samueldr> then from there I have sane assumptions I can make, like using the same kernel sources + config to make what should be a bootable kernel
<samueldr> that'll help :)
<samueldr> maybe look up how to boot from SD or USB
<lovesegfault> IIRC it doesn't support that
<samueldr> and validate you do boot from SD or USB
* lovesegfault goes look
<lovesegfault> Oh, it does
<lovesegfault> nice
<samueldr> cboot does yeah
<samueldr> it looks like it should be possible from RCM too
<lovesegfault> I think I just need an AArch64 kernel flashed to a bootable USB with /boot/extlinux
<samueldr> maybe look into how linux boots on the nintendo switch for rcm tooling?
<lovesegfault> define rcm?
<samueldr> https://docs.nvidia.com/jetson/archives/l4t-archived/l4t-3231/index.html#page/Tegra%20Linux%20Driver%20Package%20Development%20Guide/bootflow_jetson_xavier.html
<samueldr> >> The RCM boot flow is similar to a cold boot except that the binaries are transferred from the host over USB and loaded directly to SDRAM. TOS and BPMP-FW are not loaded in this path.
<lovesegfault> :O
<samueldr> early switches abuses a bug in the CPU silicon and that boot mode
<samueldr> not sure if it's any help for you though
<lovesegfault> I think I'll try just using extlinux-based boot
<lovesegfault> and see what happens
* samueldr should take some time adding nintendo-hac to a non-mainline mobile-nixos repo
<samueldr> yeah, probably easier
<lovesegfault> interesting
<lovesegfault> oh my that's a big URL
<__monty__> lovesegfault: Oh, let me know how it goes. Have always had a penchant for syslinux over grub. Haven't tried it with nixos though, I assume it doesn't allow you to boot into older generations yet?
<samueldr> that's not syslinux though
<samueldr> it's the exlinux.conf format with another implementation
<lovesegfault> it's nvidia c-boot
<lovesegfault> the c stands for cursed
<__monty__> Oh : (
<pie_> still better than cant
<lovesegfault> Alright, serial is up and running
<ekleog> lovesegfault: to answer your question: we're sunday, people don't do delivery on sundays :p
__monty__ has quit [Quit: nn]
* lovesegfault looks at the 4 boxes that got delivered today and stares at ekleog
<ekleog> Welp. So anyway, I asked UPS to try to actually deliver the box to me on friday and haven't received any news since
<ekleog> them just dropping the box at the pick-up location without even trying to deliver it is… :(
<ekleog> “we've tried to deliver it and you weren't there” WELL no that's not true
<ekleog> (unless they came outside of the business hours of both my roommate and me, and we do most of the clock with the two of us :p)
<lovesegfault> ekleog: I used to have to trap the UPS truck to get my packages
<lovesegfault> the guy would just drive by and mark as if I wasn't home
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-chat
<aleph-> Yeah UPS is actually good in my area
<aleph-> Somehow
<colemickens> cole-h: no more i3status-rust blocking updates! https://builds.sr.ht/~colemickens/job/211085 shows i3status-rust updating and it's cargoSha256 getting updated too! credit goes to msteen for `nix-prefetch`.
<cole-h> <3 colemickens <3 ottidmes
<{^_^}> colemickens's karma got increased to 24
<{^_^}> ottidmes's karma got increased to 37
<ottidmes> colemickens: Makes me happy to see it being used :)
<colemickens> well, it should've worked. and worked locally. in fact, it works again locally, not sure why it failed in that build.
<colemickens> ottidmes: wait, are you msteen?
<ottidmes> I am
<colemickens> aha! well thank you :)
<gchristensen> samueldr: I'm not finding if there is a way to say "only allow Nmb of active ram, and push the rest to swap"
<samueldr> you're still looking into that? :o
<samueldr> I mean, it's perfectly cromulent to let the system swap it out whenever it would, rather than force it
<samueldr> since on thaw it would be quicker not to read from swap
<ottidmes> colemickens: I am working on a newer version, slowly, removing allow-unsafe-native-code-during-evaluation and allow dashification of arguments, e.g. --show-urls instead of --showURLs, and I am trying to find a better way to overlay nixpkgs than the current workaround
<gchristensen> I agree. no, I took at least an hour for a call :)
<danderson> right, I need to clean up my nixos configs, and investigate this newfangled nixops I hear so much about
<danderson> anyone know if the nixops with all the new things is in unstable? Or is it all still in the form of PRs?
<gchristensen> newfangled nixops isn't ready yet :P still being newfangled
<gchristensen> unpackaged since it reallyreally isn't ready
<danderson> I mean, I'm going to try it in a low-stakes environment, but just the state backend stuff might unblock my personal use
<danderson> ah, oh well then :(
<gchristensen> state backends aren't merged yet
<gchristensen> coming, though :)
drakonis_ has quit [Ping timeout: 260 seconds]
<danderson> okay, well, I guess that project's on ice then :(
<danderson> Happy to be an alpha tester when there's something to show! I have sacrificial machines both at home and work that I can play with
<cole-h> gchristensen: btw, with finals over, you and adisbladis might just see my beautiful face on Friday (or whenever the next meeting I can attend is) ;^)
<gchristensen> cool :)
<gchristensen> w00t!
<gchristensen> danderson: Soon™!
<joepie91> tonight: a new NixOS deployment!
<joepie91> (NAS)
<cole-h> The only unknown is whether I will be on NixOS, or whether I'm on my Arch machine, still trying to figure out my NixOS stuff :P
<infinisil> Took me a while to feel at home on NixOS
<infinisil> Though I switched from macOS, so that's quite the difference
<cole-h> tbh I already feel right at home
<cole-h> Aside from needing to learn the new nixos-* commands
<cole-h> h-m was a pretty good introduction, tbqh
<infinisil> Nice :D
drakonis_ has joined #nixos-chat
<danderson> gchristensen: I hope! From what I've been snooping on the nixops channel, it's shaping up to something I can sell to my coworkers
<cole-h> I think my only pain point is wanting to suspend a nix-build (or other long-running nix* command) and that not freezing the underlying build process(es)
<danderson> and finally stop hand-feeding ubuntu installs
<infinisil> cole-h: Oh that would be nice
<colemickens> I asked in officehours, but can someone please confirm the zoom meetings are joinable from the web client? :(
<infinisil> I wonder if this could be implemented to work
<cole-h> I wonder if one could use an idea similar to gchristensen's recent experimentation with systemd scopes (but maybe in an init-agnostic way?)
<cole-h> So all the processes would be a part of that scope (or cgroup or whatever) would freeze once the parent (nix-build and friends) was SIGSTOP'd
<cole-h> and omg I must have misconfigured my h-m because now that I'm on NixOS I can build 4 things at the same time, instead of just 1!
parsley936 has quit [Read error: Connection reset by peer]
<infinisil> I guess freezing nix-build processes would be a bit more complicated, because multiple people might be building the same thing via the daemon
<infinisil> So technically freezing should only occur if all users have issues freezing
<infinisil> Oh yeah and process trees hm
<cole-h> If they're building the same thing via daemon, would that be under the same build user?
<MichaelRaskin> colemickens: yes they are
<MichaelRaskin> You need to press «your app is broken» like three times in a row
<MichaelRaskin> (and chromium-only)
<colemickens> Thanks for confirming!
<cole-h> RIP, nixpkgs-mozilla's nightly-bin is busted -- the .checksums file 404s :(
<colemickens> cole-h: their update isn't totally atomic https://github.com/mozilla/nixpkgs-mozilla/issues/186
<{^_^}> mozilla/nixpkgs-mozilla#186 (by colemickens, 45 weeks ago, open): firefox-nightly broken: checksums missing for x86-64
<cole-h> Heh