gchristensen changed the topic of #nixos-chat to: NixOS but much less topical || https://logs.nix.samueldr.com/nixos-chat
<elvishjerricco> iPad Pro is pretty good. Got one today with the keyboard case. I feel dirty continuing to use non free operating systems, but man it’s good quality stuff.
drakonis has quit [Ping timeout: 248 seconds]
<samueldr> :( their ARM hardware seems fine, except for the fact that you don't "own" the boot flow
<samueldr> hm, the twitter saga intensifies: they banned their own tokens from auth flows other than their custom new one for their new APIs, so no new user session tokens can be attributed that way with heightened rights :(
Synthetica has quit [Quit: Connection closed for inactivity]
endformationage has quit [Ping timeout: 248 seconds]
endformationage has joined #nixos-chat
drakonis has joined #nixos-chat
<drakonis> systemd grew a dependency on varlink now
<samueldr> are you sure?
<clever> varlink?
<drakonis> samueldr: yes
<drakonis> clever: its a ipc mechanism
<drakonis> userland ipc i suppose
<clever> ah
<drakonis> its going to improve systemd.
<drakonis> brb
drakonis has quit [Quit: WeeChat 2.4]
drakonis has joined #nixos-chat
<drakonis> a decent ipc mechanism will be welcome
drakonis_ has joined #nixos-chat
drakonis_ has quit [Read error: Connection reset by peer]
buckley310 has joined #nixos-chat
<colemickens> Built system. Updated 'wlroots'. Rebuild system, needs to rebuild NM?
tdeo has quit [Quit: Quit]
endformationage has quit [Ping timeout: 244 seconds]
<emily> colemickens: just wanted to say thanks for maintaining nixpkgs-wayland btw, been happily using it for months now ^^
<colemickens> emily: that's quite nice to hear, thanks!
Jackneill has joined #nixos-chat
jasongrossman has joined #nixos-chat
<eyJhb> I really can't seem to figure out, how I can give ca-cert as a byte array (DER blob)... ANy ideas? - https://people.freedesktop.org/~lkundrak/nm-docs/nm-settings.html
drakonis has quit [Ping timeout: 272 seconds]
drakonis has joined #nixos-chat
Synthetica has joined #nixos-chat
__monty__ has joined #nixos-chat
<pie__> selfsymmetric-mu you do particle physics?
<eyJhb> pie__ are you out stalking?
<pie__> eyJhb, "no", "im always stalking", other
<pie__> take your pick
<eyJhb> Always stalking?
<pie__> oh no
<eyJhb> Ever done blind SQLi by hand?
<eyJhb> Or.. Manually scripted
<pie__> k...kind of
<pie__> i mean
<pie__> wuh
<gchristensen> what is the `i`? injection?
<pie__> i did the checking if it works by hand and then i wrote a binary search...
<eyJhb> Yeah, SQL Injection :)
<gchristensen> sure
<eyJhb> I have another challenge in-the-making, which is SQLi in a binary. Which most people never check for :p
<gchristensen> that is true
<gchristensen> most people think it is limited to HTTP things :P
<eyJhb> Actually kind of a nice challenge! - Precisely! And that is what I want to change a little :D
<eyJhb> Because it is everywhere
<eyJhb> It is actually quite fun. When done you (anyone interested), could try to pwn it :p
<eyJhb> btw. gchristensen it is possible to create a r/o root owned file, using *nix easily? Thinking if I can use it as my certificate file
<gchristensen> do you want it to be only readable by root?
<eyJhb> Yeah, or... That would just be `nice`, but basically, only readable by root, meaning no users have access to it
<gchristensen> well with Nix everything is readable by everybody
<eyJhb> writeTextFile doesn't seem to include this
<eyJhb> Yeah, guesing I will stick to that anyways
<eyJhb> Does it `return` the file location? Or how would I be able to use it as a path?
<gchristensen> I don't follow
<gchristensen> you should not put secrets in to Nix
<eyJhb> No no, I remembered that it really doesn't matter, as it is a public certificate
<gchristensen> ahh okay
<eyJhb> Basically available here - http://ca.wifi.aau.dk/ .. Served over.. http
<eyJhb> This hurts
<gchristensen> yes, writeTextFile would be fine
<eyJhb> but can I use it as `mypath = writeTextFile(..)` ?
<gchristensen> yeah
<eyJhb> Should proplery just search for it in the repo
<eyJhb> Thanks ! :)
<samueldr> drakonis: that's new a new dependency on varlink; they are adding their own implementation on it
<eyJhb> not a new*?
<samueldr> eyJhb: my own clippy :)
<samueldr> (yes, thinking and writing are apparently things I cannot do at the same time)
<eyJhb> Well, trying to find some purpose! So beeing a personal clippy might be a way! ;)
__monty__ has quit [Quit: leaving]
endformationage has joined #nixos-chat
<pie__> gchristensen, so i want to set up LUKS and stuff on an external drive for testing first, any recommended way to go about it?
<eyJhb> pie__ it is no fun setting up, at least when I did it :(
<pie__> ah wait i just remembered the guide i used
<pie__> last time
<eyJhb> Link?
<gchristensen> I wrote up how I did luks on grahamc.com for the 9560
eyJhb has joined #nixos-chat
<eyJhb> gchristensen: did you link something?
<eyJhb> Is that you current driver?
<eyJhb> daily driver*
<gchristensen> I have since switched mostly to a 9380 for its small, airplane-friendly size
<eyJhb> How much can that be specced?
<gchristensen> I have 16g ram, and 8 cores -- i7-8565U
<eyJhb> Damn... That is great
<eyJhb> Guessing it can be specced up quite some more
<gchristensen> I'm not sure, but it is a fabulous little laptop.
<eyJhb> Still rocking my x230, but the specs are getting outdated.. But still better than the newer x series..
<eyJhb> 16gb ram, 2x256 SSD (SSD and mSATA SSD), i7-3250m
<arianvp> My T430 is slowly dying
<Ralith> I'm reasonably happy with my T580
<Ralith> sturdy, good screen, easy to work on
drakonis_ has joined #nixos-chat
drakonis has quit [Ping timeout: 248 seconds]
drakonis_ has quit [Ping timeout: 252 seconds]
drakonis_ has joined #nixos-chat
Jackneill has quit [Ping timeout: 244 seconds]
Jackneill has joined #nixos-chat
<joepie91[m]> relevant to your interests
<pie__> joepie91[m], scroll down ;)
<joepie91[m]> actually, this probably should've gone into the WG channel lol
<pie__> joepie91[m], i was actually surprised how few stuff i could list
<joepie91[m]> pie__: ?
<joepie91[m]> that's the most recent post lol
<pie__> oh sorry, fail
<joepie91[m]> oh!
<joepie91[m]> your comment about Python is about the same thing?
<pie__> no
<pie__> i just thought it was a plain thread link
<joepie91[m]> ah right :)
<joepie91[m]> but yeah, I meant the last comment
__monty__ has joined #nixos-chat
<samueldr> bzip2 will eventually be made upstream in rust https://people.gnome.org/~federico/blog/maintaining-bzip2.html
<samueldr> (also of note, nwe maintainer who will cut a new release with several fixes)
<eyJhb> arianvp: what is dying on it?
<gchristensen> wow!
<eyJhb> Ralith: most models after 30 are... Not very solid build
<Ralith> is that a credible quantitative judgement, or do you just not like them?
<eyJhb> Ralith Tried them...
<Ralith> so the latter, then :p
<eyJhb> Not liking them, and them falling apart compared to the older models is not the same..
<__monty__> Is bzip2 still widely used? I feel like the trade-off of time for a little bit more compression doesn't really pan out anymore. It was great when bandwidth was at a premium but isn't xz a better alternative nowadays?
<eyJhb> Take the x220 and throw it against the wall, nothing.. Take the x230 and use it for school, and it starts to come apart
<Ralith> __monty__: use zstd for new projects
<eyJhb> So saying that "I just don't like them", isn't really valid Ralith ;)
<__monty__> Ralith: That's like the opposite use case of bz2/xz afaiui.
<Ralith> __monty__: ...?
<Ralith> it's a general purpose compression algorithm
<__monty__> It's for online compression.
<samueldr> __monty__: still used to extract existing bz2 archives
<Ralith> what gave you that idea?
<__monty__> That doesn't sound like it achieves a great compression ratio.
<Ralith> you are confused
<samueldr> something like 2435 archives in nixpkgs alone
<__monty__> samueldr: Yeah but the current bzip still manages to do that though : )
<samueldr> but... that's the now current bzip!
<__monty__> Ralith: The first sentence in the README gave me that idea: Zstandard, or zstd as short version, is a fast lossless compression algorithm, targeting real-time compression scenarios at zlib-level and better compression ratios.
<Ralith> __monty__: to be specific, zstd achieves higher compression ratios at higher throughput than prior general purpose compression algorithms.
<__monty__> bzip and xz achieve compression past zlib-level. That's the only reason for their popularity afaik.
<Ralith> zstd, like practically any compression algorithm, can be tuned for throughput vs. ratio
<Ralith> it does exceptionally well at both low and high settings, compared to similar tunings of competing algorithms
<Ralith> there's a nice chart somewhere but it's a pain to find
<__monty__> A few other algorithms can produce higher compression ratios at slower speeds, falling outside of the graph. This seems to point at xz still having better compression ratios.
<__monty__> (The grap calls it lzma but that's what xz does iirc.)
<__monty__> That's what I was looking at.
<Ralith> nice of you to share :p
<Ralith> so indeed not literally the fastest at every point, at least as of several major versions ago
<__monty__> I agree it looks better than zlib. But that's very widespread, which could matter. Otoh it looks like lz4 and xz are still interesting.
<eyJhb> gchristensen: did you just updated your NixOS dotfiles?
<gchristensen> eyjhb: I haven't updated them super recently, what's up?
<eyJhb> Just tried some links that I thought was from yesterday, but they don't seem to work
<eyJhb> Cleaning up my own nixos conf...
<gchristensen> which?
<eyJhb> Found it again, must have been a old link
<eyJhb> Any quick and dirty way to make changes to the fetched channels? - e.g. for testing *sigh* displaylink?... Last time was a mess
<__monty__> nix edit?
<samueldr> I use overlays to handle out of tree drivers
<samueldr> not dirty, relatively quick when it clicks
<eyJhb> samueldr quick and dirty testing and using overlays for that? Doesn't sound like the way to go :/
<eyJhb> Guess I might just do -I nixpkgs=...
<Ralith> __monty__: yeah, looks like even current zstd can't beat out xz in terms of ratio alone, guess I misremembered
<__monty__> Ralith: It doesn't come close to lz4's throughput either. But you're right the README doesn't compare different settings. Looks like the only reason to still use gzip is compatibility.
<Ralith> yes, gzip is certainly obsolete
<__monty__> And maybe single-threaded performance, since zstd's explicitly designed to take advantage of parallel cpus.
lopsided98 has quit [Quit: Disconnected]
lopsided98 has joined #nixos-chat
<arianvp> eyjhb: it's probably dusty
<arianvp> it gets really really watrm
<arianvp> but cbf taking it apart and reapplying paste etc
<arianvp> maybe when I get my new laptop I can take this one apart
<arianvp> but can't afford to be laptopless currently
drakonis_ has quit [Ping timeout: 248 seconds]
drakonis_ has joined #nixos-chat
<joepie91[m]> in the "incredibly usecase-specific abstractions" department: https://gist.github.com/joepie91/89ad2ae0855a787dc08504188b2bc8f7?ts=4
<__monty__> Sounds like a decent idea.
<joepie91[m]> (this is for a client project :P I'll probably turn it into a stand-alone module at some point though)
drakonis_ has quit [Ping timeout: 258 seconds]
<samueldr> joepie91[m]: I cheated and the loading indicator (not a word, but an icon) has transitions in CSS that makes it act right enough for cheap :)
<samueldr> though it wouldn't really scale for long spans, only useful for really short loadings
<samueldr> though it would handle really close together rapid fire loads as one mostly solid show of the spinner
<joepie91[m]> lol
<joepie91[m]> samueldr: a sort of artificial persistence of vision?
<samueldr> kind of
<samueldr> really cheap though :)
<joepie91[m]> samueldr: yeah, it's a nice hack
<joepie91[m]> lol
<eyJhb> Will prop never update to 19.03 because of DL - https://i.imgur.com/4jh3X33.jpg
<ar> wtf
<colemickens> should've used wayland
* colemickens ducks
<eyJhb> Don't.. Don't think that resolves this proprietary nightmare
<__monty__> Have you tried? I think wayland *is* supposed to make multiple monitor setups less wonky.
<eyJhb> __monty__ you do know what DisplayLink is, right?
<eyJhb> Don't think it will make a difference, since it is the blob driver that .... *insert not nice words here*
<__monty__> No clue, I only solve problems I know nothing about. That way I can't make a fool of myself : >
<eyJhb> USB 3.0 Docking Station with adds addiational displays, which means I can have three displays connected to my x230 (external)
<eyJhb> Even the logs, are encrypted...
<eyJhb> So I just get base64 encoded bs... :)
<samueldr> wat, the logs are garbage? that's just meanspirited
<samueldr> eyjhb: tried runnning the previous LTS kernel instead of current LTS?
<samueldr> because from 18.09 -> 19.03 that's the big kernel change
<eyJhb> samueldr: enjoy! https://termbin.com/o98c :p
<ar> eyjhb: oh. i used to have a "docking station" for a dell e7440 that used displaylink chips
<eyJhb> Yeah, that is what I am considering doing now
<eyJhb> Is there a easy way to pin the kernel, and what did 18.09 run?
<samueldr> eyjhb: didn't doubt you, just empathized
<eyJhb> ar: I envy the "used" part...
<ar> eyjhb: i didn't say i got it working on linux
<samueldr> eyjhb: https://nixos.org/nixos/options.html#boot.kernelpackages
<eyJhb> I just wanted you to feel my frustration too :( Encrypted logs are... It simply cannot be put into works
<ar> eyjhb: but to make it more cursed, it also used some wigig nics as a wireless pcie bridge
<samueldr> from an 18.09 checkout
<samueldr> 14311: linuxPackages = linuxPackages_4_14;
<samueldr> so boot.kernelPackages = linuxPackages_4_14; would do it
<eyJhb> This might be a stupid question, but how can I evaluate a expression and see what kernel I am currently on? E.g. get the value of boot.kernelPackages? (just for future reference)
<samueldr> I know there's a trick to have a repl of your nixos config, but don't have it handy
<tilpner> eyjhb: nix-instantiate --eval '<nixpkgs/nixos>' -A config.boot.kernelPackages.kernel.name
<tilpner> eyjhb: Though that doesn't mean you're running that kernel. You'll need to rebuild switch and reboot for that
<eyJhb> But as far as I can tell, 19.03 uses 4_19, so.. Lets try! Rebooting now and hoping for the best!
<eyJhb> SOmething will properly explode..
<samueldr> yes, 19.03 uses the current LTS, 4.19
<eyJhb> No dice.. Trying another reboot (2 mins at least pr. reboot.......), and hoping for the best, else I will try the kernel Ubuntu 16.04 is on
ajs124 has joined #nixos-chat
<joepie91[m]> I have to say that I'm pretty happy about how the papercut thread is turning out to sfar
<joepie91[m]> so far *
<joepie91[m]> 1.5 days and we already have a sizeable list of clearly and constructively described frustrations :P
<eyJhb> I mean, I love encrypted logs
<eyJhb> I can't boot 4.4... And 4.14.2xx doesn't work.. WAIT A MINUTE
<ar> hm
<ar> someone here had a nifty set of hacks for doing fast vm startups with qemu migrations to/from disk
<ar> but my backlog fails me
<joepie91[m]> ar: that would have been tilpner, I think
<joepie91[m]> search term 'migrate'
<joepie91[m]> (or 'migration', dunno)
<gchristensen> tilpner
<ar> yup, thanks
__monty__ has quit [Quit: leaving]
<eyJhb> Yeah, so nothing works, but thanks for the suggestions guys! Think I have to pinpoint using divide and conquer...
<gchristensen> when did it stop working?
<eyJhb> Upgrading from 18.09 to 19.03. So it can be quite some
<samueldr> looks like no one except you touched the display link drivers in 19.03 (before it forked off)
<samueldr> erm, untrue, there were upgrades since the 18.09 fork
<eyJhb> Basically the only thing I can think about is taken the middle between 18.09 and 19.03, checkout, build, see if it works, if it does. Middle between that and 19.03, etc..
<gchristensen> eyjhb: do you know how to use git bisect?
<samueldr> eyjhb: git bisect
<samueldr> same idea, but more automation
<eyJhb> Nope, no clue
<samueldr> (and yes, you can run it manually enough for your use case)
<eyJhb> Tips and tricks encouraged!
<eyJhb> But I don't think it is anything related to the specific change of displaylink/evdi files
<samueldr> here's the unhelful FM part :) https://git-scm.com/docs/git-bisect
<samueldr> eyjhb: were you running 18.09 with the changes to upgrade display link drivers to 4.4.24?
<eyJhb> samueldr: currently viewing it :) - Yeah, but I might have to test again. Because I am becoming less and less sure if that actually works..... It did back when I tested it, but the stable branch 18.09 doesn't have those changes
<samueldr> right, that was my thought behind that
<eyJhb> Might test tomorrow though.. Seeing as it is 00:15... :p
<eyJhb> And each.. REboot..Takes 2 minutes.. At least!.. :(
<samueldr> the big idea with git bisect is you tell it "this commit works, this commit doesn't" and it'll handle navigating you to a mid-point, where you can say that one works, doesn't or is inconclusive
<samueldr> you mean there's 23:45 hours left in the new day!
<eyJhb> Yeah, seems very nice! Haven't used it before :p But it is very much pleases me... :p
<samueldr> it can also run fully automated
<eyJhb> :( I have exams too you know
<samueldr> it feels like magic
<eyJhb> Think this will be quite hard to automate :|
<samueldr> yeah, in your case very
<samueldr> the best it could do is skip those commits that won't build
<eyJhb> Yeah...
<eyJhb> Or!
<eyJhb> Setup a camera, that can see the screen that doesn't work, get it to prompt a bright white color, detect that, feed that into git bisect (dunno how it works), and automate it like that!
<eyJhb> *jokes, but would be nice
<eyJhb> Ohh that will be very very hard, seeing as it requires reboots and stuff
<samueldr> if you were displaylink, and developing it, it sure would be a thing to consider :)
<elvishjerricco> You can boot a raspberry pi off a USB disk, right?
<samueldr> elvishjerricco: yeah
<samueldr> elvishjerricco: there are a bunch of caveats and details depending
<eyJhb> samueldr: but you know, it will just tell them that everything is bricked and barely working
<elvishjerricco> samueldr: Why’s that?
<samueldr> elvishjerricco: do you intend to fully boot from USB or boot from SD and continue on USB?
<samueldr> elvishjerricco: from USB some drives will not work, and most spinning drive will just not work since they start too slowly
<elvishjerricco> samueldr: I figured I’d do everything off an external HDD
<elvishjerricco> Seriously? The speed of the disk matters?
<samueldr> elvishjerricco: but if you have a flash drive that works, it's just seamless
<samueldr> elvishjerricco: yes, it doesn't wait too long before continuing on
<elvishjerricco> Well that’s annoying
<samueldr> yes
<samueldr> though you can have your cake and eat it too
<samueldr> I'm using this on an SD card
<samueldr> the card is mostly read-only, only changing settings in the UEFI writes to it
<samueldr> I don't mount it in the OS
<samueldr> with that, the drive has ample time to spin up before the UEFI starts poking at it
<samueldr> at least, it was my experience with a usb HDD
<samueldr> elvishjerricco: if it's a B (not B+) you will need to burn some fuses if you want to fully boot from usb
<samueldr> [3B (not 3B+)]*
<elvishjerricco> Geez. So complicated :P
<samueldr> the uefi sd card is pretty set and forget in my experience
<samueldr> grub works the same exact way as on x86_64 that way, meaning selection of the generation is graphical and with arrow keys, add to that command line editing!
<elvishjerricco> Oh so you don’t flash the firmware or anything? The pi just boots an image that implements efi?
<samueldr> exactly
<elvishjerricco> Neat
<samueldr> there is one drawback compared to the u-boot process
<samueldr> it will not load a dtb from the kernel, so it ends up using whatever was built in the UEFI
<samueldr> (or might even be whatever is built in the pi)
<samueldr> by "load a dtb from the kernel" I mean "load a dtb that has been compiled from the upstream kernel source"
<samueldr> depending on what you intend to do it might not be an issue at all
<samueldr> I might want to investigate writing this command into generations for grub https://www.gnu.org/software/grub/manual/grub/html_node/devicetree.html
<samueldr> (this would make the grub config specific to a device when active, but would fix that drawback)
<samueldr> and there again, #nixos-chat derailed to on-topic dicussions :)
<elvishjerricco> Lol
<elvishjerricco> I don’t see the device specific grub config thing as a problem
<elvishjerricco> It’s likely already at least boot disk dependent, since the uuid is probably in there
<samueldr> depends on your goals
<samueldr> if you want to boot the same drive on another SBC
<samueldr> or another aarch64 device
<elvishjerricco> That sounds like an odd use case :P
<samueldr> why would it be more weird than on x86_64?
<elvishjerricco> I’d find it weird on x86_64 as well
<elvishjerricco> Decided to try getting mkinitcpio to work in nix so that I could mess around with the much nicer initrd system in Arch. So many hard coded /usr/... and /lib/... paths... No clear way to automatically patch them correctly.
<infinisil> Oh my god, I hate summer
<infinisil> The number of spiders I've had to get out in the last week is too goddamn high
<samueldr> oof, do we tell infinisil it's not summer yet? ;)
<infinisil> And about half of them from my own room, which just so you know, does *not* have a spider-door to outside
<infinisil> Damnit
<elvishjerricco> Maybe I’ll just steam-run this thing...
<joepie91[m]> welp, VR stuff is too fun