| --- Log opened Mon Mar 27 00:00:47 2017 |
| 00:14 | | Kindamoody is now known as Kindamoody[zZz] |
| 00:16 | <&McMartin> | His talk's endpoint is kind of amusing, as someone who in fact writes 16-bit ring-0 asm as a hobby. |
| 00:16 | <&McMartin> | That final core kernel ends up looking a whole lot more like an expanded DOS. |
| 00:17 | <&McMartin> | ... which in turn means you can probably jam it into a single UEFI module and hand it the keys to the whole system. |
| 00:19 | < RchrdB> | which bit are you talking about? the punchline of B&DoJS where he talks about Linux+V8 running without any need for hardware memory protection because the V8 sandbox doesn't have holes? |
| 00:19 | <&McMartin> | Right. In that architecture, "Linux" is providing nothing more than a set of interrupts for I/O. |
| 00:20 | <&McMartin> | Which are no longer even interrupts |
| 00:20 | < RchrdB> | I had two quibbles with the details of that. One is that, dammit Gary, making two different changes that affect performance will not necessarily result in a new performance number that is the product of the relative speedups! |
| 00:20 | <&McMartin> | (Well, OK, the asynchronous I/O parts are.) |
| 00:21 | < RchrdB> | the other quibble is that it seems really unlikely that a perfect sandbox will ever exist, but I could probably be proven wrong |
| 00:22 | <&McMartin> | Well, I mean, hardware protection doesn't save you there either |
| 00:22 | <&McMartin> | cf Heartbleed. |
| 00:22 | < RchrdB> | I think you mean Rowhammer, not Heartbleed. |
| 00:22 | <&McMartin> | Actually, no, I mean any of the thousands of bugs in between them, come to think of it. |
| 00:23 | < RchrdB> | Heartbleed was "OpenSSL accidentally discloses memory contents". |
| 00:23 | <&McMartin> | Yeah, I'd forgotten and thought it was the network kernel component doing the accidental disclosue |
| 00:23 | <&McMartin> | Leaking data through the hardware protection interface to the detriment of system stability is a broad class of bug though. |
| 00:23 | <&McMartin> | So "The kernel won't be a perfect firewall" isn't much of an argument, overall |
| 00:24 | <&McMartin> | The part where this does get relevant is when facing the question "so, how important is it, actually, to have a multiuser machine that has multiple processes running at once" |
| 00:24 | < RchrdB> | Rowhammer is "you can change the values of memory contents in pages that you aren't actually allowed to access according to your page tables, by triggering defects in your RAM, just by issuing reads and writes to memory in a pattern that causes rows to get reloaded a lot and make some capacitors get discharged to below the threshold voltage in between DRAM refresh cycles" |
| 00:24 | <&McMartin> | Right. |
| 00:25 | <&McMartin> | Rowhammer is more fundamental than I was going for there |
| 00:25 | <&McMartin> | Your objection here seems to be "V8 will have bugs", and my reply is "so will kernels" |
| 00:25 | < RchrdB> | Oh right but there are degrees |
| 00:25 | <&McMartin> | Indeed, and I see two countervailing forces pulling in opposite directions |
| 00:25 | <&McMartin> | That if you synthesize them do kind of give you his endpoint. |
| 00:26 | < RchrdB> | the attack surface of V8 is, I think, bigger than the attack surface of a hypervisor |
| 00:26 | <&McMartin> | Force 1 is to push for smaller and smaller kernels |
| 00:26 | < RchrdB> | (hypervisor slash kernel) |
| 00:26 | <&McMartin> | We've basically given up on microkernels in practice but hypervisors as the new meta-really-small-kernel is gaining in popularity and is itself a very old idea indeed going back to the mainframe era |
| 00:27 | < RchrdB> | IMHO hypervisors count as microkernels but with new branding. |
| 00:27 | <&McMartin> | I disagree because I cast them as VM/CMS with new branding :D |
| 00:27 | <&McMartin> | And once you have *that*, that enables wider use of the thing that's showing up from the thread of thought that asks "what should an IoT device *actually* look like, because it's sure as Hell not a stock and unpatchable Linux image YOU IDIOTS RARRRRGH" |
| 00:27 | < RchrdB> | AFAIK lots of embedded applications are using microkernels for realsies too. |
| 00:28 | <&McMartin> | BSD is kind of considered one, I think. |
| 00:28 | < RchrdB> | like actual honest-to-betsie L4 |
| 00:28 | < RchrdB> | Hm? FreeBSD, OpenBSD, NetBSD all have monolithic kernels. |
| 00:28 | <&McMartin> | Past a certain point you are handwaving, like asking how many instructions you can have before you stop being "RISC" - it's the wrong question. |
| 00:28 | <&McMartin> | Hm. What am I thinking of |
| 00:29 | < RchrdB> | Were you thinking of OS X? OS X started out as a fork of a microkernel called Mach but it isn't a microkernel any more. |
| 00:29 | <&McMartin> | Probably. |
| 00:29 | <&McMartin> | MachO needs to find a series of fires to die in |
| 00:29 | < RchrdB> | I mean OS X's kernel started out as a fork of Mach |
| 00:30 | <&McMartin> | Mach itself was argued to be monolithic too, it seems. |
| 00:30 | < RchrdB> | mmmmmmmmeh |
| 00:30 | <&McMartin> | Anyway |
| 00:31 | < RchrdB> | This conversation will be more productive if we ban asking "is it a microkernel?" and switch to asking "how large is the trusted code base?" |
| 00:31 | <&McMartin> | I can imagine a system that says "I have a hardware abstraction layer and I only run code that I JIT myself from a bytecode that does not permit arbitrary pointer arithmetic or self-modifying code" |
| 00:31 | <&McMartin> | "And therefore I never leave Ring 0 because I don't have to" |
| 00:31 | <&McMartin> | I can *imagine* it |
| 00:31 | < RchrdB> | Do you know MirageOS? |
| 00:31 | <&McMartin> | But, well, that's DOS with execution prevention. |
| 00:31 | < RchrdB> | *about |
| 00:32 | <&McMartin> | If I do it's not swapped in. |
| 00:32 | < RchrdB> | okay so there's a cute idea called a unikernel |
| 00:32 | <&McMartin> | ... OK, looking that up |
| 00:32 | <&McMartin> | Yes, this is exactly the architecture I am envisioning |
| 00:33 | <&McMartin> | This is also what I think IoT devices should probably be doing instead of being fuckin' IoT devices. |
| 00:33 | < RchrdB> | <hypothetical scenario> I write a webapp. I build and ship a VM image containing Linux, nginx, my web app. </hypothetical scenario> |
| 00:33 | < RchrdB> | Now in this scenario, all of (linux, nginx, my app) are actually the same trust domain. |
| 00:33 | <&McMartin> | Yep |
| 00:34 | <&McMartin> | Also: I am very familiar with Exokernel, as it happens. |
| 00:34 | <&McMartin> | Engler was *also* on my thesis committee =P |
| 00:34 | < RchrdB> | In this scenario, if any piece of that software gets broken, it's the same to me as if any other piece of it gets broken |
| 00:34 | < RchrdB> | so I may as well run all of it as root |
| 00:34 | < RchrdB> | maybe I might as well run it all in ring 0 too |
| 00:35 | <&McMartin> | Yep |
| 00:35 | < RchrdB> | and so hell, maybe I'll just solve this problem instead by shipping a single binary that runs in ring 0 (atop a hypervisor in practice) which contains the virtio drivers and TCP stack as libraries |
| 00:35 | <&McMartin> | I heartily endorse this approach to software development and deployment. |
| 00:36 | < RchrdB> | MirageOS is a toolkit for writing unikernels in OCaML. Some of the practical issues that you'd have with "oh god are you really suggesting I put all this C++ code in ring 0?" are alleviated by it being ML instead of C++. |
| 00:36 | <&McMartin> | The rest being "what else are you protecting from this code?" |
| 00:36 | <&McMartin> | "... nothing, right? Right. Well then." |
| 00:37 | < RchrdB> | I had a go at reading some of the exokernels literature and, um |
| 00:37 | <&McMartin> | What you've really done here is reinvent software-on-cartridge for PCs, just without the actual cartridge part |
| 00:37 | <&McMartin> | And without the single-tasking nature because you've got a hypervisor covering the rest. |
| 00:37 | < RchrdB> | it was cool but I think the unikernel + library-OS approach has less complexity |
| 00:37 | <&McMartin> | Yes |
| 00:37 | < RchrdB> | I mean unikernel + hypervisor |
| 00:38 | <&McMartin> | Yep |
| 00:38 | < RchrdB> | because the exokernel paper I saw had a horrendously complicated ABI for stuff like... userland programs to pass bytecode to the hardware multiplexor so that it could work out which pages of disk mattered and stuff like that |
| 00:38 | < RchrdB> | "hardware multiplexor" being the exokernel's... kernel |
| 00:39 | <&McMartin> | Yeah, I think the only one I really took seriously was the introductory paper which was called something like Destroy All Operating System Abstractions |
| 00:39 | <&McMartin> | The rest is, well, a post-apocalyptic wasteland after you destroyed everything you used~ |
| 00:39 | < RchrdB> | it seemed to me that there were lots of places where you couldn't plausibly build a secure exokernel system because the ABI was too complicated and too hairy to implement without accidentally leaving bugs in. |
| 00:39 | < RchrdB> | two more things you might like |
| 00:40 | <&McMartin> | Graphene seems like the sort of middleground between Unikernel and Full OS that's more relevant to the talk's endpoint. |
| 00:40 | < RchrdB> | NetBSD has a thing called "rump kernels" where they've got the NetBSD kernel carved up so that you can easily pick code out of it and run it as an ordinary binary in some process on some other operating system (or maybe even on no operating system) |
| 00:42 | < RchrdB> | and there's a concept called a "library OS" where, uh, your program gets presented with a raw hardware interface *but* there's a library containing all the device drivers to hand |
| 00:42 | <&McMartin> | I've been frantically wikiwalking and bouncing through papers and repos during this conversation |
| 00:42 | < RchrdB> | sorry |
| 00:42 | <&McMartin> | And "library OS" seems very tightly bound to or close to the "unikernel" concept |
| 00:42 | <&McMartin> | (Graphene seems to call itself one, for one) |
| 00:42 | < RchrdB> | Yes. A library OS is one of the components of a unikernel. |
| 00:43 | < RchrdB> | You write your program and link it with a library-OS and the artefact you've built is a unikernel. |
| 00:43 | < RchrdB> | You can write your program without bothering with the library-OS too, and you'd still get a unikernel, but to do that you'd have to write the network driver and TCP stack yourself. |
| 00:48 | < RchrdB> | McMartin, okay now just to make your day worse, I'm going to suggest that possibly the optimal thing for performance and maintainability is to not do so much of this, because kernel-bypass networking is actually just about as fast as putting your webserver or whatever into ring 0. https://github.com/lukego/blog/issues/13 |
| 00:49 | <&McMartin> | Heh |
| 00:49 | <&McMartin> | So, does doing that make you more or less like Basically DOS~ |
| 00:50 | < RchrdB> | "kernel-bypass networking" is where you run your program on an ordinary OS like Linux, Windows or BSD. The OS is configured to *not* load a driver for the computer's NIC. Instead, the kernel memory-maps the MMIO pages for your NIC into your program's address space and your program drives the NIC directly again. |
| 00:50 | <&McMartin> | The core thesis here - that a modern OS kernel is too large for the tasks we put on them - stays strong |
| 00:50 | <&McMartin> | ... I'm down with that, though that's turning you less into a DOS machine and more into a Commodore 64. :D |
| 00:50 | < RchrdB> | and there exists a concept called "kernel-bypass storage" where you do that except with the hard disk controller |
| 00:50 | < RchrdB> | etc |
| 00:51 | <&McMartin> | Do modern x86 chips permit use of IN/OUT instructions in ring 3? |
| 00:51 | < RchrdB> | except that kernel-bypass storage doesn't get as much attention because until very recently storage devices weren't fast enough for this kind of approach to be interesting |
| 00:51 | <&McMartin> | I would also imagine that if the answer to my question above is "no", then there is also the minor issue of "also you literally cannot talk to the hardware outside of the kernel most of the time" |
| 00:52 | < RchrdB> | No. You don't use IN/OUT though. Instead you use memory-mapped IO. |
| 00:52 | <&McMartin> | OK, next question |
| 00:52 | < RchrdB> | so there's a range of physical addresses that don't actually correspond to RAM in your DIMMs, instead those addresses correspond to registers and buffers on your PCI(e) cards |
| 00:52 | <&McMartin> | Right, I'm quite familiar with MMIO |
| 00:52 | < RchrdB> | and the OS is convinced to let you have those specific addresses mapped in and marked writable by your process |
| 00:53 | < RchrdB> | aha |
| 00:53 | <&McMartin> | I've just never seen it available on PCs beyond commanding the VGA's video buffers. |
| 00:53 | < RchrdB> | so the point of this is that, it's the library-OS approach to networking again! and that's great for throughput! but now it's with an otherwise ordinary linux process |
| 00:53 | <&McMartin> | Everything on ISA and - the last I had checked - the basics of PCI as well - were all done purely through the I/O ports. |
| 00:53 | < RchrdB> | so gdb still works |
| 00:53 | <&McMartin> | Yep. |
| 00:54 | < RchrdB> | offhand I'm not sure |
| 00:54 | <&McMartin> | I know nothing of PCIe other than that I thought it was vaguely compatible |
| 00:54 | < RchrdB> | I think maybe Snabb does some stuff with MMIO and some stuff by asking the kernel to touch I/O ports on its behalf |
| 00:54 | <&McMartin> | And of course once you wander out of the x86 ghetto MMIO is usually the only game in town |
| 00:54 | <&McMartin> | So if you're on an ARM system, AFAIK you are 100% golden |
| 00:55 | < RchrdB> | but the things that it has to ask the kernel to touch I/O ports for aren't done lots of times on a per-packet basis |
| 00:55 | | * McMartin nods. |
| 00:55 | <&McMartin> | The DOS soundcode I was messing with earlier this year... whole lot of I/O port work. |
| 00:55 | < RchrdB> | I'm not sure if everything is MMIO now though |
| 00:55 | < RchrdB> | I honestly thought the IN and OUT instructions on x86 didn't have any meaning outside ISA anyway? |
| 00:55 | <&McMartin> | It's part of the chip, not the arch. |
| 00:56 | <&McMartin> | Z80 has them too, which means it must go back at least to the 8008. |
| 00:56 | < RchrdB> | like there is a fixed limit of exactly 256 I/O ports because *jazz hands* that's the instruction encoding |
| 00:56 | <&McMartin> | ... I can state with absolute certainty that this isn't true |
| 00:56 | <&McMartin> | Because the default sound blaster port was 0x220. |
| 00:56 | < RchrdB> | hm |
| 00:56 | <&McMartin> | And the Adlib ports were above that too. |
| 00:56 | <&McMartin> | 65536 ports because that's your register width. =P |
| 00:57 | <&McMartin> | "Because that's your register width" is an entirely reasonable restriction~ |
| 00:57 | <&McMartin> | But even then |
| 00:57 | < RchrdB> | are AL and AH 16 bits or 8 bits? |
| 00:57 | <&McMartin> | I ran some realmode code on a 2012 i7 running FreeDOS |
| 00:57 | <&McMartin> | 8. make AL the low byte and AH the high byte and you have AX. |
| 00:57 | < RchrdB> | gotcha |
| 00:58 | < RchrdB> | I'm looking at http://x86.renejeschke.de/html/file_module_x86_id_222.html |
| 00:58 | <&McMartin> | There is no equivalent to AH for the top 16 bits of EAX or the top 32 of RAX. |
| 00:58 | < RchrdB> | which claims that the OUT instruction accepts either an 8-bit immediate OR an 8-bit register as the destination port number |
| 00:58 | <&McMartin> | Ah, no, you have misread. |
| 00:58 | <&McMartin> | This is using the Intel syntax, not the AT&T syntax. |
| 00:58 | <&McMartin> | Destination is on the left. |
| 00:58 | < RchrdB> | aha! |
| 00:58 | <&McMartin> | OUT DX, AL writes 8 bits to the 16-bit port named in DX. |
| 00:59 | < RchrdB> | hang on are you sure |
| 00:59 | < RchrdB> | "Output byte in AL to I/O port address imm8." |
| 00:59 | < RchrdB> | that's an imm8? |
| 00:59 | <&McMartin> | Yep |
| 00:59 | <&McMartin> | Immediate has to be 8-bit |
| 00:59 | <&McMartin> | No 16-bit immediate mode for this instruction. |
| 00:59 | < RchrdB> | and "Output byte in AL to I/O port address in DX." |
| 00:59 | < RchrdB> | but DX is 16 bits |
| 01:00 | <&McMartin> | Correct. |
| 01:00 | < RchrdB> | right so there are 65535 ports. |
| 01:00 | < RchrdB> | *65536 |
| 01:00 | <&McMartin> | Note that if you output more than one byte, the port increases as you go |
| 01:00 | < RchrdB> | I guess just only the bottom 256 of them can be addressed with an immediate? :) |
| 01:00 | <&McMartin> | Again correct. |
| 01:00 | < RchrdB> | Does it wrap if you use the imm8 form? |
| 01:00 | <&McMartin> | Likewise, if you're going to barrelshift, the only immediate value permissible is 1. |
| 01:01 | <&McMartin> | I have never attempted this and am not sure what lives at port 0xff. |
| 01:01 | < RchrdB> | Does "OUT 255 AX" write AH to port 255 and AL to port 256 |
| 01:01 | < RchrdB> | or does "OUT 255 AX" write AH to port 255 and AL to port 0? :D |
| 01:01 | < RchrdB> | (if I got AH and AL the wrong way around, well, shit) |
| 01:01 | <&McMartin> | I know what you're asking. I'm saying I have never attempted this because randomly poking I/O ports is a bad idea. |
| 01:01 | <&McMartin> | You did get them wrong; x86 is little-endian so AL comes first |
| 01:02 | < RchrdB> | demmit |
| 01:02 | <&McMartin> | In practice you didn't do this because everything you cared about was serialized |
| 01:02 | <&McMartin> | And thus expected two bytes to the *same* port. |
| 01:02 | <&McMartin> | https://github.com/michaelcmartin/bumbershoot/blob/master/dos/sound/fmscale.asm |
| 01:02 | <&McMartin> | See for instance my writeAdlib function on line 63 |
| 01:03 | <&McMartin> | "Write card register number, wait 5 microsec, write new value" |
| 01:04 | < RchrdB> | "Read 6status 6 times" is how you implemented "wait 5 microsec"? :) |
| 01:04 | <&McMartin> | That is the recommended technique, and that *is* a quirk of the ISA bus. |
| 01:05 | <&McMartin> | In that the speed of the ISA bus never increased after the release of the Adlib. |
| 01:05 | <&McMartin> | So IN/OUT end up throttling down the speed of your system to match. |
| 01:05 | <&McMartin> | To, uh, 12 MHz-equivalent, IIRC. |
| 01:06 | <&McMartin> | All Adlib-compatible soundcards that post-date ISA also had logic that did not require any waits. |
| 01:06 | < RchrdB> | Yes. Your ISA peripherals would break if you tried clocking it higher. :) |
| 01:07 | <&McMartin> | It turns out that the PC's programmable interval timers were not quite consistently manufactured enough to handle the timing here. |
| 01:07 | < RchrdB> | wat |
| 01:07 | < RchrdB> | but reading the ISA bus was? |
| 01:07 | <&McMartin> | Yep. |
| 01:07 | < RchrdB> | huh |
| 01:07 | <&McMartin> | Specifically, the way you'd do this without reading the ISA bus was spinlocking on reading the PIT's internal registers. |
| 01:08 | <&McMartin> | That was only ever really intended for wacky corner case debug mode stuff and thus was both incompletely specified in the first place and generally not robust enough to be spinlock hammered even at 40MHz, much less 2GHz |
| 01:09 | <&McMartin> | And that's even before we get to the part where it was probably on the ISA itself so by the *time you set up the damned timer it's been 5 microseconds* |
| 01:09 | < RchrdB> | heh |
| 01:10 | <&McMartin> | Setting up a Sound Blaster apparently requires a 200-300 microsecond wait in there to make sure the reset signal fully sticks |
| 01:10 | <&McMartin> | Best practices there was to use the BIOS tick and overshoot by a factor of two thousand or so~ |
| 01:12 | < RchrdB> | or turn on the reset signal, load some other assets for a bit which should probably take a couple seconds by itself anyway, then check to see if the wait time period already elapsed and if not spin? |
| 01:12 | <&McMartin> | That doesn't seem to have been as common, TBH |
| 01:13 | <&McMartin> | They'd just have it hitch for a quarter second while it did the reset, set up some dummy DMAs, and checked to see if the IRQ came in where it expected, etc. |
| 01:14 | < RchrdB> | I guess in those days nobody *really* cared if the game took ten seconds to load or eight, it was a miracle that anything ran at all in the first place ;P |
| 01:14 | <&McMartin> | Takes a bit longer, but if it fucks up, you don't make the video mode flip out or whatever. |
| 01:14 | | Jessikat` [Jessikat@Nightstar-q5khu9.dab.02.net] has joined #code |
| 01:14 | <&McMartin> | I don't care about the difference between 10 and 9.75 now. |
| 01:15 | <&McMartin> | That said, DOS games were pretty zippy to start up if they were not doing full probes on startup, and really, even if they were. |
| 01:15 | <&McMartin> | It's almost certainly going to be under 5, and probably under 2. |
| 01:17 | | Jessikat [Jessikat@Nightstar-hpgbve.dab.02.net] has quit [Ping timeout: 121 seconds] |
| 01:20 | < RchrdB> | Okay fair. :P |
| 01:20 | | Alek [Alek@Nightstar-cltq0r.il.comcast.net] has quit [Connection closed] |
| 01:20 | < RchrdB> | It's still disappointing to find oneself staring at a bar labelled "loading" when one would like to be playing terrible videogames though. |
| 01:21 | < RchrdB> | http://wiki.osdev.org/PCI is surprisingly fun reading |
| 01:21 | < RchrdB> | there's a lot there so I haven't read all of it yet |
| 01:21 | <&McMartin> | Oh, I'm not counting that part |
| 01:22 | <&McMartin> | But even there |
| 01:22 | <&McMartin> | The last DOS game I played was TIE Fighter |
| 01:22 | <&McMartin> | Apart from the (unavoidable, because no persistent OS config) joystick calibration, there is *no* Obvious Loading Garbage going on. |
| 01:22 | <&McMartin> | It cuts to the LucasArts intro basically immediately. |
| 01:22 | < RchrdB> | anyway it sounds like the deal with PCI drivers in userspace is that yes you need to ask the kernel to fire some IN and OUT instructions at ports 0xCF8 and 0xCFC to read or write PCI registers for you |
| 01:23 | < RchrdB> | and it *sounds* like (though I'm not 100% certain) something like snabb switch would be doing that, eh, at most once every few packets to schedule a DMA transfer |
| 01:23 | < RchrdB> | buuuut |
| 01:23 | <&McMartin> | Ah yes, DMA |
| 01:23 | <&McMartin> | Hmmmm. |
| 01:24 | < RchrdB> | also there's an optional mechanism that PCIe added where the PCI registers are memory-mapped too |
| 01:24 | < RchrdB> | and uh |
| 01:24 | <&McMartin> | If you're mostly doing DMA then making sure that the hardware Gets Your Actual Buffer's Physram would be pretty sweet |
| 01:24 | < RchrdB> | you don't need kernel-bypass networking on NICs that aren't fast enough to need PCIe :) |
| 01:24 | <&McMartin> | And then PCIe gets All The Toys. |
| 01:24 | <&McMartin> | Yep. |
| 01:24 | < RchrdB> | yes |
| 01:25 | < RchrdB> | If you want a slightly fun afternoon reading about why nginx and lighttpd's designs are somewhat enticing, read "the c10k problem" |
| 01:25 | <&McMartin> | Yeah, I'm a much simpler soul than that |
| 01:25 | <&McMartin> | I prefer MMIO because I first programmed graphics and sound with POKE commands in C64 BASIC. |
| 01:25 | | Alek [Alek@Nightstar-cltq0r.il.comcast.net] has joined #code |
| 01:25 | | mode/#code [+o Alek] by ChanServ |
| 01:26 | < RchrdB> | If you want a fun, scary afternoon reading about why Snabb switch and stuff like it are enticing, read "the c10M problem" |
| 01:26 | < RchrdB> | "stuff like it" including Intel DPDK and a few other things whose names I've forgotten |
| 01:28 | < RchrdB> | mm |
| 01:28 | < RchrdB> | No argument that MMIO is a conceptually very clean model |
| 01:29 | <@himi> | Oh hey, Snabb looks like something to keep an eye on |
| 01:29 | <&McMartin> | ... until you have to worry about bus contention, anyway. |
| 01:29 | < RchrdB> | and you can do cute things like grant a process the ability to muck directly with an actual real piece of physical hardware just by giving it access to some MMIO addresses. I'm sure that can't POSSIBLY go wrong. |
| 01:29 | <&McMartin> | MMIO means Shit Has Gotten Real (Mode), yes~ |
| 01:30 | < Jessikat`> | 16 bits of pain |
| 01:31 | < RchrdB> | himi, fwiw, I might be very wrong but I get the impression that, Snabb is kind of about the specific problem of writing applications in userspace on Linux that talk various layer-2 and layer-3 protocols at wire speed |
| 01:31 | < RchrdB> | possibly including switching |
| 01:31 | <@himi> | That appears to be the case, from the doco I just spent about 60 seconds reading |
| 01:32 | < RchrdB> | and that for applications that don't look so much like switching, you might want to look at Intel DPDK and/or PF_RING instead |
| 01:32 | <@himi> | I currently work on OpenStack, so its potential for SDN is what interests me |
| 01:32 | < RchrdB> | not totally sure about that though |
| 01:32 | <@himi> | DPDK is . . . . really hard to get into |
| 01:32 | < RchrdB> | oh bummer |
| 01:33 | < RchrdB> | okay maybe Snabb is more interesting then :) |
| 01:33 | <@himi> | It's far more "enterprisey" than I like to see in my code |
| 01:33 | <@himi> | Yeah, DPDK is targeted at enterprises developing stuff, whereas it looks like Snabb is far more "hey, have a hack at it and see what it's like" |
| 01:34 | < RchrdB> | Y'know what would be a terrible abuse of technology - getting a FreeBSD rump kernel and using it to drive a NIC and TCP stack in userland on Linux *just* so that you can use kqueue() for network sockets instead of epoll(). |
| 01:34 | <@himi> | They're explicitly referencing 50-100Gb switching with Snabb, so performance doesn't appear to be an issue |
| 01:34 | <@himi> | . . . if you're running your TCP stack in userland why would you worry about that kind of thing? |
| 01:35 | <@himi> | I mean, sure, you get an extant TCP stack with nice features, but there are plenty of extant userland TCP stacks out there that have nice reatures |
| 01:35 | < RchrdB> | well the silly point is running a TCP stack in userland instead of using the TCP stack in your kernel but *only* because the TCP stack in your kernel has a shitty API |
| 01:36 | < RchrdB> | whereas kqueue is nicer :) |
| 01:36 | <@himi> | That's just silly |
| 01:36 | < RchrdB> | I did prefix this idea with âY'know what would be a terrible abuse of technologyâ. |
| 01:36 | <@himi> | A userland TCP stack has different behavioural requirements than a kernel TCP stack |
| 01:36 | <@himi> | Very true |
| 01:37 | < RchrdB> | btw, if anyone would like a https://lobste.rs/ invite, hit me up? |
| 01:37 | <@himi> | Oh, that's a lovely starting sentence for an article: Today (2013), $1200 will buy you a computer with 8 cores, 64 gigabytes of RAM, 10-gbps Ethernet, and a solid state drive. Such systems should be able to handle |
| 01:37 | < RchrdB> | it's meant to be roughly "like HN but nicer" |
| 01:40 | < RchrdB> | hey you still can :) |
| 01:40 | < RchrdB> | albeit if you do, you got ripped off? :) |
| 01:41 | < sshine> | RchrdB, you can invite me, too. need an email or what? |
| 01:41 | <@himi> | I was thinking more about the fact that my 200 node cluster, purchased in 2014, is surprisingly similar: 16 cores, 128GB, SSDs |
| 01:42 | <@himi> | The big difference being the Mellanox 56GB NICs |
| 01:42 | < RchrdB> | sshine, yes, invites are by email address. Please PM me or whatever. |
| 01:42 | <@himi> | Also, definitely not $1200 per machine |
| 01:43 | < sshine> | RchrdB, how do you perceive it as better than hacker news? I normally use hckrnews.com and I see that lobste.rs looks much like news.ycombinator.com, so you must mean that the content is better. maybe less talk on venture capital? |
| 01:46 | < RchrdB> | Smaller community. On the current front page, articles 0, 2-9, 12, 14-16, 18-25 are all pretty much purely technical. |
| 01:47 | < RchrdB> | The rest are related to technology, policy and regulation around technology, how to cope with being a human being who does things with technology, etc. |
| 01:50 | < RchrdB> | Glancing at news.ycombinator.com right now I see actual garbage, various bits of general interest fluff, various bits of general interest science. |
| 01:50 | < RchrdB> | surprisingly fewer than usual articles about VC |
| 01:53 | < RchrdB> | Also lobste.rs is much less welcoming to, um, right-wing extremists. Left-wingnuts don't really pop up there either. |
| 01:53 | | Turaiel[Offline] is now known as Turaiel |
| 01:56 | | Jessikat [Jessica@Nightstar-bt5k4h.81.in-addr.arpa] has joined #code |
| 02:01 | < RchrdB> | slep nao <3 |
| 02:06 | < sshine> | RchrdB, sleep well! and thanks for the invite. :) |
| 02:06 | < sshine> | Jessikat, oohh, .in-addr.arpa addresses are so cool! when do people ever have those any more? |
| 02:07 | < Jessikat> | d.. bwah? |
| 02:07 | | * Jessikat shrugs |
| 02:07 | < Jessikat> | my housemate set up the 'net, I guess he's responsible for that |
| 02:07 | < Jessikat> | it's the kind of thing he'd do xD |
| 02:09 | < sshine> | hmm, according to wikipedia, as far as I understand, all IPv4 addresses that don't reverse resolve to a domain can just resolve to <the-ip>.in-addr.arpa. I learned something new today. |
| 02:09 | < sshine> | I suppose the reason they're not common is that you'd have to set up reverse DNS for an IP and specifically not choose a domain. |
| 02:10 | < sshine> | or rather, a normal domain. |
| 02:10 | | * sshine wants to see if his theory is right by setting his VPS rDNS to that as well. :-P |
| 02:29 | | Vornicus [Vorn@ServerAdministrator.Nightstar.Net] has quit [Connection closed] |
| 02:29 | | Vornicus [Vorn@ServerAdministrator.Nightstar.Net] has joined #code |
| 02:29 | | mode/#code [+qo Vornicus Vornicus] by ChanServ |
| 03:01 | | Jessikat [Jessica@Nightstar-bt5k4h.81.in-addr.arpa] has quit [[NS] Quit: Leaving] |
| 03:34 | | Jessikat` is now known as Jessikat |
| 04:57 | | Turaiel is now known as Turaiel[Offline] |
| 04:59 | | Derakon is now known as Derakon[AFK] |
| 05:25 | | Alek [Alek@Nightstar-cltq0r.il.comcast.net] has quit [Ping timeout: 121 seconds] |
| 05:28 | | Alek [Alek@Nightstar-cltq0r.il.comcast.net] has joined #code |
| 05:28 | | mode/#code [+o Alek] by ChanServ |
| 05:47 | | Jessikat [Jessikat@Nightstar-q5khu9.dab.02.net] has quit [[NS] Quit: Bye] |
| 05:50 | | Alek [Alek@Nightstar-cltq0r.il.comcast.net] has quit [Ping timeout: 121 seconds] |
| 05:55 | | Alek [Alek@Nightstar-cltq0r.il.comcast.net] has joined #code |
| 05:55 | | mode/#code [+o Alek] by ChanServ |
| 07:33 | | celticminstrel is now known as celmin|Zzzzzz |
| 09:00 | | Kindamoody[zZz] is now known as Kindamoody|afk |
| 09:06 | <@Pi> | Oh, hey, RchrdB! |
| 09:15 | <@abudhabi> | You sound like shadowfax, Pi. |
| 09:15 | <@Pi> | Shadowfax? |
| 09:17 | <@abudhabi> | Was a bot in another channel. |
| 09:17 | <@abudhabi> | Turing'd people sometimes. |
| 09:18 | <@Pi> | Ah, okay. :) |
| 09:23 | <@abudhabi> | http://zoo.nightstar.net/viewtopic.php?p=299866#p299866 |
| 10:33 | <@TheWatcher> | Seriously, Twitter? Seriously? |
| 10:34 | | * TheWatcher stabs their API coders in the head |
| 10:35 | <@TheWatcher> | Related: I fucking hate DST |
| 10:37 | <~Vornicus> | do they, like, not use gmt |
| 10:38 | | * abudhabi intends to go on a strict static-time regimen in the near future. |
| 10:39 | <@abudhabi> | No changing the damn alarm clocks. No changing session times. Let other people change, if they wish. |
| 10:40 | <@TheWatcher> | Vornicus: I present a sample date from the JSON reply to the user_timeline endpoint: "created_at":"Mon Mar 27 05:00:20 +0000 2017" |
| 10:40 | <@TheWatcher> | Except that was created at 05:00:20 +0100. |
| 10:40 | <~Vornicus> | Okay, so, terrible alr... |
| 10:40 | <~Vornicus> | What. The. Fuck. |
| 10:42 | <@TheWatcher> | I mean, I can work with it, it just... seriously? |
| 11:20 | < RchrdB> | Hello Pi. :) |
| 12:14 | | Jessikat [Jessikat@Nightstar-o6dt1g.dab.02.net] has joined #code |
| 12:24 | | Vornicus [Vorn@ServerAdministrator.Nightstar.Net] has quit [Ping timeout: 121 seconds] |
| 12:51 | | himi [sjjf@Nightstar-v37cpe.internode.on.net] has quit [Ping timeout: 121 seconds] |
| 12:58 | | Jessikat` [Jessikat@Nightstar-o6dt1g.dab.02.net] has joined #code |
| 13:00 | | Jessikat [Jessikat@Nightstar-o6dt1g.dab.02.net] has quit [Ping timeout: 121 seconds] |
| 13:42 | | RchrdB [RchrdB@Nightstar-qe9.aug.187.81.IP] has quit [Ping timeout: 121 seconds] |
| 13:53 | | * TheWatcher grumbles at users |
| 13:53 | <@TheWatcher> | I really wish people'd actually check shit before bitching at me about problems that only exist in their sodding heads |
| 14:14 | | Jessikat [Jessikat@Nightstar-ksmccf.dab.02.net] has joined #code |
| 14:17 | | Jessikat` [Jessikat@Nightstar-o6dt1g.dab.02.net] has quit [Ping timeout: 121 seconds] |
| 14:25 | < Jessikat> | Heh |
| 14:25 | < Jessikat> | I recognise this |
| 14:35 | | RchrdB [RchrdB@Nightstar-qe9.aug.187.81.IP] has joined #code |
| 15:41 | | mac is now known as macdjord|wurk |
| 16:11 | | celmin|Zzzzzz is now known as celticminstrel |
| 18:27 | | Vornicus [Vorn@ServerAdministrator.Nightstar.Net] has joined #code |
| 18:27 | | mode/#code [+qo Vornicus Vornicus] by ChanServ |
| 20:26 | | Kindamoody|afk is now known as Kindamoody |
| 20:44 | | Jessikat` [Jessikat@Nightstar-5e2u9b.dab.02.net] has joined #code |
| 20:48 | | Jessikat [Jessikat@Nightstar-ksmccf.dab.02.net] has quit [Ping timeout: 121 seconds] |
| 20:48 | | Jessikat` is now known as Jessikat |
| 21:05 | | celticminstrel [celticminst@Nightstar-oil0hh.dsl.bell.ca] has quit [[NS] Quit: KABOOM! It seems that I have exploded. Please wait while I reinstall the universe.] |
| 21:06 | | celticminstrel [celticminst@Nightstar-oil0hh.dsl.bell.ca] has joined #code |
| 21:06 | | mode/#code [+o celticminstrel] by ChanServ |
| 21:10 | | ToxicFrog [ToxicFrog@ServerAdministrator.Nightstar.Net] has quit [Ping timeout: 121 seconds] |
| 21:11 | | Turaiel[Offline] is now known as Turaiel |
| 21:20 | | ToxicFrog [ToxicFrog@ServerAdministrator.Nightstar.Net] has joined #code |
| 21:20 | | mode/#code [+ao ToxicFrog ToxicFrog] by ChanServ |
| 21:32 | | ion_ [Owner@Nightstar-gmbj85.vs.shawcable.net] has joined #code |
| 22:42 | | Kindamoody is now known as Kindamoody|afk |
| 23:15 | | Jessikat` [Jessica@Nightstar-bt5k4h.81.in-addr.arpa] has joined #code |
| --- Log closed Tue Mar 28 00:00:48 2017 |