14:02 <hl> whitequark: re: burroughs, have you ever looked at IBM i / AS/400 / System/38?

14:03 <whitequark> not in depth

14:03 <whitequark> i know that it exists

14:03 <whitequark> and i vaguely recall it being unusually advanced too

14:03 <hl> whitequark: this is hopelessly incomplete but here's a brief intro I wrote; https://www.devever.net/~hl/f/as400guide.pdf

14:04 <hl> also https://homes.cs.washington.edu/~levy/capabook/ if you haven't seen it

14:14 <whitequark> >Getting Started With The Future Systems Legacy

14:14 <whitequark> that's not very optimistic

14:15 <hl> the division of IBM that produced what ultimately became i was the 'Future Systems Division'

14:15 <hl> i.e., a bluesky thinking effort

14:15 <hl> IBM i is still absurdly advanced by contemporary standards in some ways but there's no getting around the fact that it's also kind of legacy in many ways

14:17 <whitequark> oh!

14:17 <whitequark> also yeah i'm reading it and yeah

14:18 <whitequark> like can we have that already? kthx

14:18 <whitequark> especially typed filesystems

14:36 <gruetzkopf> i'll have two first-gen AS/400 systems soon

14:37 <hl> gruetzkopf: ##ibmi for advice

14:38 <gruetzkopf> great topic line :D

14:46 <whitequark> can we talk about that topic line

14:47 <hl> whitequark: I'm just disappointed someone removed 'Philosophical discussions about the Teletubbies also allowed' from it

14:48 <hl> (this actually happened once)

14:48 <whitequark> only once?

14:48 <whitequark> i'm disappointed

14:48 <hl> unfortunately yes

15:21 <whitequark> hl: read the page; interesting system

15:22 <whitequark> i'm not sure if it's quite as advanced given that these ideas have been bouncing around for a whole lot of time

15:22 <whitequark> it's more that posix is hopelessly obsolete

15:22 <hl> agreed

15:22 <hl> did you see my recent articles on OS desigN?

15:23 <whitequark> just like x86 got virtual memory how many years after pdp-8?

15:23 <whitequark> os design, nope

15:23 <hl> 1. https://www.devever.net/~hl/objectworld

15:23 <hl> 2. https://www.devever.net/~hl/globalfs

15:23 <hl> maybe also see https://www.devever.net/~hl/nexuses

15:24 <whitequark> oh thank god someone actually criticizes plan 9

15:24 <whitequark> i thought i'd never see this day

15:26 <whitequark> oh yeah, powershell is brilliant

15:26 <whitequark> if it had verbs that are useful on linux (like netlink!) then i'd use it as my login shell

15:26 <hl> yeah

15:27 <hl> the only real issue with powershell is it's a layer on top of the OS, rather than the OS - you can cd into the registry or WIM or whatever in powershell, ideally you could do that in applications too

15:28 <hl> but yes, powershell was actually designed by someone who understood that shell pipes are actually dataflow engines, and that there's more to life than untyped plain text

15:28 <whitequark> preach

15:28 <whitequark> untyped plain text is one of the worst things about unix

15:28 <hl> i mean I've witnessed people who are very drunk on the "UNIX is the best we can ever do" kool-aid, and when someone proposed pipes passing something with actual structure, they're all "that's not unix!!!"

15:29 <whitequark> well yes that's the point

15:30 <whitequark> trying to shoehorn things into posix is so depressing

15:30 <whitequark> like i bet someone will eventually get pipes to pass json

15:31 <hl> and everyone implements posix. even things which aren't unix. IBM i actually had an AIX compatibility environment called PASE tacked onto it years ago and depressingly, more development gets done there now. z/OS supports POSIX now

15:31 <whitequark> i think what would work is building your own fiefdom on top of POSIX that actually makes sense, but is compatible with legacy systems

15:31 <whitequark> then strangle them

15:31 <whitequark> microsoft style

15:32 <hl> (despite the fact that last I checked z/OS traditionally didn't have much conception of files; its equivalent notion, 'dataset', is a fixed-length allocation on disk thus really a partition)

15:32 <whitequark> seL4 is soooort of doing that

15:32 <hl> (no idea what z/OS does now though)

15:32 <hl> whitequark: yeah, I have an OS concept which is currently just in my head, based on seL4

15:33 <hl> whitequark: the nice thing about seL4 is that if a thread does illegal operations, page faults, unknown syscalls, etc., it all just gets treated as an IPC send to some other thread supervising that thread... which means theoretically, you could implement linux syscall ABI compatibility without even modifying the kernel

15:33 <whitequark> yep

15:34 <whitequark> i mean, i did that for darwin

15:34 <whitequark> https://github.com/whitequark/zs

15:34 <hl> it also amuses me how seL4 treats VMs as really just a slightly different type of thread. because that's all it comes down to - a difference in the interface exposed to the code running in it

15:34 <hl> ...cool

15:35 <whitequark> i think they broke the port bootstrap dance since

15:35 <whitequark> i think it might be possible to just go via launchd instead? not sure, not a macos expert

15:35 <hl> whitequark: and then there's solaris/illumos, which implemented the linux syscall ABI, along with zones, a container system which can actually be relied upon to be secure (unlike linux's), meaning that joyent actually used it to offer multitenancy without needing VMs

