<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>
(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.)
<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
<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>
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>
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>
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>
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>
(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...