00:03religiousmess: We are developing a safety system based of real coding guidelines. USA get's a deliberate ban from all those systems, their military was the force of conspiracy and involved in deliberate fraud trying to kill me, though as always US jews more likely rather than anyone else from United States were and are behind such tyranny and scams.
00:05gfxstrand[d]: cubanismo[d]: Typically, you pick the smaller of the two, if all you care about is tiling. But for different GOB types... Now sure. We could also pick a plane and say that modifier is for that one and you infer the other. Or we could add another thing just for NV12.
00:21cubanismo[d]: As long as we can agree on a convention such that NVK, DRM-KMS, and the proprietary driver all behave consistently, I don't care that much. I think I vote for just picking the sector layout/modifier you'd get for the first plane, but I'm going to think about it. I'm worried something is going to break in Vulkan where you can very explicitly access all the different planes of YUV images.
00:21cubanismo[d]: Or at best, I'm going to have to write a ton of "But also allow this" stuff there to accommodate it.
02:20x512[m]: Managed to get NVKMS working on Haiku. Previous tests were on Linux.
05:29startofpipeload: some things AI does today is pretty good, for an example it can say what most hardware does today without any visible false positives. But most thing it does is not yet regulated with proper speed nor memory management, so i have been correct in any of the talks i did offer, including hyperthreading being vulnerable , so the ethernet card is also always vulenrable since they employ a
05:29startofpipeload: processor that forwards several tcp packets per cycle pipelined.
05:30startofpipeload: so to measure pipeline depth on those processors is just a matter of getting stream correct.
09:43airlied: TimurTabi: the dma bits patch broke my GB203 bootup
11:25rulesofgod: hyperthreads have no execution unit, so if value is written it needs to know the register of core2 but that could only happen through the memory, but atom is indeed x86 where load operation can take x86 register. So hence rndis should still be vulnerable. So the tcp stack needs to push repeatedly from same memory, and hence as told atom z2760 is still vulnerable even at layer of tcp, since
11:25rulesofgod: when you push you push to memory, next corrupting package reads that memory and has to corrupt the register, hence tcp corrupts the memory with correct timing, and processor corrupts the register therefor, this is something like if push immediately, load rX , case flags=!push things get rejected, so it all boils down to internally corrupting the conditional. That is round about how
11:25rulesofgod: libdimentio works too, which was designed to jailbreak apple products. So the perspective is it has two possibilities to implement the conditional, with ld repeatedly or jump to the routine, and both are vulnerable, so if you do not jump you can not call the conditional again. self-modifying code vs hardware vulnerability that is. And the payload to execute root codes i showed as to how to
11:25rulesofgod: assemble.
20:19santosnobili: TCP/UDP checksum calculations can not be done in bus locked environment (since the data has to be fully received to do that(in which case nic card needs a memory bus), but putting piggybacked PSH onto stream will reorder the memory transactions on the bus possibly corrupting anything that cpu is about to receive from memory bus if locks can not be held). It's peak closed tail open and vice
20:19santosnobili: versa situation imo. So you are thinking of cpu cores having their own dma channels, where checksum is done on one thread and parsing on another one, in which case somehow the cpu core which controls the bus holds the lock, while the calculator of needs the bus? yeah well that makes zero sense.
20:58Lyude: karolherbst[d]: ack on the bug, sorry I didn't notice this until just now!
21:09karolherbst: actually.. this one is different 🙃
21:10HdkR: Too many capital letters in the alias to match :D
21:10karolherbst: I think I'll just add all of protons ranges..
21:18funderscore: w/89
21:18funderscore: great
21:24karolherbst: not sure it's the smartest idea to connect with a private IP address 🙃
21:27dwfreed: did you mean to make that /32
21:28karolherbst: yeah...
21:29karolherbst: does it also work without it if it's just part of the "Actual host"?
21:30karolherbst: dwfreed: also.. I was wondering.. is anybody in #llvm aware that nobody sees any messages? Because I think if you have m and z set, but no active operators, all messages go into the void, no? Though maybe that's intentional as everybody else would just use discord? Just something I've noticed today...
21:32dwfreed: The +m is intentional, the +z I forget
21:32dwfreed: re /32, it's redundant regardless; IP bans match IPs even if the visible host is a proper rDNS
21:34karolherbst: dwfreed: what I mean is, that with +z only active ops will see the messages, not people who are allowed to op themselves, right?
21:34karolherbst: ahh
21:34karolherbst: okay
21:35karolherbst: but yeah, /32 on that one, because it's like Celluar network and I'd rather not ban others by accident
21:35dwfreed: karolherbst: correct, only people who *currently* have +o will see messages; if there are none, then the messages really do get tossed into the void
21:36karolherbst: yeah.. I don't see ops in #llvm that's why I'm wondering
21:38dwfreed: looks like the +z is from a *long* time ago
21:39dwfreed: one would argue it's a feature, rather than a bug :D
21:39dwfreed: s/would/could/
21:40karolherbst: :D
21:40karolherbst: yeah just sucks being somebody who wants to ask something and gets no replies back
21:40dwfreed: heh, yeah
21:41dwfreed: once I get a proper handle on things, I might ask if they'd be interested in running dibridge like you do