15:36 <whitequark> oh come on, people offer multitenancy on openvz too

15:36 <whitequark> (yes i know it's bad)

15:36 <hl> oh god openvz

15:36 <hl> so, have you read about CHERI?

15:36 <whitequark> of course

15:37 <whitequark> wait, do you follow me on twitter?

15:37 <hl> I don't, but someone linked to your twitter today hence why I showed up here to respond to it

15:37 <hl> I don't actually have a twitter account, so heh

15:37 <whitequark> ah, right

15:37 <whitequark> so one of the motivations for my CPU research project is making it possible to add CHERI as a microcode update

15:37 <hl> oooh

15:37 <whitequark> like, *just* running ARM and x86 binaries isn't very interesting

15:37 <whitequark> more of a cool party trick

15:38 <hl> so, CHERI is very interesting. It kind of sidesteps some of the ergonomic issues microkernels have

15:38 <whitequark> but i want to tape out silicon that makes it possible to do research that hasn't even started when it arrives from the fab

15:38 <hl> e.g. passing large buffers between processes

15:38 <whitequark> yeah

15:39 <ar> hl: a friend of mine, also an irc troll, works on CHERI

15:39 <whitequark> "also an irc troll" is a pretty unkind description for... anyone

15:39 <ar> whitequark: he actually acknowledges that

15:40 <hl> for example, how do you implement POSIX write() on seL4? the buffer may not be page-aligned. You pretty much need to have some main server which has all memory mapped, and do a copy, AFAICT. with CHERI it's just... pass a cap, done. Makes everything so much more flexible than VM and gets rid of switching costs

15:40 <whitequark> yeah

15:41 <whitequark> i agree entirely

15:41 <whitequark> and one reason i avoid transmeta-style JITs is well, how the fuck do you prove a JIT's correctness?

15:41 <hl> whitequark: of course, you "can" do this in software rather than hardware with stuff like Singularity - wrote an entire OS in .NET, meaning they could turn off the MMU (and actually got better performance due to no TLB misses)

15:41 <hl> IBM i is ofc another example of this

15:41 <whitequark> but a microcoded engine would be entirely amenable to existing SAT-style provers, not to say more powerful methods

15:41 <hl> as is wasm

15:41 <whitequark> except you can't turn off the MMU anymore

15:42 <hl> whitequark: on x86-64? yeahhhh, I noticed that

15:42 <whitequark> no

15:42 <whitequark> on anything that speculates

15:42 <hl> hmm

15:42 <whitequark> encrypted memory is one of a few apriori reliable ways to fight speculative side channels

15:42 <whitequark> it's not even very good, but it claws back quite a lot of space

15:43 <ar> whitequark: btw, found this today while looking for something else entirely, but i still need to find the docking station: https://i.imgur.com/xEEiEoj.jpg

15:45 <whitequark> ar: meanwhile someone on twitter found me a 802.11ad router

15:46 <ar> whitequark: oh. neat

15:46 <whitequark> with the PHY/MAC stuck over USB 3

15:46 <ar> huh

15:46 <whitequark> the uhhh give me a sec

15:47 <whitequark> ar: it's a Peraso PRS4000

15:48 <whitequark> http://perasotech.com/wp-content/uploads/2015/03/prs4000_1025-product_brief-rev0-15-03.pdf

15:48 <whitequark> reference design judging by the PCB

15:48 <whitequark> very fancy multilayer ceramic PCB

15:48 <whitequark> has a Tag-Connect on it too lol, and an ARC core so I can debug it with Glasgow if I wanted

15:48 <whitequark> I'm more excited about the router tho

15:49 <whitequark> it looks exactly like your bog standard SOHO design. SPI flash I can dump and dissect

16:50 <ali_as> What is the actual router that uses that chip?

17:03 <whitequark> ali_as: IgniteNet Metrolinq

17:03 <whitequark> i think it's a mesh thing?

17:38 <kc8apf> whitequark: you've seen Intel's Total Memory Encryption (TME) and MKTME, yes?

17:47 <whitequark> kc8apf: yep. it was very funny

17:48 <whitequark> i came up with a design where PTEs are associated with keys, speculating (no pun intended. actually scratch that, it's a good pun) that it will solve some read side channel issues

17:48 <whitequark> and a few hours later someone informs me intel made MKTME public in late '18

17:49 <kc8apf> Yet no hardware seems to implement TME or MKTME

17:50 <kc8apf> Linux is just _now_ figuring out how to add MKTME

17:50 <whitequark> yeah they're probably scrambling to stick AES into their memory controller right now?

17:51 <whitequark> well, maybe a year ago.

17:56 <kc8apf> likely

18:13 <gruetzkopf> iirc game consoles started doing this way earlier