<vin>
Why isn't there an instruction that does sepcific TLB invalidations across all cores at once? invlpg [addr] only invalidates the TLB on one core
<vin>
This requires sending ipi to all other cores and triggering invlpg on the same address if pcid/asid match
<vin>
Or reloading CR3 on all cores if page table changes -- which can cause serious performance issues -- especially if the invalidated addresses aren't even activly used
<Mutabah>
Well, each instruction only affects one core in general
<Mutabah>
so, the way to do specific invalidations cross-core is to use an IPI
<heat>
well, no
<heat>
they could do cross-core shootdowns, but they don't
<heat>
for various legacy/silicon/asid reasons
<Mutabah>
Hmm... a point
<heat>
arm64 can do this sort of stuff just fine
<heat>
zen (due to its arm legacy) can do this stuff too, with some little issues due to lack of asid bits
<heat>
see invlpgb for more deets
<vin>
I wonder if there would be race conditions when done in kernel. If kernel issues invlpg[addr,asid] on core 1 and sends and ipi to core say 32 (furthest away) for invlpg[addr,asid] by the time core 32, by the time cross core shoot down happens some requests might be services from stale TLB at 32.
<heat>
there's no race condition because you can't reuse those unmapped pages/page table pages/ptes/whatever before getting the shootdown confirmation
<vin>
Yes, the core initiating ipi can't use it but what about the other core who has no clue that there is an ipi in flight -- it will blindly service the requests from TLB correct?
<heat>
yes
<heat>
where's the race condition?
<Mutabah>
heat: If you changed the mapping then there's a possible race - although maybe the IPI should be sent with a lock held?
<heat>
you always need to tolerate slightly stale data being in the TLB because obviously there's no "nukethetlbexactlywhereiwant,atomically,acrossallcpus" instruction
<vin>
core 1 does mov addr and core 32 does mov addr -- core 1 has addr->pfn1 but core 32 has addr->pfn2 (stale entry in TLB)
<heat>
yes
<vin>
"nukethetlbexactlywhereiwant,atomically,acrossallcpus" instruction -- wouldn't that be awesome
<heat>
this isn't even a problem because very rarely do you need or want to just replace a pte's pfn like that
<heat>
at least while it's a valid pte for the operation you want
<Mutabah>
Yeah...
<Mutabah>
shared/replacable PTEs should be protected by some sort of lock to avoid issues
<heat>
i mean, obviously you have locks, but locks don't save you
<Mutabah>
And for doing CoW the worst is a false PF
<heat>
yes
<Mutabah>
(... wait, maybe a stale read?)
<Mutabah>
although, that'd be a standard race condition
<heat>
right
<Mutabah>
maybe? I feel like there might be a hole towards a soundness issue depending on the desired behaviour of that read
<vin>
So, I was reading how linux does tlb shootdowns when moving pages to swap cache -- it unmaps the pages (clears ptes and issues invlpg) and then does a cr3 relaod on all other cores for an asid. This ends up causing tlb misses for pages that are not even being moved to swap.
<heat>
>and then does a cr3 relaod on all other cores for an asid
<heat>
not really?
<heat>
there's a sysfs configurable on the single page ceiling, above that number of pages it reloads cr3, under that it does invlpg
<bslsk05>
github.com: linux/mm/vmscan.c at 4a5df37964673effcd9f84041f7423206a5ae5f2 · torvalds/linux · GitHub
<bslsk05>
github.com: linux/arch/x86/mm/tlb.c at 4a5df37964673effcd9f84041f7423206a5ae5f2 · torvalds/linux · GitHub
<vin>
but doing invlpg for a single core is not enough if if above the page ceiling as there will be tlb entries else where
<heat>
nope, it ends up in arch_tlbbatch_flush
<vin>
also, I am only looking at x86 paths
<heat>
which then decides what it wants to do in flush_tlb_func
<vin>
heat: I am looking a flamegraph that shows exactly the paths taken and I can see that try_to_unmap() eventually calls native_flush_tlb_one_user() and try_to_unmap_flush_dirty() calls native_flush_tlb_local().
<vin>
native_flush_tlb_one_user() does invlpg on the addrs whereas native_flush_tlb_local() does cr3 reload
<heat>
it may be that in your case it always ends up doing a full flush
<heat>
for instance SWAP_CLUSTER_MAX > the default single page ceiling
<vin>
Why does it have to to do a full flush if folio size is greater than SWAP_CLUSTER_MAX? Wouldn't this affect the performance of application even if it isn't touching any of the pages being swapped?
<heat>
there's a point where doing invlpg in a loop is just slower than flushing the whole thing and letting it catch back up with tlb refills
<heat>
the default is 31
<heat>
for x86
<heat>
note that this has little to do with folio size but how many folios you're holding for reclaim at once
<heat>
the exact try_to_unmap_flush_dirty() you're looking at, i can't really explain (i don't understand the logic behind it), but the rest just tries to batch tlb ops. if you reclaim SWAP_CLUSTER_MAX (32) pages from your address space, you will 100% get a full flush
<heat>
and note that x86 has further logic for asids and tlb gens, yadda yadda, that might also be causing the full flush you're observing. i'm not intensely familiar with that stuff
<heat>
but basically the logical conclusion is that flushing the whole tlb isn't much slower than invlpg after a very small point, for various reasons
<heat>
for instance, consider that invlpg fucking sucks
<vin>
I don't understand how issuing invlpg one a single core is enough? In the case of folio list size smaller than SWAP_CLUSTER_MAX. The x86 tlb.c has not logic to do ipi shootdowns for a given addr
<the_oz_>
TLB is local to a core isn't it?
<heat>
oh sorry, i am blind, they specify a full flush in arch_tlbbatch_flush
<heat>
TLB_FLUSH_ALL
<vin>
heat: arch_tlbbatch_flush is only called in try_to_unmap_flush() and not in try_to_unmap() or try_to_unmap_flush_dirty()
<vin>
Ah you are right -- and that eventually does cr3 relaod. Then I don't understand why they do invlpg in try_to_unmap(). Since we anyway end up reloading the entire TLB for that ASID
obrien has quit [Remote host closed the connection]
SGautam has joined #osdev
Arthuria has quit [Ping timeout: 260 seconds]
heat__ is now known as heat
Turn_Left has joined #osdev
netbsduser` has joined #osdev
Left_Turn has quit [Ping timeout: 260 seconds]
<sortie>
I will osdev for money apply today
karenw has joined #osdev
<kof673>
:/ credit replaced money a long time ago :D quote: Those are I.O.U.'s. Go ahead and add it up, every cent's accounted for. That's a car. Two hundred seventy five thou... Might want to hang on to that one.
hwpplayer1 has joined #osdev
rb has quit [Remote host closed the connection]
GeDaMo has quit [Quit: 0wt 0f v0w3ls.]
Arthuria has joined #osdev
<nikolar>
sortie: me too
<sortie>
Join Sortix let's make it a success?
Left_Turn has joined #osdev
<nikolar>
heh
<nikolar>
is there money though
<sortie>
idk I think there is some potential here. Sortix is close to being a viable server platform for the cloud. Unclear how to sell that.
<sortie>
Or setting up some sort of foundation and receiving donations
<sortie>
Companies like canonical make money somehow
<nikolar>
consultations and support i imagine
<sortie>
I imagine the path would be something like making Sortix just really useful and then asking people using it to pay for development and services?
Turn_Left has quit [Ping timeout: 264 seconds]
<nikolar>
but how can you make more useful than linux or even bsds
<sortie>
> In 2008, the European Research Council awarded Prof. Andrew S. Tanenbaum, the designer of MINIX, an Advanced Grant of €2.5 million (about $3.2 million) to produce a reliable operating system. [ https://wiki.minix3.org/doku.php?id=www:download:releasenotes-3.3.0 ]
<sortie>
This quote is still burned into my mind. Minix 3 isn't even that great. The project even appears to be entirely dead today, €2.5 million later vanished into the air.
<nikolar>
well intel me used it
<sortie>
Do you know what kind of Sortix I could make for €2.5 million???
<nikolar>
lol what
<nikolar>
what's the average us programmer salary
<nikolar>
like 150k or something
levitating has joined #osdev
<nikolar>
that's like 16 years
<sortie>
I could definitely do something way better than Minix with 16 years :)
<nikolar>
krk
<nikolar>
get intel to use sortix in the me
<nikolar>
instead of minix
<heat>
>Sortix is close to being a viable server platform for the cloud
<heat>
definitely not?
<heat>
servers have like 100 cores
<heat>
you're running an individual sortix instance for each?
<nikolar>
heat: i think replacing minix for intel me is more viable :P
<sortie>
The MORE INTERESTING aspect is the existence of government funds that pay this much for open source development?
<sortie>
1) Get such a grant 2) osdev
<sortie>
heat: Hey I
<nikolar>
how do you pitch your os to dev then
<heat>
nikolar, i suspect intel me is super far from minix
<sortie>
heat: Hey I'm the one of us that's actually running their OS in production :
<sortie>
:P
<heat>
weird bastardized fork of minix passed around in .zips
<heat>
sortie, fair enough
<sortie>
Heck like you said doing SMP is probably not that hard just a bunch of work
<nikolar>
heat: i'd like to know what they are doing nowadays
<nikolar>
is it even stil minix
<sortie>
Cloud instances are usually small-to-medium and there's a lot of them
<heat>
sortie, doing smp is really hard, doing crap smp is easy
<sortie>
Sounds Good Enough® to me with crap SMP
<heat>
openbsd has crap smp and it can't scale past 4 cores
<sortie>
The Sortix kernel has way better locking than OpenBSD anyway with a few notable exceptions I can work on if they actually bottleneck
<heat>
does it?
<sortie>
Generally fine grained locks all written to be preemptive
<heat>
>all written to be preemptive
<heat>
that's kind of a problem
<sortie>
heat: But yeah Sortix actually works very well as a server. The init system is nice. It has ports of key server packages. I would like a port of cloud-init and then a disk image with autoresize might work well enough as a cloud instance
<nikolar>
heat: rcu everywhere then?
<sortie>
Not saying there's more to do, definitely is, but a lot of stuff just has to be 'good enough' to tick off the boxes
<heat>
i don't think you're ready to find out that my in-kernel PRNG can actually visibly contend in a flamegraph on a "exec lotsafuckingtimes" bench, with just 4 cores
<heat>
because it just Has A Lock
<sortie>
Hey I'm just saying I might beat OpenBSD with some work but that's like a low bar
<heat>
indeed
<sortie>
The big thing I have going for me is that my kernel is _small_ and _simple_ which makes it way easier to optimize and redesign as needed
<heat>
small and simple becomes big and complex
solaare has quit [Ping timeout: 252 seconds]
<heat>
did you see that diff i showed you a while ago? where all i had to do was avoid allocating under a lock?
<sortie>
It's always an ongoing eeffort to keep simplicity
<heat>
it becomes a total mess
<heat>
and it's still not perfect, and i may need to adjust it, because i dont guarantee forward progress
<sortie>
I do joke that the supported way to scale Sortix is to spawn more cloud instances but that's legitimately the way to scale very big
<heat>
linux can legitimately scale very big
<heat>
freebsd can also do it
<sortie>
At one point it's just one machine
<sortie>
And your big workflow has to be split across many
<heat>
the linux rcu implementation is said to scale to a couple thousands of cores
<heat>
(would love to know what kind of machines this big they test on)
<sortie>
Probably mainframes and such
<sortie>
For people that can't afford z/OS
<sortie>
heat: What are your thoughts on making money off osdev?
<heat>
lol lol lol lol lol
<heat>
you either hit a really specific niche and get really popular and see people donate (serenityOS)
<heat>
or you're doing it for free, forever
<heat>
the best way of making money off of osdev is getting a real good job off of it
<sortie>
Yeah that was one of my thoughts too, stuff like doing a Patreon and relying on a community project and hype
<sortie>
heat: Oh I already did that. They laid me off once they realized just how much money they paid me and what my savings are now
<nortti>
I do feel hype is probably going to be very hard to generate with more backend-focused projects
<sortie>
I mean I'm not opposed to making Sortix a desktop experience too
<sortie>
idk I do feel some legitimacy about hype if the operating system can actually be put to production use?
<heat>
sortie, keep doing it? it's not like there's a shortage of kernel or low level jobs out there
<heat>
technically making money doing ""osdev""
<sortie>
heat: Literally looking for those jobs. Feel free to suggest great companies to do it for
<heat>
kernel?
<sortie>
Kernel, distribution level stuff, you know I can do it all
<heat>
i don't know what kind of things there are in denmark
<sortie>
I'm not opposed to a remote role
<sortie>
Although I do prefer a fun office
<heat>
but red hat, suse, canonical are always decent bets. oracle is deeecent too (depending on what you're working on, probably, but AFAIK the linux side is chill)
<heat>
collabora probably gives you a lot of freedom
<sortie>
I'm gonna rule Oracle out by default
<heat>
why?
<sortie>
Cus Oracle
<sortie>
I have been seriously looking at canonical but I'm not hearing great things
<heat>
canonical's interview process is insane yeah
<heat>
oracle is seriously decent and they drive a good bit of linux kernel development
<sortie>
ok I will reconsider my opinion of them then
<heat>
you might also get lucky with ARM, and i do know they have offices in norway
<sortie>
ARM is interesting too good pont
<sortie>
*point
hwpplayer1 has quit [Quit: I'll be back later thanks all !]
<heat>
intel's in a tough spot, but they have offices in germany, poland and finland. amd has an office in germany. google (lol) does a lot of low level stuff in poland too. facebook does a lot of kernel stuff in switzerland
<zijjgfs>
did you consider that maybe he doesn't wanna get any job? :^)
<heat>
cloudflare has a really small kernel team so you're probably not lucky there, but they're flexible
<sortie>
zijjgfs: ... I may definitely be a tough sell at this point
<heat>
i'm just spillin the beanz on what i know wrt this kind of stuff in europe
<heat>
because it's definitely not trivial to be picky here
<sortie>
heat: This is extremely useful btw
<zijjgfs>
the entire conversation is framed from this point of view where you desperately want to do labor for somebody else
<sortie>
zijjgfs, right? Like you're supposed to. And I actually don't have to.
<FireFly>
I mean getting hired at google would be the kinda popcorn option
<zijjgfs>
yeah, it's like you could swear the world is filled with SlaveBot 9000s who have an irrational desire to work really hard to make lots of money so that they can go blow their money away by using it inefficiently on overpriced garbage
<heat>
what's the alternative? hobo it out?
<kof673>
it has to be that way for things based on credit basically
<kof673>
they are going to inflate you whether you like it or not
<zijjgfs>
alternative is to die yea
<sortie>
Look as a shareholder in the economy I tend to think that is a little bit dark if maybe accurate way of seeing it zijjgfs
<kof673>
^^^^^^^
<heat>
ah okay, alternative is to die
<heat>
sortie, i didn't mention that you could also not do anything and just die
<heat>
it is a choice.
<sortie>
heat eh I could worry about that ten years from now
<FireFly>
sortie: on the distro side of things there's certainly suse, redhat etc too
<sortie>
FireFly, do you know if those companies got a better rep?
<zid>
we're all going to die in the water wars in 2038 anyway
<sortie>
Sortix has 64-bit time_t I'll be laughing from my derelict ship
<FireFly>
I know someone who used to work at opensuse and seemed pretty happy with it afaik, and used to know someone who worked at redhat once upon a time, but admittedly might've changed since too
<zid>
note the water wars are nothing like waterworld
<FireFly>
idk canonical is the only one of those I've heard actively bad things about
<heat>
suse afaik is fine, red hat is... complicated
heat has quit [Read error: Connection reset by peer]
<sortie>
FireFly: Hey lack of a signal is a signal :)
heat has joined #osdev
<sortie>
What's complicated about red hat, heat?
<heat>
work culture may be getting a little... tough, as far as I've heard
<FireFly>
that's a bummer :o
<sortie>
heat: Oh?
<heat>
yeah.
<kof673>
mjg turned out ok........
netbsduser` has quit [Ping timeout: 246 seconds]
<kof673>
<sees puzzled looks> what?
<heat>
i don't have plenty of details, but it's definitely not the first complaint i've heard wrt RH
<FireFly>
it was mentioned already but like, there's always the route of applying for grant money if you have an interesting idea for a project that'd be beneficial to the EU/open internet/etc kinda things.. though admittedly I guess the future of NGI Zero is a bit shaky now what with not getting allocated funding for next year IIRC
<sortie>
NGI Zero?
<FireFly>
grant fund funded by the EU to support development of modern/open internet things
<heat>
ofc you could try to get donations or a grant or whatnot, but that's really flimsy and hard to find
<FireFly>
well "internet", pretty broad scope
<heat>
tannenbaum got a big fuckin grant, but it's also tannenbaum
<heat>
mega hyper PhD writer of books and torvalds hater
<sortie>
heat, I mean, Tanenbaum did literally write the book. Literally using one of his books to prop up my monitor.
<sortie>
But also kinda the wrong person for the job getting that grant. He's never really had some real vision for Minix which is what led to Linux
<zid>
Can we give that grant to no$
<zid>
fucker's homeless half the time
<zijjgfs>
isn't the vision of minix to be as micro of a kernel as possible?
<zijjgfs>
for students to learn off of?
<sortie>
FireFly: Huh that's really interesting. These projects are all getting funding?
<FireFly>
sure seems so
<sortie>
zijjgfs, it's the learning aspect that's at fault here
<zid>
same with riscv
<zid>
they're both shite
<zid>
intentionall
<heat>
freebsd this year got ~647000 moneyroos
<zid>
then people tried to 'extend' them to make them 'useful'
<heat>
and they have big corporate backing
<heat>
"big"
<zijjgfs>
zid: but the fact remains that people try to "extend" them
<heat>
minix is dead
<zijjgfs>
i don't see anybody trying to extend, say, Linux
<heat>
lol
<zid>
heat: now say it about riscv, pretty please
<sortie>
FireFly: I mean Sortix probably does quality in the big scheme of things as being as fund-worthy as a CI system for GNU/Hurd
<zijjgfs>
except corporations who just keep spewing bloat
fedaykin has quit [Quit: leaving]
<heat>
corporate contributions = bloat
<heat>
personal contributions = glorious open source all praise the bazaar
<zid>
corporate contributions aren't vegan
<FireFly>
sortie: dunno, I'd find it easier to motivate the latter
<zijjgfs>
minix is small enough that somebody can look at it and think "hmm this is simple and solid enough to base my <domain specific thing> off of
<zid>
they require human exploitation and suffering
<FireFly>
I mean depends on what the practical benefits and applications are of continued Sortix dev
<heat>
do you know what linux is?
<zijjgfs>
"extend" in this context is not the same as contribute
<heat>
it is the thing everyone bases shit off of
<heat>
no one uses minix except intel. literally no one
<heat>
sorry, maybe a couple of blokes
<zijjgfs>
to extend, i would argue, is where somebody forks and takes ownership of it to add the features they want and steer the project into their vision
<FireFly>
I was idly messing around with seL4 a bit, maybe I should get back to that, seems cute and is interesting how you can use it as a VM hypervisor too
<sortie>
FireFly: Although I'm not there, Sortix with some work, will be able to offer a really understandable system with a clean design, which is powerful and can be put into production, with great documentation, and I think I can reach some really high levels of security too (needs a bunch of work, inb4 our hot friend interjects)
<sortie>
Security in Sortix is slightly missing, but because the code is all high quality and not infinite, it's actually really easy to harden
<zid>
(Will need running through a formatting tool before being seen by impressionable youths)
<FireFly>
I guess you'd have to motivate why hardened Sortix would be the choice vs either going the route of hardened BSDs or so that are more established and well-tested with presumably more HW support, and on the other hand something like seL4 or similar that's approaching from a formally-verified-kernel direction instead
<FireFly>
or well, what it brings to the table
<FireFly>
but maybe?
<sortie>
Sortix can also offer a much smaller attack surface since the system is much smaller and has much less bloat. Contrarywise, it is unproven in production, so even once I declare it secure, someone's gotta find a way in
<sortie>
FireFly, yeah, just bouncing off the head of what I got :)
<FireFly>
sure
<heat>
can i be a little mean
<sortie>
But there really is something to be said about making a clean new system and not spending time actively making messes for compatibility and misguided features
<sortie>
heat, please do, but I mean Sortix is _not_ there. But it could get there.
fedaykin has joined #osdev
<heat>
there's no reason why anyone would use sortix over another unix system
<heat>
in fact it's really hard to justify $UNIX SYSTEM over linux
<sortie>
Oh definitely. I'm in play if they consider BSD. If not then yep they defaulted to Linux
<sortie>
But also. Some people like unikernels and all that?
<heat>
freebsd is really hard to justify, netbsd is impossible to justify, openbsd is really hard to justify (but has its own loyal followers), dragonflybsd is absolutely impossible to justify
<sortie>
But there could be a room for something very lightweight and secure
<heat>
at the end of the day, all of these systems are just unices, and it turns out linux UNIXes better than everyone else
<sortie>
dragonflybsd's upgrade method is to build from source.. yep not serious for production
<FireFly>
I'm not sure going that direction with sortix would pan out, but I could absolutely see room for some interesting osdev/distro-y projects that help bring something new to the table and solve some problem
<sortie>
I mean it's also not that binary. Sortix has proven itself quite flexible at being adapted to different situations, so it could totally play multiple use cases here.
<heat>
like, say you're not netflix. why would you use freebsd? linux with extra headaches? is it worth it to own the libs-uh i mean the GPL fans
<sortie>
I do know the desktop experience use case is pretty impossible to win, which is why I'm thinking server use cases could be won
<sortie>
heat, good point, Sortix is ISC-licensed rather than GPL, that will have some sway for some uses
<FireFly>
I still have to agree with heat here, I don't really see why one would opt for sortix
<FireFly>
(and more to the point I don't see the angle for asking for funding for it)
<sortie>
I agree too. My argument is very lightweight even if I did all of these things
<heat>
server use cases is even harder because being a good server side OS is reaaaally hard
<heat>
client can get away with being less awful
<heat>
s/less/more/
<bslsk05>
<heat*> client can get away with being more awful
<sortie>
I'm not sure about that. What stuff do you see as a problem with being a good server?
<zid>
really complicated tcp and io hacks
<heat>
performance, scalability, features, high bandwidth networking, dealing with all sorts of weird edge cases, observability support, driver support
<zid>
they'll bench a webserver on it and if it's 1% less, you lose by default
<sortie>
I tend to think drivers for servers are easier
<zid>
nah they're harder
<sortie>
Especially cloud platforms
<heat>
you would be wrong
<heat>
cloud platforms yes
<zid>
cus you actually have to support the 16 cpu round robin interrupt delivery mode
<zijjgfs>
what's the reason why people optimize?
<zid>
else it will do precisely 0 work
rb has joined #osdev
<heat>
even clients are really fucking complex these days. there was a report from the google side in the LKML of apps launching ONE HUNDRED THREADS at startup
<FireFly>
that doesn't entirely surprise me somehow
<zid>
heat does onyx support any weird backplane protocols that only servers use and the rest of us have never heard of
<heat>
sadly, no
<heat>
im sure i can squeeze in NVME-over-fabrics
<zijjgfs>
gotta go sonic hedgehog fast so that they can compete against others to become the winner of usershare, so that way when it gets put into use... what's it being used for... to send TickTock videos over QUIC 2.0 or something?
<heat>
or NVMe-over-tcp
<heat>
iSCSI
<zid>
what's that thing they use instead of ethernet
<zijjgfs>
i remember there being an xkcd comic about this
<zid>
at big internet places
<childlikempress>
clients 'get away with' sucking because there's no incentive to make them good :s
<heat>
nvlink?
<zid>
I used to know but now I don't
<zid>
nvlink is SLI
<heat>
nvlink is also the backbone for a lot of GPU/AI shit I believe, at least
solaare has joined #osdev
<zid>
yea it was designed for the little IDE ribbon that went between two gpus for SLI
<zid>
I assume they co-opted it for likkle clusters
<heat>
infiniband?
<FireFly>
hmm I know there is conductive thread, wonder if you could actually pull off NVMe over literal fabric
<heat>
lol
<kof673>
this makes me think ip over pigeon but the message is just a decoy, they have small wifi or something as they fly
<zid>
yea infiniband, but maybe I was also thinking of MPLS
<FireFly>
homing pigeons with flash storage _does_ have pretty high bandwidth tbf
<zijjgfs>
MPLS goes on top of ethernet
<zid>
right, because ethernet is too fancy for datacenters
<heat>
MPLS sounds like a south american guerilla group that lives in the jungle
<zid>
you want to bulk transmit a gajillion packets and just need them to show up at one of 4 other datacenters
<zid>
so you add a 2 bit tag to 'shortcut' all the routing
<zid>
instead of checking all the headers and using routing tables and shit
<zid>
"fuck the internet it's complicated"
netbsduser` has joined #osdev
<heat>
yep.
<heat>
quick, choose between like 10 different congestion methods
<sortie>
acid
<heat>
that's a good choice. fuck this, take acid
<nikolar>
sortie: good idea, burn through all of the routers
<nikolar>
disolve them into nothing
<sortie>
It's the only way to be sure
<zid>
if you use just enough acid you might get some pretty die shots
<nikolar>
zid: that's a bonus
<zid>
like the swiss flag
<zid>
it's a big plus
<heat>
oh, the best part of being a server side OS is when some random IDIOT asks you for ZFS
<heat>
"yeah bro it has snapshots"
<nikolar>
heat: you're hating on zfs a lot for someone who hasn't used anything but ext4 :P
<heat>
the rest is acceptable, but as soon as someone asks you for an opensolaris compatibility module, you have to be out
<heat>
yes, zfs is my rust
<zid>
zfs is great, I'm sure, for the 5 people with a use-case for it
<zid>
nobody has met these 5 people
<zid>
but they apparently exist
<zid>
and we must all suffer
<nikolar>
i use zfs
<zid>
for 0 reason
<nikolar>
how are you suffering
<heat>
see, nobody has met these 5 people
<zid>
because you're being a vegan iphone user
<zid>
about it
<nikolar>
i didn't even bring it up lol
<FireFly>
classic hash osdev conversation
<zid>
You're the one who flamed
<heat>
there's this guy in #xfs that sometimes pops in and thinks really hard about filesystems. like, why doesn't everyone use the same filesystem, or what filesystem is the best at iterating through a directory with 4356 files
<zid>
nice
<zid>
vin but for filesystems
<heat>
yes
<nikolar>
lel
<zid>
nikolar why hasn't a really hot punk girl hit me with her moped and caused a robot to grow out from under the wound in my head yet
<heat>
not only have i been sick for the last few days, now my wisdom tooth is also fucking killing me
<nikolar>
because there isn't a massive iron in the middle of your town
<heat>
i hate this.
<zid>
The 'one industrial employer for my town' is a fucking mine
<zid>
and a factory that makes chips
<zid>
just to be extra british
<nikolar>
lol
<Ermine>
MPLS
netbsduser` has quit [Ping timeout: 265 seconds]
<Ermine>
fwiw porting wireguard should be ezpz, but in-kernel crypto...
levitating has quit [Read error: Connection reset by peer]
<kof673>
i just keep thinking you guys must really love minneapolis :D Mpls Downtown Improvement District - Minneapolis www mplsdid com a concrete jungle sure :D
netbsduser` has quit [Ping timeout: 252 seconds]
Left_Turn has quit [Read error: Connection reset by peer]