<ashkitten>
it uses chroot to isolate the program and modifies libc to allow file descriptors to be passed in even though the paths don't exist in the chroot
<ashkitten>
essentially, not only will static linking not circumvent the protections, but a statically linked program will not work
<ashkitten>
this comes with a few downsides of course, foremost being that statically linked programs won't work properly, but also that the shell has to be very careful to not pass the program any real directory fds as it could use them to escape the chroot environment
<ashkitten>
if the program tries to open a directory the shell will pass it a fake fd that it can still use normally but not for syscalls
<ashkitten>
the shell also has to manually crawl the directory tree rather than letting the kernel handle paths, since accidentally following symlinks and such could potentially allow the program to access things it wasn't meant to access
<MichaelRaskin>
Dunno, I just have scripts to do nsjail with whatever mounts I care about and maybe grant write access to something.
<ashkitten>
i'm not saying any one approach is better, i'm not familiar enough with anything to know the advantages or disadvantages of each approach
<ashkitten>
i'm trying to explain what i know about this approach which i thought was interesting
<elvishjerricco>
Yea I used nsjail once or twice. It's much closer to the approach I'd like for containerization, but it's still a major pain to use
<MichaelRaskin>
Oh, you mean directly?
<MichaelRaskin>
Ouch
<MichaelRaskin>
Indeed a pain to use
<ashkitten>
gchristensen: btw qyliss linking spectrum-os.org was what prompted me to think about this today ;)
<ashkitten>
it looks like exactly what i want out of nixos, haha
<gchristensen>
nice
<ashkitten>
i don't know how i can be helpful, though
<ashkitten>
i've pretty much decided i don't want to do programming for anything but my own one-off hobby projects
<elvishjerricco>
Looks like Nutty has most of the features I want for a network monitor, but it seems to be GUI-only and specific to Ubuntu-like distros.
<Drakonis>
ubuntu-like distros?
<Drakonis>
don't you mean debian-like?
<samueldr>
debian-like, don't you mean gnu+linux like?
<Drakonis>
unless of course, it is dependent on netplan, which means it is dependent on ubuntu
<Drakonis>
since nobody else runs netplan
<elvishjerricco>
Not sure if it works on debian. I only heard it works on ubuntu, mint, and elementary os
<samueldr>
there is a growing chasm between ubuntu specifics and debian
<ashkitten>
ha ha! linux!
<Drakonis>
its dependencies list seems to not include netplan
<samueldr>
I don't think I've seen any of those "remote X" (as absurd as it sounds) work well with video or graphics accel
<ashkitten>
wellll
<ashkitten>
virtualgl
<samueldr>
yeah, the only user I know of is a vnc implementation; though I don't think I know them all :)
<ashkitten>
virtualgl worked great when i used it for playing games on my tv through x forwarding on my laptop from my desktop in the other room
<ashkitten>
just needs fucktons of bandwidth, which ofc is not an issue when it's local
pie__ has quit [Read error: Connection reset by peer]
pie__ has joined #nixos-chat
_e has quit [Quit: WeeChat 2.4]
_e has joined #nixos-chat
_e has quit [Client Quit]
_e has joined #nixos-chat
Myhlamaeus1 has quit [Remote host closed the connection]
pie___ has joined #nixos-chat
pie___ has quit [Remote host closed the connection]
pie___ has joined #nixos-chat
pie__ has quit [Ping timeout: 252 seconds]
Drakonis has quit [Quit: WeeChat 2.4]
Peetz0r has quit [*.net *.split]
zimbatm has quit [*.net *.split]
colemickens has quit [*.net *.split]
hexa- has quit [*.net *.split]
nh2 has quit [*.net *.split]
srhb has quit [*.net *.split]
makefu has quit [*.net *.split]
srhb has joined #nixos-chat
ericnoan has quit [Ping timeout: 270 seconds]
ericnoan has joined #nixos-chat
pie___ has quit [*.net *.split]
tokudan has quit [*.net *.split]
lopsided98 has quit [*.net *.split]
qyliss^work has quit [*.net *.split]
joepie91[m] has quit [*.net *.split]
joepie91[w] has quit [*.net *.split]
sphalerit has quit [*.net *.split]
dtz has quit [*.net *.split]
qyliss^work has joined #nixos-chat
lopsided98 has joined #nixos-chat
tokudan has joined #nixos-chat
pie___ has joined #nixos-chat
joepie91[w] has joined #nixos-chat
joepie91[m] has joined #nixos-chat
dtz has joined #nixos-chat
sphalerit has joined #nixos-chat
nh2 has joined #nixos-chat
colemickens has joined #nixos-chat
hexa- has joined #nixos-chat
makefu has joined #nixos-chat
zimbatm has joined #nixos-chat
Peetz0r has joined #nixos-chat
Peetz0r has quit [Max SendQ exceeded]
Peetz0r has joined #nixos-chat
kgz has quit [Ping timeout: 246 seconds]
kgz has joined #nixos-chat
joepie91[m] has quit [Remote host closed the connection]
sphalerit has quit [Remote host closed the connection]
Moredread[m] has quit [Remote host closed the connection]
thefloweringash has quit [Read error: Connection reset by peer]
Ralith has quit [Write error: Connection reset by peer]
ma27[m] has quit [Remote host closed the connection]
nocent has quit [Write error: Connection reset by peer]
colemickens has quit [Remote host closed the connection]
dtz has quit [Remote host closed the connection]
kgz has quit [Ping timeout: 246 seconds]
colemickens has joined #nixos-chat
kgz has joined #nixos-chat
elvishjerricco has quit [Ping timeout: 250 seconds]
elvishjerricco has joined #nixos-chat
zimbatm has quit [Ping timeout: 252 seconds]
nh2 has quit [Ping timeout: 252 seconds]
nh2 has joined #nixos-chat
zimbatm has joined #nixos-chat
Ralith has joined #nixos-chat
thefloweringash has joined #nixos-chat
dtz has joined #nixos-chat
joepie91[m] has joined #nixos-chat
sphalerit has joined #nixos-chat
ma27[m] has joined #nixos-chat
kraem has quit [Ping timeout: 246 seconds]
pie___ has quit [Ping timeout: 252 seconds]
<ldlework>
dtz: hey you around?
kraem has joined #nixos-chat
Miyu-chan has joined #nixos-chat
__monty__ has joined #nixos-chat
<MichaelRaskin>
gchristensen: judging from the fact there is a discussion of a deleted tweet by everyaws, the predicted «it will reach an undesirable word» did finally happen? How many messages were needed to reach that state (might be an interesting statistics for a word list, I guess)?
<__monty__>
AI drama?
<gchristensen>
it was AWS Slavery or AWS Slave I forget which, and it took about 5,000 tweets
<MichaelRaskin>
Deleted for being too real?
<gchristensen>
something like that
<__monty__>
Who follows twitter accounts like that?
<MichaelRaskin>
I guess it is the suboptimal middle?
<MichaelRaskin>
No topic, but not yet a uniform sample of a large enough pool of things
<gchristensen>
yeah
<__monty__>
It periodically retweets people's tweets?
<gchristensen>
only ones where they said it was a periodic reminder
<gchristensen>
I thought they would be happy to have a periodic reminder bot!
<__monty__>
And you'd follow that to get your own and everyone else's reminders?
<gchristensen>
"your periodic reminder" is a common tweet format which I suppose I'm a bit tired of
<gchristensen>
it collects 10-20 "new' tweets a day, and then only tweets out like 4 a day, so they'll get older and older over time
<MichaelRaskin>
Maybe it could get some interest if it auto-checked whether the periodic reminder is actually periodic
<gchristensen>
oh?
<MichaelRaskin>
Has the same person previously posted another twit with «periodic reminder» and the two rarest words of the samped tweet
<gchristensen>
ah, hehe, no, that is the point of the bot! they're not periodic, they're just being smug about it
<MichaelRaskin>
Well, arguably some of these ar epure smug out of void, some are maintaing a concentration (different people posting the same stuff at the rate it is actually kind of periodic), and some might be true-periodic
<MichaelRaskin>
As it is, anyone who considers «periodic reminders» a class with common properties probably dislikes them, and so the bot provides only some additional annoyance (and so noone follows it)
<MichaelRaskin>
If it auto-classified and maybe inflated the rare true-periodic class, it could be a food for thought in terms of «what are these rare things that are actually periodic reminders»
<gchristensen>
that is an interesting idea!
hexa- has quit [Quit: WeeChat 2.4]
hexa- has joined #nixos-chat
kraem has quit [Ping timeout: 248 seconds]
kraem has joined #nixos-chat
<eyJhb>
If anyone has a opinion, which do you prefer of `GetPod(),UpdatePod(),DeletePod()` or `PodGet(),PodUpdate(),PodDelete()` ?
<__monty__>
Neither in an OO language.
<MichaelRaskin>
You mean a bound-methods OO language, right?
<eyJhb>
Well, you could split it up further
<eyJhb>
But I am not sure that will be very pretty
<eyJhb>
But handling the SQL connection becomes less `fun`
<__monty__>
I'd go with suffix. PodGet() etc. made me think it should be somePod.get() and similar.
<eyJhb>
So basically having it as GetPod() ? - Pros and cons of both. I most like `PodXXX` because it groups all the functions with a speficic prefix
<manveru>
naming things...
<manveru>
eyJhb: i think that depends on how/where/by whom it's used
<eyJhb>
manveru: I have started at my screen for minutes trying to name things sometimes
<eyJhb>
Currently, me, here, me, me :p
<manveru>
is the user aware that there's a thing called pod?
<manveru>
is there autocompletion?
<manveru>
are there only CRUD operations?
<eyJhb>
Ehmm... It is a part of the CTF platform I am coding, so it would only be developers who use it. So they should know it , also by using the API
<eyJhb>
Yes, mostly only CRUD. Or at least, from that file that is what it will expose
<manveru>
then just vary the convention to mess with their brains :P
<manveru>
well, i just wondered what's the point of having a wallpaper you never see anyway...
<eyJhb>
Precisely. I only see mine when other people notice it and complain
<eyJhb>
I love when people are considering a apartment, because they look like a flock of amateur burglars
<manveru>
so now i configured polybar and termite with transparency and downloaded some 2000 triple-monitor backgrounds for regular switching
<eyJhb>
Basically going all the way up to the window, and just looking in.
<eyJhb>
Ahh...
<manveru>
:D
<eyJhb>
Another dilemma... Considering switching away from urxvt
<manveru>
well, urxvt is fine, i used that for a decade or so
<manveru>
various versions of rxvt anyway
<eyJhb>
Why the switch then?
<manveru>
mostly because proper font support in rxvt is a PITA
<manveru>
i mean, it works mostly, but using urxvt in i3, you always get that black bar at the bottom of the terminal if it doesn't exactly match the window-height/font-size
<manveru>
once i wanted transparency, i finally switched because there's no fix for it
<manveru>
and termite supports about 95% of what i used perl extensions for out of the box
<manveru>
powerline fonts also work without major hacking
<__monty__>
But you can't get rid of the leftover black bar unless you compromize on font scaling.
<manveru>
plus i used urxvtd/urxvtc, sometimes the daemon crashed and all my terminals died with it :(
<__monty__>
I agree urxvt has terrible font support though.
<__monty__>
Can't say I like termite either.
<manveru>
yeah, for me it's just the most convenient option atm
<manveru>
tried pretty much all others as well, but never use them other than cool-retro-terminal :P
<MichaelRaskin>
Argh. Julia 1.1 fails on master, during the tests, after consuming a ton of CPU and RAM and time, and I don't understand why…
<__monty__>
manveru: Fwiw, kitty has some really nice features.
<manveru>
__monty__: maybe once it gets a home-manager module ;)
<manveru>
just kidding, what do you like best about kitty?
pie_ has joined #nixos-chat
<ldlework>
huh, i never noticed the extra space at the bottom.
<ldlework>
i guess my mind saw it as margin. thanks a lot.
<manveru>
ooh, symbol_map is nice, so i don't need to patch fonts for kitty...
* ldlework
can't unsee
<manveru>
ldlework: sorry man :(
<ldlework>
lol
<manveru>
i tried to ignore it for a long time too ;)
<__monty__>
manveru: Things like open url, copy line to clipboard and use hash from previous output in current command.
<manveru>
__monty__: i'll definitely give it a try
<manveru>
i noticed `icat` isn't there by default
<manveru>
usually i use ranger for that, but would be cool
<__monty__>
If you use ranger it also supports first-class image previews : )
<__monty__>
With the kitty method.
<__monty__>
Hmm, icat should be in the kitty package.
<__monty__>
Terminology has slightly better image viewing and can handle video too. But I do miss the hinting features. And people usually object to the EFL dependency : )
<manveru>
__monty__: yeah, i have no icat for some reason
<manveru>
,locate bin icat
<{^_^}>
Found in packages: sleuthkit
<manveru>
i doubt that's it
<__monty__>
,locate icat
<{^_^}>
Found in packages: kitty, sleuthkit
<__monty__>
Hmm, maybe it's not an output of the derivation?
<manveru>
ah, got it
<manveru>
the command is actually `kitty +kitten icat`
<manveru>
anyway, it seems pretty smooth and more configurable than termite, gonna try it for a few days :)
<Shados>
manveru: I've not had a single urxvtd crash in all my usage of it :o. Been about... 8 years or so, I think. Although I make very little use of perl plugins, to be fair.
<Shados>
Topically, the main urxvt plugin I *do* make use of is for live config reloading...
<ldlework>
urxvtd has never crashed for me either. i use a few plugins for the typical things like the fancy url selector, etc.
<ldlework>
i do lament no color emoticons but only a tiny bit :D
<Shados>
Well, they have colour. Just not baked in :p.
<ldlework>
Mine don't have color, and while I forget what I tried at the time, I'm pretty sure I tried everything :P
jackdk has quit [Quit: Connection closed for inactivity]
<jD91mZM2>
I gave up on carnix, even the most simple definition failed after an upgrade. I think I'm going to try rolling my own. With cargo as a library, I can get this output: https://gist.github.com/ed58dd82826d6a9d47300fdbc917a377. If I can then just replace all the paths with correct ones...
<jD91mZM2>
By letting cargo generate the rustc commands it's probably not going to be buildRustCrate compatible. I honestly don't care, I just want it to Just Work:tm:
Drakonis has joined #nixos-chat
<Ralith>
jD91mZM2: sounds like a very cool project! I def wouldn't worry about backwards compat
<Ralith>
there's not a ton of rust in nixpkgs and we really need a maintainable solution
<Ralith>
I bet you could even upstream some changes if needed, but you can probably get pretty far by symlinking dependencies together and setting `CARGO_HOME` or similar
<eyJhb>
Comming up with where to place the logic in ones code ... suck :(
<qyliss>
I really hope we can get rid of buildRustPackage in nixpkgs
<andi->
Yeah
<gchristensen>
+1
<ashkitten>
ooh, terminal emulator discussion
<ashkitten>
i'd recommend either alacritty or kitty
<das_j>
ashkitten: st?
<ashkitten>
isn't that the suckless one where you have to recompile to change options
<ashkitten>
no thanks
<ashkitten>
suckless more like suckmore. "get rekt" or whatever the kids these days say
<qyliss>
a particularly horrible community too
<ashkitten>
yeah
<ashkitten>
they're not fun
<ashkitten>
actively and explicitly elitist and user-hostile
<ashkitten>
one of their actual stated reasons for using header files as configuration is to keep the userbase "small and elitist" iirc
<qyliss>
oh it gets worse than that
<ashkitten>
well i wasn't gonna mention the fascism
<qyliss>
I'm all for header files as configuration. Means you can configure with Nix very easily.
<qyliss>
And means you don't have to write a parser
<qyliss>
(Or link to one)
<ashkitten>
when was the last time you wrote a parser
<ashkitten>
for a configuration format
<ashkitten>
the libraries come in droves
<qyliss>
well sure
<qyliss>
but why add a dependency on a library?
Guanin has joined #nixos-chat
<ashkitten>
because not everyone uses nix?
<ashkitten>
it's user-hostile
<qyliss>
The other thing I like is the s6 approach
<qyliss>
Where you have a directory
<qyliss>
File names are keys, file contents are values
<ashkitten>
that just sounds like filesystem hell
<qyliss>
How so?
<ashkitten>
filesystems, particularly on hard drives, are really bad with tons of tiny files
<ashkitten>
makes latency bad, and you get fragmentation on certain filesystems
<qyliss>
so don't use those file systems?
<ashkitten>
there isn't really a filesystem i'm aware of that is optimized for tons of tiny files
<ashkitten>
well, maybe that one that's literally an sql database
<qyliss>
wait what
<ashkitten>
i think it was a research project
<ashkitten>
i dont know what it's called
<ashkitten>
but it was well optimized for traversing directories iirc
<qyliss>
ZFS can share blocks between multiple files
<qyliss>
(apparently)
<ashkitten>
which makes latency and fragmentation worse if the files change
<ashkitten>
and zfs has no defragmentation currently
<ashkitten>
it's a really hard thing to do with its layered architecture and accounting in many places
<qyliss>
I'm not exactly expecting configuration files to change so often as to cause issues?
<ashkitten>
sure
<ashkitten>
without seeing it in context at full scale i can only speculate on the possible downsides
<ashkitten>
either way a simple key-value file format is not expensive to parse
<qyliss>
just annoying
<ashkitten>
don't see how it's that annoying in modern langs
<qyliss>
well, it adds code
<ashkitten>
in rust i can just #[derive(Deserialize)] on a struct with serde
<MichaelRaskin>
Does it care about human redability (and writeability even)?
<ashkitten>
MichaelRaskin: ?
<qyliss>
but then you need a dependency on serde
<ashkitten>
serde supports a number of serialization formats including json, yaml, toml, and csv
<ashkitten>
qyliss: why are dependencies bad
<MichaelRaskin>
Well, if we are talking about configuration files the annoying parts are making sure corner cases are encodable and making the format nice to version-control
<gchristensen>
everything already depends on serde anyway
<ashkitten>
i don't see why dependencies are so awful lol
<gchristensen>
serde is the bee's knees
<ashkitten>
maybe if you have a really bad build system that can't fetch dependencies for you, i assume that's why so many c libraries reinvent everything so they can be dependency-less themselves
<ashkitten>
but modern build systems aren't like that
<qyliss>
Things fetching dependencies for themselves is how we end up with buildRustPackage and stuff
<ashkitten>
nix can fetch dependencies too
<qyliss>
where it's very hard to package things without going through those build systems which are also package managers
<gchristensen>
yeah
<gchristensen>
and it does suck to have the entire ecosystemof dependencies move forward in a way you're not ready to
<gchristensen>
I had to fork and maintain several libraries for ofborg due to this
<ashkitten>
it's impossible for a distro to package every library, that's just a hard truth. but having every library be an entirely different programming paradigm is honestly the worst thing and why i'll never go back to c++
<qyliss>
I have an RFC in me for doing this kind of stuff better in Nixpkgs, but gotta quit my job first so I actually have time.
<qyliss>
ashkitten: we already package, for example, basically every haskell library
<MichaelRaskin>
Having each library in a single programming paradigm inside itself is already horrible
<ashkitten>
i don't know that you mean, MichaelRaskin
<ashkitten>
qyliss: that might be true, but i know for a fact that a lot of libraries in nixpkgs are wildly out of date
<gchristensen>
really?
<MichaelRaskin>
Well, CLSQL ships both functional and object-oriented wrappers over the same functionality, for example
<ashkitten>
gchristensen: especially lesser-used python libs
<gchristensen>
30% it seems
<MichaelRaskin>
Purely language-defined ecosystems is that decay old good books have warned me against, twenty years ago
<MichaelRaskin>
Having trouble whenever a library wants to ship both Lua and Python wrappers is also… suboptimal
<ashkitten>
i'm mostly just tired of having people be afraid to introduce dependencies for things they'd rather not have to maintain themselves
endformationage has joined #nixos-chat
<ashkitten>
and then you end up with ubiquitous de facto standard libraries for things that are just absolute garbage but everyone uses them so you don't have much choice
<ashkitten>
cough cough, glx
<samueldr>
anyone with experience / opinions about the different block device over network implementations that work with linux?
<gchristensen>
a little bit, and my general answer is be very careful
<MichaelRaskin>
There are interesting corner cases
<MichaelRaskin>
Over the network basic consistency assumptions don't hold
<gchristensen>
one time I hit a corner case in Ceph and it cause the entire ceph cluster to kernel panic, and then everything mounting anything off the ceph cluster had a kernel panic, and then then all of my servers were dead for a bit
<samueldr>
I may have a weird use case; I don't intend to make those block devices permanent, if it even works with what I want to do
<gchristensen>
is this for, like, mounting a temporary rootfs from remote for very thin clients?
<samueldr>
I might even not care about latencies that much depending on what testing looks like once I start
<samueldr>
right
<samueldr>
temporary might not be the right word, more ephemeral in that I don't care to reuse them the next boot
<gchristensen>
coo
<gchristensen>
I think clever had a thing for this
<samueldr>
and I think the main pain point would be the low amount of ram on the machines mounting the networked block device
<samueldr>
(from not too deep of a research)
<__monty__>
How is it different from PXE boot?
<samueldr>
it would start from PXE boot, but PXE doesn't (AFAIK) have remote storage in mind
<MichaelRaskin>
Are you sure you want remote _block_ device?
<samueldr>
from PXE you get an initial system, from which you *might do something* to remote mount something
<samueldr>
not entirely, and I need to actually test it to know
<samueldr>
and you'll scream internally
<samueldr>
swap
<samueldr>
because I might as well mount NFS or any other file-based FS for the rootfs
<MichaelRaskin>
So, in case of any network hiccup, your client nodes are allowed to just lockup in weird and innovative ways?
<samueldr>
yes
<gchristensen>
it'll be fine then
<samueldr>
or at least, I want to *try* it before poo-pooing the idea; I'm not sure it's even a remotely passable idea at first
<samueldr>
(heh, remotely)
<samueldr>
but it might end up saner than the alternatives for the contrived use case
<ashkitten>
wait, you're doing swap over network?
<samueldr>
might be forced to do so
<gchristensen>
that is how you know it is a good idea
<MichaelRaskin>
iSCSI maybe?
<gchristensen>
I think pxe even knows about iscsi, built in
<ashkitten>
i feel like swap over network is worse than no swap
<MichaelRaskin>
Network is faster than HDDs, though
<samueldr>
in most cases my feeling would be to agree
<ashkitten>
swap on pingfs!
<samueldr>
but in this case it is known that on-board memory will not be sufficient
<gchristensen>
ashkitten: at one point I booted a VM with its rootfs in a pingfs mount
<samueldr>
lol, I just searched "DDR(2, 3, 4) over USB" as it would fix the issue of "flash drives will die", and every one replying to the serious questions are deafly saying "it's volatile so it wouldn't work"
<ashkitten>
so why exactly are you using the client this way as opposed to say, a virtual machine on the host which is accessed via vnc or similar?
<samueldr>
nothing that a good mkswap at boot wouldn't fix
<samueldr>
builders for a specific CPU
<ashkitten>
gchristensen: this disgusts and fascinates me
__monty__ has quit [Ping timeout: 245 seconds]
<MichaelRaskin>
People say ATA over Ethernet is a thing
<samueldr>
yeah, I saw AoE, iSCSI and NBD as options
<ashkitten>
the funniest thing about pingfs is that it only works over the internet and not locally, because the low latency will make it drop packets
<gchristensen>
ashkitten: it didn't work well, and barely made it past boot
<ashkitten>
lol
<samueldr>
it's likely I want the one with the least memory requirements... which now makes me think: could that be an issue, where it swaps itself out on itself?
<MichaelRaskin>
Oh well, computing started with storage being essentially pingfs
<MichaelRaskin>
I don't remember if there were acoustic delay lines first, though
<gchristensen>
true
<ashkitten>
pingfs is also hilarious because if your network goes down you just lose the whole filesystem
<MichaelRaskin>
Oh well, Rowhammer plus obviously volatility reminds us that our DRAM still shares some values with pingfs
<MichaelRaskin>
Meh, if your HDD reading head goes down just a fraction of a millimeter, you also lose your whole FS, so what
<ashkitten>
that's not the same
<ashkitten>
your filesystem isn't contained on the wires between the read head and your sata controller
buckley310 has joined #nixos-chat
<gchristensen>
it is a teensy bit easier to get a busted FS off a drive than it is to get it back out of the RAM of network equipment, too
<ashkitten>
especially when it's been dropped from the ram already
__monty__ has joined #nixos-chat
<MichaelRaskin>
gchristensen: I think you missed the part about the head going down a fraction of a millimeter
<eyJhb>
gchristensen: "teensy bit easier" :p
<MichaelRaskin>
Not really easier to recover anything after that
<eyJhb>
MichaelRaskin: but that wouldn't stop a plate swap, if you really wanted to
<eyJhb>
And you had a exact matching drive. I might be wrong
<gchristensen>
eh whatever
<gchristensen>
sounds like a funproject samueldr
<ashkitten>
MichaelRaskin: well it's easier than trying to get ephemeral data out of ram that probably never even hit ram
<MichaelRaskin>
Well, you can plate swap, but the spinning rust has been mechanically moved by the collision at that point
<eyJhb>
I feel like this is a setup for a CTF challenge
<MichaelRaskin>
Start small
<MichaelRaskin>
Overwrite with zeros and ask to recover
<ashkitten>
do ping packets ever even hit ram? i doubt it
<MichaelRaskin>
Depends; on a Linux-based router with horribly complicated routing rules, probably yes
<eyJhb>
pingfs => dump traffic => give pcap file => be hated
<eyJhb>
I love it
<ashkitten>
anyway imma go do stuff
<ashkitten>
cya all
<gchristensen>
see you
<MichaelRaskin>
See you
__monty__ has quit [Quit: leaving]
<gchristensen>
r13y.com is seriously cramping my style these days. the system it runs on is too stressed by it
Miyu-chan has quit [Ping timeout: 246 seconds]
__monty__ has joined #nixos-chat
__monty__ has quit [Ping timeout: 248 seconds]
__monty__ has joined #nixos-chat
<samueldr>
heh, I wondered why the solder wouldn't flow
<samueldr>
the batteries in the soldering iron *finally* died