<clever>
samueldr: and with the addition of megaparsec, it can now detect github urls, and switch to fetchFromGitHub, which fetches far faster then fetchgit
<samueldr>
nice
Taneb has quit [Quit: I seem to have stopped.]
drakonis has quit [Quit: WeeChat 2.3]
drakonis has joined #nixos-chat
drakonis_ has quit [Ping timeout: 264 seconds]
jackdk_ has joined #nixos-chat
jackdk has quit [Disconnected by services]
jackdk_ is now known as jackdk
ninjin has quit [Remote host closed the connection]
ninjin has joined #nixos-chat
endformationage has quit [Quit: WeeChat 2.4]
eyJhb has joined #nixos-chat
jasongrossman has joined #nixos-chat
eyJhb is now known as eyJhb
thePirateKing has joined #nixos-chat
jackdk has quit [Ping timeout: 240 seconds]
Taneb has joined #nixos-chat
drakonis has quit [Ping timeout: 246 seconds]
drakonis has joined #nixos-chat
pie_ has joined #nixos-chat
<srhb>
Hum. Any graphviz people around? I want to make all nodes in a subgraph have the same size (that of the largest node) and maybe fiddle with their alignment. Can I do that?
<Taneb>
srhb: there's the fixedsize node attribute which gets you part of the way there, with width and height?
<eyJhb>
srhb: I am currently (like right now) in a lecutre on Graph Theory, but I doubt my teacher have used graphviz
<srhb>
eyJhb: I'd be very surprised if you're right about that :P
<srhb>
Taneb: In this episode of "why isn't X a programming language..."
<eyJhb>
I can ask him next time he is around? :p
<eyJhb>
He mostly use MatLab as far as I know
<etu>
TFW you are confused why numbers in your database table don't increment and you realize that you hit unsigned maxint
<eyJhb>
etu: I believe I have done worse :p Took me a week to debug
<Taneb>
srhb: I'm trying to imagine what a programming language designed for drawing graphs would look like...
<srhb>
Taneb: Well, right now I just want it to go: compute the minimum width of these, then set fixedwidth to all in this subgraph. :P
<eyJhb>
Taneb: I would guess as much fun as havin git
<srhb>
inflateToBox=true
<srhb>
:-)
<srhb>
Surely I'm not being unreasonable here!
<Taneb>
Wanting things to be useful and practical? How unreasonable can you get! ;P
* srhb
sighs
<srhb>
uglyGraph it is.
<eyJhb>
srhb: got any screenshot of this? :p
<srhb>
Not without getting rid of identifying labels I'm afraid. Maybe I can cook up an example later. :)
<eyJhb>
Work related? Sensitive information?
<eyJhb>
- disableLabels: true
<eyJhb>
:D
<srhb>
Work related, yeah. Not strictly sensitive, but I try and maintain a healthy distance. The label size is what causes the problem though! xD
<srhb>
Guess I can just s/r them all into the same letter or something. That should reduce the information leak :-P
<eyJhb>
ohh, then that is a easy fix! Remove the labels, and just say "It is OBIVIOUS what this means" - Every textbook ever.
<eyJhb>
s/r? :p
<srhb>
Search and replace.
<srhb>
But yeah >_
<eyJhb>
Ahh... Makes sense.. I am thinking with grahs now! And that thinking is broken, seeing as I quite don't get it.
<srhb>
Make them all be single letter labels and include a legend at the bottom...
<srhb>
:|
<eyJhb>
Do that! :D Possibly pretty
<srhb>
Also indecipherable. I think maybe I should just draw this by hand. But ugh, the purpose of this exercise was to make it actually editable when revisions are needed, and we all know how images get updated (never)
<srhb>
Oh well. /me scampers back to more important stuff
<srhb>
Who care about documentation anyway
<eyJhb>
That will be a problem for future srhb / your teammates :p
<eyJhb>
I started documenting my Gocode as my group members could understand it. It is now 75% comments
<eyJhb>
Are there any rules about extensive commenting NixPkgs?
<joepie91>
actually, maybe I'm confusing JWS and JWT
<joepie91>
hold on
jtojnar has joined #nixos-chat
<etu>
And then you can have jwks to distribute public keys as well
<eyJhb>
*did not expect this to happen
<joepie91>
"The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure"
<joepie91>
okay so the "JWT" is just the data structure contained within the signed and/or encrypted thing
<joepie91>
guess I *was* confusing JWS and JWT :P
<etu>
So "they can be encrypted" :)
<joepie91>
yes, see above :P
<joepie91>
(my confusing JWS and JWT)
<eyJhb>
And that's how I got the nick eyJhb
<sphalerite>
*credits roll*
<joepie91>
lol
<eyJhb>
It is kind of a love/hate relationship, as I hate having to type anything with uppercase letters.. So I am conflicted between eyjhb and eyJhb
<joepie91>
eyJhb: ey is a unique-enough prefix that you will never have to type uppercase!
<joepie91>
just ey<tab>
<eyJhb>
Yeah, but I just hate seeing it in configs too! Each time I need to actually use the nick for anything... And the WORST... the structure of Golang src.. `~/go/src/github.com/eyJhb/<project>`, but true.. Never type it that often
<eyJhb>
And fzf all the way for navigation
<sphalerite>
eyJhb: but github is case insensitive!
<sphalerite>
(windows-style case insensitive, where it preserves but ignores case)
<eyJhb>
Hmm. I wonder if Golang will care
<eyJhb>
WEll well well.. I will just use lowercase then!
<eyJhb>
sphalerite: haha, glad to hear! I still have ... loads of them :p - Hoping that I will soon have some time, to do some writeups regarding some basic exploits
<eyJhb>
*they are still very usefull those sim cards every once in a while*
endformationage has joined #nixos-chat
waleee has joined #nixos-chat
endformationage has quit [Ping timeout: 268 seconds]
pie_ has quit [Ping timeout: 245 seconds]
endformationage has joined #nixos-chat
noonien has joined #nixos-chat
thePirateKing has quit [Remote host closed the connection]
drakonis_ has joined #nixos-chat
drakonis has quit [Ping timeout: 244 seconds]
thePirateKing has joined #nixos-chat
drakonis_ has quit [Ping timeout: 240 seconds]
thePirateKing has quit [Ping timeout: 255 seconds]
<samueldr>
not sure, it was your "Lorri?" apparent confusion that ensured I'd link it
<ldlework>
It says "Lossy"
<ldlework>
as in lossy compression
<samueldr>
it was a bad pun on lossy compression yeah
<ldlework>
i like it
<__monty__>
I thought it was an aquarel.
<andi->
it is art.
<gchristensen>
reminds me of a lotto kiosk I saw in Nuremberg with a big sign saying "Lose von Lotto", and it felt slightly too honest
<andi->
never thought about it that way
<andi->
Just when I thought (and waited for a few minutes) that I managed to split $out into $out and $lib for buildRustCrate It errors out with a cyclic dependency… -,-
<eyJhb>
Ohh I am having fun with BuyVM atm. testing something that requires internet.. So sometimes there are just "build in breaks", which are between 5 secounds to 5 minutes
<gchristensen>
...lol.
<eyJhb>
But mostly me commenting in/out code which pulls images from hub.docker.com, which 50/50 works because of internet.. :p
<eyJhb>
Having to luck up documentation on the phone sucks too
hl has quit [Read error: Connection reset by peer]
<andi->
maybe you should consider switching your traffic elsewhere.. :-)
<eyJhb>
Properly should, but that requires me to setup another VPN again...
<eyJhb>
And holy hell, this setup with my docker/slave/master/agent, stuff is begining to be very.. Jenky to say the least
<andi->
can not judge how bad exiting at you local ISP/uni is but maybe worht considering for a while..
<eyJhb>
Well... Not always bad, buuut, I like to be safe... But I should maybe consider having more passthrough from my normal laptop, and let my test server have all the VPN fun
hl has joined #nixos-chat
<eyJhb>
gchristensen: have you worked on the NixOps plugins since initial PR?
<gchristensen>
a bit here and there
thePirateKing has joined #nixos-chat
__monty__ has quit [Quit: leaving]
jasongrossman has quit [Ping timeout: 250 seconds]
<samueldr>
oof, not sure how much there really is on the ground, but looks like about 10-15cm already out of the 25cm announced for the day; with more to come tomorrow
<gchristensen>
wow!
<gchristensen>
I'm down to a 4-square-foot patch 1" deep.
<clever>
infinisil: luckily, the severe lack of escaping, allows me to escape it myself!
jasongrossman has joined #nixos-chat
das_j has quit [Remote host closed the connection]
das_j has joined #nixos-chat
jasongrossman has quit [Ping timeout: 246 seconds]
<elvishjerricco>
So `man zpool` says it's ok to have an `ashift` that would imply a sector size greater than the disk's actual sector size. In that case, how can ZFS ensure the atomicity of writing a single sector? Isn't that the whole basis for its guaranteed consistency?
<gchristensen>
maybe its root sector write is a native size?
<elvishjerricco>
Oh I see, it's somewhat journal-like kinda. There's actually four copies of the superblock on each vdev. When importing a pool, ZFS just scans for the one with the highest transaction number whose content matches its hash. So if you crash while writing the new superblock for the first time, it'll just use one of the others with the old superblock
<elvishjerricco>
So they don't rely on block-level atomicity at all
<clever>
elvishjerricco: ive asked about similar things in #zfs before, and when you modify any directory, it will recursively modify all parent directories, all the way up to the superblock
<clever>
depending on snapshots, it may then GC the originals
<elvishjerricco>
clever: Yea. It's apparently 4x128, not just 4. Kinda. There's an array of 128 superblocks, and every new superblock goes to the next index in that array, wrapping around at the end. If your most recent superblock isn't completely written, it uses the previous slot. For redundancy, this array is stored in four places on each vdev. So it'll look at all copies and just pick the newest verifiable slot out them all.
<clever>
ahh, nice
<elvishjerricco>
Wrapping around this array like that helps avoid wearing a single block too hard (not sure that's relevant on SSDs)
<clever>
wrapping also ensures a partial write wont destroy the old value
<elvishjerricco>
yep
<clever>
since you have 127 old values at diff slots
<elvishjerricco>
and that's how it remains atomic
<clever>
ive even seen similar things in embeded hardware, have an array of configs, with a serial# on each
<clever>
and just use the one with the highest serial#
<clever>
wear leveling and atomicity in the same package
<clever>
mkSelector :: Text -> NAttrPath NExpr
<elvishjerricco>
Now I'm trying to figure out how often ZFS commits its transaction groups... It isn't per fsync or even write I don't think. I tried making a small pool, filling it with a large file, and overwriting that file with new data, and it didn't claim to be out of space; so presumably if I lost power in the middle of that write operation, the file would be in a half and half state.
<clever>
elvishjerricco: from past questions ive asked, zfs mostly keeps things atomic at the syscall level
<clever>
so a given write() call will either have happened, or not, but never land in the middle
<elvishjerricco>
clever: It does not at the `write` syscall level, it seems. Maybe observably to other processes, but not to the storage of the data.
<clever>
but, i think depending on sync stuff, a write() call can return, but then fully rollback after an improper shutdown
<clever>
then it will behave as-if it never happened
<elvishjerricco>
My experiment shows that because you can overwrite a file that takes up the whole disk, it must be overwriting blocks that contain the old data
<elvishjerricco>
and that was a single write syscall
<clever>
ive run into problems before, where i had so little free space, i couldnt even delete a file
<clever>
but part of that might be the automatic snapshots, so it cant immediately GC the old version
<elvishjerricco>
yea, the equation changes with snapshots.
<elvishjerricco>
because that ensures you *must* have new blocks to write to
<clever>
have you seen the block dump api?
<elvishjerricco>
but this problem should still be observable on files not currently in a snapshot
<elvishjerricco>
nope, what's that?
<clever>
echo 1 > /proc/sys/vm/block_dump
<clever>
the kernel will now log EVERY read/write to disk, in dmesg
<elvishjerricco>
lol ok I should give that a shot in a VM
<clever>
[1363338.049405] z_wr_iss(388): WRITE block 516165200 on nvme0n1p1 (8 sectors)
<clever>
[1363338.049596] z_wr_iss(386): WRITE block 516361560 on nvme0n1p1 (112 sectors)
<clever>
elvishjerricco: if you then know where the 4x128 superblocks are, you can convert those block offsets into superblock slot#'s
<clever>
and verify if something even is in the superblock
<elvishjerricco>
yea that's a good idea
<clever>
note, if the journal is on zfs, that will cause recursion
<elvishjerricco>
Oof
<clever>
dmesg written to zfs, causing more dmesg, causing more writes!
<clever>
systemd does buffer things fairly well, so it wont max out resources, but it will result in a constant stream of writes
<elvishjerricco>
can you write to a block device sparsely in a single write? i.e. write to blocks 0 and 2 but not 1, without sending multiple commands to the disk?