program     = { statement } statement   = if_stmt | while_stmt | l
> 1762607523 597071 PRIVMSG #esolangs :14[[07Fuck'n14]]4 N10 02https://esolangs.org/w/index.php?oldid=167688 5* 03Yayimhere2(school) 5* (+996) 10Created page with "'''Fuck'n''' is a [[brainfuck]] simplification based off of [[Unary]] and [[Underload]]. It is an [[OISC]] == Etymology == Fuck'n's name comes from Fuck and Unary combined. == Memory == Memory is stored within 5 unbounded cells on a circular ta
> 1762607539 480318 PRIVMSG #esolangs :14[[07Fuck'n14]]4 10 02https://esolangs.org/w/index.php?diff=167689&oldid=167688 5* 03Yayimhere2(school) 5* (+1) 10
< 1762607582 202126 :ehmry!~quassel@217.155.30.169 PART #esolangs :too noisy
< 1762607899 110871 :Yayimhere!~Yayimhere@197.185.159.234 QUIT :Ping timeout: 250 seconds
> 1762608022 387297 PRIVMSG #esolangs :14[[07RECT4n=GLE14]]4 10 02https://esolangs.org/w/index.php?diff=167690&oldid=166413 5* 03Yayimhere2(school) 5* (-19) 10add a note on how RECT4n=GLE measures how well formed a set of shapes are
> 1762608328 122228 PRIVMSG #esolangs :14[[07,(*+)14]]4 10 02https://esolangs.org/w/index.php?diff=167691&oldid=167686 5* 03Yayimhere2(school) 5* (-155) 10/* Programs */ deleted the truth machine as its wrong
> 1762609023 290320 PRIVMSG #esolangs :14[[07Ooh14]]4 M10 02https://esolangs.org/w/index.php?diff=167692&oldid=142524 5* 03Ractangle 5* (-45) 10/* Python implementation */
> 1762609687 982026 PRIVMSG #esolangs :14[[07Esolang:Introduce yourself14]]4 10 02https://esolangs.org/w/index.php?diff=167693&oldid=167592 5* 03Wuyugu 5* (+199) 10/* Introductions */
> 1762609692 103741 PRIVMSG #esolangs :14[[07Stopload14]]4 10 02https://esolangs.org/w/index.php?diff=167694&oldid=167684 5* 03Yayimhere2(school) 5* (+0) 10Fix a weird comma
< 1762611092 147235 :DOS_User!~DOS_User@user/DOS-User:11249 JOIN #esolangs DOS_User :[https://web.libera.chat] DOS_User
< 1762611184 640378 :DOS_User!~DOS_User@user/DOS-User:11249 QUIT :Client Quit
> 1762612631 865519 PRIVMSG #esolangs :14[[07Stopload14]]4 10 02https://esolangs.org/w/index.php?diff=167695&oldid=167694 5* 03Yayimhere2(school) 5* (+87) 10/* Semantics */
> 1762614943 586947 PRIVMSG #esolangs :14[[07T+Riangle14]]4 10 02https://esolangs.org/w/index.php?diff=167696&oldid=165576 5* 03C++DSUCKER 5* (+41) 10
> 1762615470 745062 PRIVMSG #esolangs :14[[07Karvity14]]4 10 02https://esolangs.org/w/index.php?diff=167697&oldid=167626 5* 03Yayimhere2(school) 5* (+905) 10Add a demonstration of the language!
> 1762615687 520521 PRIVMSG #esolangs :14[[07Noddity14]]4 10 02https://esolangs.org/w/index.php?diff=167698&oldid=167620 5* 03Yayimhere2(school) 5* (+50) 10
> 1762615807 91243 PRIVMSG #esolangs :14[[07Karvity14]]4 10 02https://esolangs.org/w/index.php?diff=167699&oldid=167697 5* 03Yayimhere2(school) 5* (+102) 10
> 1762615838 592323 PRIVMSG #esolangs :14[[07Noddity14]]4 10 02https://esolangs.org/w/index.php?diff=167700&oldid=167698 5* 03Yayimhere2(school) 5* (+46) 10/* Memory */
> 1762615874 43633 PRIVMSG #esolangs :14[[07Karvity14]]4 10 02https://esolangs.org/w/index.php?diff=167701&oldid=167699 5* 03Yayimhere2(school) 5* (+2) 10/* Commands */
< 1762618674 954593 :ais523!~ais523@user/ais523 JOIN #esolangs ais523 :(this is obviously not my real name)
< 1762619257 564473 :Lord_of_Life!~Lord@user/lord-of-life/x-2819915 QUIT :Ping timeout: 264 seconds
< 1762619305 593627 :Lord_of_Life!~Lord@user/lord-of-life/x-2819915 JOIN #esolangs Lord_of_Life :Lord
> 1762619567 962210 PRIVMSG #esolangs :14[[07Combine and continue14]]4 N10 02https://esolangs.org/w/index.php?oldid=167702 5* 03Yayimhere2(school) 5* (+1438) 10Created page with "'''Combine and continue''' or '''CAC''' is an esolang created by [[User:Yayimhere]], created to make a church numeral based language, that is not actually [[Lambda calculus]] == Memory == Memory is stored on an unbounded stack, starting with an i
> 1762619748 792844 PRIVMSG #esolangs :14[[07Combine and continue14]]4 10 02https://esolangs.org/w/index.php?diff=167703&oldid=167702 5* 03Yayimhere2(school) 5* (+118) 10/* Commands */
> 1762619900 258033 PRIVMSG #esolangs :14[[07Combine and continue14]]4 10 02https://esolangs.org/w/index.php?diff=167704&oldid=167703 5* 03Yayimhere2(school) 5* (+0) 10/* Commands */
> 1762620079 274213 PRIVMSG #esolangs :14[[07Combine and continue14]]4 10 02https://esolangs.org/w/index.php?diff=167705&oldid=167704 5* 03Yayimhere2(school) 5* (+98) 10/* Commands */
< 1762620548 299904 :pool!~nathan@user/PoolloverNathan QUIT :Read error: Connection reset by peer
< 1762620566 621793 :pool!~nathan@user/PoolloverNathan JOIN #esolangs PoolloverNathan :nathan
> 1762622619 477526 PRIVMSG #esolangs :14[[07Combine and continue14]]4 10 02https://esolangs.org/w/index.php?diff=167706&oldid=167705 5* 03Yayimhere2(school) 5* (+830) 10/* Commands */ Prove CAC turing complete
> 1762623855 432132 PRIVMSG #esolangs :14[[07Viktor's amazing 4-bit processor14]]4 M10 02https://esolangs.org/w/index.php?diff=167707&oldid=167400 5* 03TheBigH 5* (+967) 10added multiplication program
> 1762624084 822632 PRIVMSG #esolangs :14[[07Special:Log/newusers14]]4 create10 02 5* 03GolferHome 5*  10New user account
> 1762624168 235151 PRIVMSG #esolangs :14[[07Esolang:Introduce yourself14]]4 10 02https://esolangs.org/w/index.php?diff=167708&oldid=167693 5* 03GolferHome 5* (+225) 10
> 1762625048 507618 PRIVMSG #esolangs :14[[07QuantumGolf14]]4 N10 02https://esolangs.org/w/index.php?oldid=167709 5* 03GolferHome 5* (+2762) 10Created page with "QuantumGolf is a [[QOO-OOKALAN]] extension for even shorter codes.  === Language Addictions ===  ==== Basic Syntax ====    // Assignment returns value (like JavaScript)   x = 5        // Assigns 5 to x, returns 5    // Implicit output: last expression is printed 
> 1762625177 446248 PRIVMSG #esolangs :14[[07QuantumGolf14]]4 10 02https://esolangs.org/w/index.php?diff=167710&oldid=167709 5* 03GolferHome 5* (+135) 10
> 1762625201 980418 PRIVMSG #esolangs :14[[07Special:Log/newusers14]]4 create10 02 5* 03QuoteDam!anquote 5*  10New user account
> 1762625257 219733 PRIVMSG #esolangs :14[[07QuantumGolf14]]4 10 02https://esolangs.org/w/index.php?diff=167711&oldid=167710 5* 03GolferHome 5* (+88) 10
< 1762625516 604110 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Hmm, do we have a platform that adheres to POSIX but has a NULL pointer representation that's not all-0 bits?
> 1762625926 878908 PRIVMSG #esolangs :14[[07Esolang:Introduce yourself14]]4 10 02https://esolangs.org/w/index.php?diff=167712&oldid=167708 5* 03QuoteDam!anquote 5* (+270) 10
> 1762626018 706495 PRIVMSG #esolangs :14[[07TernaryDigitPointer14]]4 N10 02https://esolangs.org/w/index.php?oldid=167713 5* 03QuoteDam!anquote 5* (+28271) 10i apologize this couldnt be more formal but present circumstances in my life make serious formulation rather difficult. love you esolangs ~~~~
< 1762626032 553505 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :int-e: you don't count C++ pointer-to-members, right? 
< 1762626057 965322 :int-e!~noone@int-e.eu PRIVMSG #esolangs :right
< 1762626179 249095 :int-e!~noone@int-e.eu PRIVMSG #esolangs :CHERI might come close but kind of for the wrong reasons (invisible tags in memory). Plus it's not fully conformant for more or less the same reasons.
< 1762626214 303196 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I hope there isn't. all zero bits to represent null pointer is convenient. 
< 1762626476 487444 :Sgeo!~Sgeo@user/sgeo JOIN #esolangs Sgeo :realname
< 1762626492 430409 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :and I think a different representation would break a lot of existing code that hardcodes that (unless perhaps there are multiple valid null pointers that the C comparison operators all compare equal and they all count as false in boolean context and the all zeros is one of them)
> 1762626998 87127 PRIVMSG #esolangs :14[[07BytePusher14]]4 10 02https://esolangs.org/w/index.php?diff=167714&oldid=165606 5* 03Wlad 5* (+175) 10Add new BytePusher implementation
< 1762629210 972346 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :fwiw I think there are reasons to want pointers that have set bits in interesting places, like the top bit
< 1762629227 378285 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so that they can be more easily distinguished from integers (especially in systems with "this is a pointer" bits like OCaml)
< 1762629257 949458 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but that doesn't mean that NULL can't be all-bits-zero because normally you want NULL to be non-dereferenceable, so it's OK if it doesn't have a valid representation for a pointer
< 1762629364 19407 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :The entire belief that pointers are rows of bits is a quirk of Von Neumann machines. It's not a coincidence that this assumption fails precisely in Harvard arches like CHERI or WASM.
< 1762629380 697190 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I have been thinking a lot about this today in particualr
< 1762629399 80828 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I was thinking about the difference between shadow-capability models and tracing-capability models
< 1762629411 294341 :APic!apic@apic.name PRIVMSG #esolangs :Good Night!
< 1762629444 4898 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :It's akin to the belief that I've been quietly grapping with in Vixen, that a directory path is a bytestring, a UTF-8 string, or a list of path segments; but on a modern Unix, a directory path can be a file descriptor! Folks' difficulty in accepting this is why Capsicum was never merged to Linux.
< 1762629448 82381 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :APic: Peace.
< 1762629457 41705 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(the former is systems like Fil-C and CHERI where the thing that makes the pointer a pointer is stored in a parallel set of memory somehow; the latter uses the equivalent of "GC roots" (although there needn't actually be a GC) and a state machine to know what a pointer is, sort of like a tracing GC but without the actual GC)
< 1762629496 663444 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: file descriptors are clearly the best way to represent directories – but it's fairly easy to go back and forth between the two representations in modern Linux
< 1762629503 448633 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :you can just write /proc/self/fd/10 or whatever
< 1762629520 931546 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :As opposed to e.g. Cello, I suppose? In Cello, a fat pointer is represented as a pair of pointers, and the GC interop is achieved by requiring all fat pointers to be *allocated* by libcello.
< 1762629527 928987 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(I think there's even an abbreviation /dev/fd/10)
< 1762629570 764117 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: In many BSDs, there's a flag O_BENEATH or O_OPEN_BENEATH that allows open() on a directory to return a *restricted* descriptor. Doing an openat() or similar on this descriptor will fail if the path is not relative, or if it contains segments like "..".
< 1762629580 208773 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: Linux too
< 1762629603 965237 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the RESOLVE_BENEATH option to openat2(2)
< 1762629619 104119 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: Kind of? The flag only works for a completely separate version of the syscall, called something like open2(), and it's not bound in glibc. So actually doing it on Linux requires a syscall().
< 1762629619 542947 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :oh, no, it's an option to a different syscall
< 1762629630 472862 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the BSD approach does it when opening the directory, Linux does it when opening the file
< 1762629650 736195 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :you could still use seccomp or the like to force the flag to be given
< 1762629654 247192 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Yeah. Gotta paper over that. There's a Rust crate, and it's part of the std::cap capability-friendly stdlib.
< 1762629696 376959 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(I think it is correct to do this as defence in depth when using an object-capability model – having the kernel block things that don't use capabilities properly is nice even if your type system also does that)
< 1762629719 515844 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :This doesn't sound like a fun time though. I'd have to somehow show that Vixen objects can't allow user code to handle raw paths? Or perhaps I'd have to show that user code can't invoke certain syscalls? Either way it's daunting.
< 1762629742 768381 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :(Yes! See also pledge() and unveil() on some BSDs.)
< 1762629750 818087 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :both Linux and OpenBSD (and maybe some of the other BSDs too?) have a way for a process to prevent itself from ever using certain syscalls
< 1762629759 257234 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :seccomp on Linux, pledge on OpenBSD
< 1762629778 588336 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but the BSD version is easier to use, Linux's is very general but a bit difficult to use because of that
< 1762629814 376376 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Right. In capability theory, what we really seek is a system that has safe *loading* of untrusted user code; if the user can't ever instantiate a malicious object, then they can't possibly violate any security property.
< 1762629828 986594 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :also, if you use seccomp you can't subsequently exec setuid binaries (basically because if they could use the syscalls themself that would be a hole in the sandbox, and if they couldn't they might malfunction due to some of their syscalls not working)
< 1762629852 685474 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :And so Vixen's going to have to do the same thing that many cap systems do, where there's two kinds of pointers. There's low-level references that are unsafe, but the user can't touch; and high-level references that are safe and obey the cap rules.
< 1762629902 469658 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think the correct way to do loading of untrusted code is "it comes with a proof that it doesn't violate any of the capability rules and you verify it on load" (where the proof is ideally just types in an appropriate type system)
< 1762629962 524257 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :In E, low-level refs are Java refs and high-level refs are fat pointers of safe code and a closure to more refs. In Monte, low-level refs are RPython object refs and high-level refs are fat pointers again. But this pattern can't work for Vixen because a fat pointer containing a path still lets the user read the path; this is a problem in Nix too.
< 1762629990 42035 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :oh right, I also had a terminology problem
< 1762630004 50295 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the thing that proves you have access to, e.g., a filesystem resource is called a "capability"
< 1762630017 89672 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the thing that makes a piece of memory into a pointer and lets you dereference through it is also called a "capability"
< 1762630039 239553 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Yeah, probably. In practice, we start by requiring the code itself to be highly restricted, usually equivalent to a simply-typed lambda calculus; cap safety is free there. Then we ensure that the loaded code only has access to *tamed* resources, which have been structured to preserve caps. And we have to take away stuff like timers that seem harmless.
< 1762630047 316167 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :this is OK as long as you're only dealing with one of those at a time, but trying to think about both at once is confusing and I've been looking for a clear way to distinguish
< 1762630076 406744 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(they are clearly connected concepts, but a little different in nature and in most cases substantially different in implementation)
< 1762630084 393879 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :As Arlo Guthrie put it, "Officer Obie wanted to make sure that we wouldn't hurt ourselves in the jail cell. So Obie took away our belts so we couldn't hang ourselves, and our shirts so we couldn't strangle ourselves, and even the toilet seat so we couldn't hit ourselves over the head with it."
< 1762630099 889645 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :some real-life prisons actually do do that sort of thing
< 1762630120 163690 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Right. The capability is the *reference* and the resource itself is an object/actor/machine/etc.
< 1762630165 437275 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I guess it helps if your file descriptors are Windows/WASM-style opaque-numbers-that-look-a-lot-like-pointers rather than POSIX's consecutive integers
< 1762630200 626321 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Yeah, we usually require a capability representation to be *unguessable*, which is a truly bad word but better than "very-hard-to-guess-able".
< 1762630203 331079 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :because then you can make them not collide with actual real pointers you can store through
< 1762630222 610709 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: oh, I'm surprised, I thought you would use the type system to make them unforgeable
< 1762630243 936029 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :This is actually kind of nice for Vixen though, because we can say that the calling convention includes a *row* of FDs, starting with the standard three and optionally adding more. Just like how we can pass additional argv by appending them to the end, we can pass additional FDs in a little stack.
< 1762630296 799484 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(I believe that, given the number of speculative execution vulnerabilities that have been discovered and the rate at which they are still being discovered, there are almost certainly a large number of such vulnerabilities that aren't publicly known, some of which may be known to adversaries – and as such, with today's processors, unguessability is probably unwise to rely on)
< 1762630298 362446 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: Some languages do that. Pony's a good example. It's got like six different kinds of modifier for pointers, and the type system strongly restricts how pointers can be casted. They ended up incorporating a fair amount of Rust's thinking IIRC.
< 1762630336 843488 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Wyvern's another decent example. They have dependency injection for global concepts; if you want to write an HTTP handler but not an HTTP server, you can write just the handler and the type system will wire it up for you.
< 1762630340 957568 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :Rust is a mix of things that are only incidentally there and could easily be different, and some fundamental insights about programming
< 1762630360 677253 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :"exclusive references are useful" is one of the fundamental insights, I think
< 1762630382 543271 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I realised that today, because I was thinking about casts between pointer-to-pointer and pointer-to-integer
< 1762630384 185621 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :(I don't know why most cap languages are named after animals. The pattern has never stopped, though; E was originally Joe-E, both a coffee and "joey" pun. Monte is homophonic with Lojban {manti}, "ant".)
< 1762630418 96120 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :in almost all memory-safe language, these either can't be allowed (for semantic reasons) or are permitted but don't actually work correctly
< 1762630460 516974 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :whereas in Rust, the cast is safe as long as you have an exclusive reference, and write through it before reading through it
< 1762630474 647358 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and I was trying to work out where the difference was – it's purely the exclusive reference that makes it work
< 1762630479 850269 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Or they do something silly. In cap theory, a *c-table* or *cap table* holds pointers for users, since users can't be trusted to do bad things. Instead, the user gets a reference into the c-table. Examples range from the kernel's row of per-process FDs to ECMAScript's WeakMap.
< 1762630519 521528 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :that reminds me of WebAssembly's function table, which I think is similar but not quite the ame
< 1762630521 127496 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :*same
< 1762630539 477921 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(WebAssembly doesn't really have function pointers, but you can use indexes into the function table as a substittue)
< 1762630566 212172 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Further, a *powerbox* is a set of pre-delegated powers that are already packed into a c-table. We usually assume that the user has to *know* the keys for a powerbox before it will do anything for them; keys are unguessable in WASM or Nix, or unforgeable in ECMAScript's WeakMap.
< 1762630622 739303 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :And yeah, WASM starts each module with a powerbox of imports and other stuff. The runtimes like wasmtime include tamed POSIX syscalls in the powerbox. I think that the fullest example of all of this was CloudABI, an also-ran for Capsicum that I think is now defunct.
< 1762630659 931041 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :A variant would be to store a generation number with each reference into the table as well; Free Hero Mesh does this (although this is an internal representation and not exposed to user code, which only sees references to objects without knowing their internal representation). (Free Hero Mesh also uses 0 for null pointers, even though non-null pointers are distinguished from integers.)
< 1762630694 947052 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :one of the things I want to do is write my own interact-with-the-OS library, sort-of like the OS-interaction parts of libc, but with a very different interface
< 1762630744 682789 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :What kind of different interface?
< 1762630754 346396 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it would be designed to be compatible with object-capabilities but I would want to make other changes too (e.g. supplying a solution to the heterogenous select problem, and being compatible with asynchronous interfaces)
< 1762630784 738152 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :like, you could start a write and two reads and then select on any of those completing, or signals arriving, or timers expiring, or a directory being changed, or anything else of that nature
< 1762630838 4578 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :I had thought of that, although in the context of redesigning the entire operating system and computer rather than working with existing systems.
< 1762630856 268402 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :this interface is compatible with old-fashioned POSIX (not async, you use pselect and maybe threads if you have to), with nonblocking IO, with async IO, and with io_uring
< 1762630899 207206 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but it would be so much more sensible than what we have at the moment, where system calls are able to block on random subsets of things and there isn't a clean, simple way to just block on any set of things
< 1762630934 631110 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :All of the things you mentioned would be implemented using the same system call (and there is no distinction between timers, directories, files, etc; signals might be distinct if necessary but the others would just be capabilities with the same system call interface as any other)
< 1762630949 477257 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(Linux has been moving towards a model of being able to convert arbitrary things you want to wait on into fds, and using epoll to block on them all at once ? but it doesn't quite work for everything, e.g. they couldn't make futexes work with it even though they tried)
< 1762630990 595024 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :oh no, somehow my client's encoding has changed away from UTF-8 and I have no idea where the setting is to change it back
< 1762631056 602932 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :testing – áéàè
< 1762631060 75200 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :that's better
< 1762631088 42173 :int-e!~noone@int-e.eu PRIVMSG #esolangs :☢
< 1762631364 379604 :pool!~nathan@user/PoolloverNathan QUIT :Read error: Connection reset by peer
< 1762631375 251919 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :There was a quite interesting thread on that topic recently on Lobsters: https://lobste.rs/s/ko5i9y/if_you_could_redesign_linux_userland_from It turns out that there's a very real distinction between changes that are willing to negotiate syscalls and changes that take the syscalls as they are.
< 1762631414 68154 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :zzo38: Have you looked at seL4? I regret not actually putting time into it, but it seems like they got all of the capabilities done right.
< 1762631490 397517 :pool!~nathan@user/PoolloverNathan JOIN #esolangs PoolloverNathan :nathan
< 1762632066 445396 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: I think it's OK to leave the kernel's system calls as they are, but there should be an API layer in between them and userspace that enforces sensible usage
< 1762632326 646537 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :I have seen seL4 and my ideas have some similarities but also differences
< 1762632758 678603 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: your link reminds me of another thing I wanted to do: having command-line arguments grant capabilities
< 1762632766 739638 :tromp!~textual@89-99-43-152.cable.dynamic.v4.ziggo.nl JOIN #esolangs * :Textual User
< 1762632781 774861 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :i.e. a program can't naturally read files, but can if you specify them as command-line arguments (this would need some rules for when a command-line argument was a file and when it wasn't)
< 1762632816 121141 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the nice thing is that I think you can do that in a way that's mostly compatible with programs that don't understand the convention
< 1762632921 864220 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(the hard part is allowing programs to read the dependencies they depend on, although I think that's regular enough to be special-caseable)
< 1762633225 473620 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: The trick is to understand that a string can still grant an unguessable capability, as long as it's in some hyperbolically-large (and thus exponentially expensive to search) space. Doesn't work for Realtalk/Dynamicland books, which are in Euclidean space; but it *does* work for URLs. There's a W3C about this: https://www.w3.org/TR/capability-urls/
< 1762633265 986603 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: oh, I was thinking in terms of user interface as used by humans, rather than in terms of program-program communication
< 1762633296 541329 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :you don't need to use unguessable strings when you can just say /dev/fd/10 or whatever (which is guessable, but won't work if the capability hasn't been given)
< 1762633399 18354 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :It's too bad that we can't name capabilities easily when we pass them. I was thinking about using envp; there'd be an envvar like MY_CAP=42 and a passed FD 42. But that feels like too much of a hack for some reason, even though envp's part of the process calling convention.
< 1762633478 504367 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :No wonder that big message-passing actor systems (gRPC at Google, Workers at Cloudflare) use some sort of extremely restricted flat-buffer format (PBs, Capn Proto). Slightly less of a wonder that Capn Proto explicitly has a "capability" type which is just for opaque pointers but comes with calling-convention rules for networked usage.
< 1762633490 764793 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :a related idea I've had for a while is that of a "typed main()" where the entry point to a program gets to choose its own arguments and types for them, rather than being a list of strings
< 1762633509 986456 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and this would include the capabilities that it needs
< 1762633531 373870 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :then there would be some automated way to translate this into a command-line argument parser so that humans could use it
< 1762633559 856415 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Wyvern does that although I don't remember the syntax. Monte did it in a way that was optimized for human auditing; just read the main() directly: https://github.com/MostAwesomeDude/airbrus/blob/master/airbrus.mt#L102-L107
< 1762633587 467883 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :(This is an IRC bot but the principles are fully general. I also did some TUI widgets, distributed raytracing, HTTP, etc.)
< 1762633632 107822 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: ooh, so I wasn't the first person to have that idea, that makes me more confident that it's a good one
< 1762633704 578855 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: In the Bun runtime, which is like an ECMAScript dialect, there's CLI switches to disable various caps, so that if main() asks for a disabled cap then it'll immediately crash. pledge() in argv, basically. I want to say that wasmtime has that sort of thing, too, but I'm not sure.
< 1762633751 76532 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :It's a really cool fusion of ideas. The cap says what you *can* do, but the constraint/context says what you *can't* do, and the runtime never lets the cap violate the constraint.
< 1762633751 152715 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: right, that's equivalent to just not passing the argument in
< 1762633770 508321 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and in most programs that gives you a usage error
< 1762633804 527972 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Oh! Fil-C does this too. People have been talking about data racing and ragged/torn pointer accesses. The upshot is that Fil-C's fat pointers basically are cap/context pairs, with the cap being a plain pointer, and the language's safety is relative to the context rather than the caps.
< 1762633837 540804 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: Exactly! Monte literally raises the *same* key-not-found error that it would raise for an ordinary map lookup. I think it *is* an ordinary map TBH.
< 1762633888 403157 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: your terminology here contradicts the standard, most people call the shadow part the capability (the part in main memory is called an integer part or an address)
< 1762633912 358232 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but right, it's the same concept
< 1762634114 230540 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Yeah, I think that it's a consequence of being on the other side of memory-safe-by-default. It's possible in Python to sandbox an imported module s.t. it won't corrupt memory, but all of the issues of improper access are still there, and Python can't be sandboxed in general without removing most of the object model.
< 1762634379 455929 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :In the E framing, a fat pointer's got a "script", which is like all of the compiled methods, and a "closure", which is just a list of caps. These are both machine pointers, and improper access is prevented wholly by the script being safely-loaded code. So to even have access to an E system is to be limited by these safety rules and never mishandle a pointer.
< 1762634421 526326 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :In the CHERI framing, though, the code can literally have any sequence of bytes and instruct the machine to do anything whatsoever. So of course the cap and the pointer are distinct, because the instructions are about pointers and not caps.
< 1762634481 991299 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :I've always said that Nix is what we call a *transitional* cap-aware system. It can, when restricted to a certain view, be cap-safe; but really that depends on a discipline where we never look under the hood at the actual path. Vixen would be like this too. But also so is Apache when it's got a webroot; path traversal is generally not okay.
< 1762634504 893034 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so I think there are two main distinctions here: a) shadow capabilities versus tracing capabilities, b) pointers being one machine word versus two machine words
< 1762634516 432160 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :So maybe there's a sense of *path-safety* that we haven't quite figured out, s.t. cap-safety implies path-safety but not vice versa.
< 1762634529 615448 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: this is the same problem as SQL injection I think
< 1762634555 630403 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it is certainly possible to have sound programs that use string concatenation to substitute into their SQL, they just have to be super-careful to escape properly
< 1762634558 875044 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :that's what Apache is doing with paths
< 1762634583 389420 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Isn't SQL injection about quoting? The problem here is that somebody could guess that a Nix store has a particular (common version of a) package and does a Living Off The Land setup.
< 1762634591 299872 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but using parametrized queries is better, because then there's no chance that you forget to escape something and input gets interpreted as code
< 1762634619 933111 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: yes, but Apache is similar – I think it works by parsing the path to look for suspicious combinations of ../ and the like
< 1762634632 572123 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :which isn't quite the same problem as quoting but it has essentially the same solution
< 1762634638 330320 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :The biological model I've been thinking of is not viruses or bacteria but *obelisks*, very recently discovered RNA-world fragments. It's possible and common for a script in the Nix store to just wrap another script, setting the environment and etc.
< 1762634692 208035 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: Yeah. We could analogize that to a form of memory-safety where it's possible to canonicalize a pointer, and relative paths are like segmented/etc. pointers. So path traversal is like pointer forgery.
< 1762634709 42038 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :right
< 1762634730 595746 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the distinction is between an environment where capabilities *can't* be forged, and an environment where capabilities *aren't* forged
< 1762634737 633499 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(they could be, just the code chooses not to do it)
< 1762634761 145716 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :you can make the latter into the former with a sufficiently powerful static analyser
< 1762634784 852113 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Oh no. I hate this distinction. This is one of those things that I don't like at all. In Lojban, we call it {poi} vs {noi}; when is something logically constrained/restricted from occurring, vs. just coincidentally happening to never occur?
< 1762634824 179616 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :I don't like this because AFAICT there's no *logical* basis for telling these two environments apart. This has kept me up at night.
< 1762634848 818780 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :…and I've just realised that we've spent like 30 out of the last 40 years of programming trying to make the latter better rather than concentrating on the former, and that makes me sad too
< 1762634880 315485 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :I get what you're saying. We're talking about environments that are safe because they were correctly programmed, not because they were proven correct with a construction.
< 1762634898 803221 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think Chinese has this distinction too, there are 4 or 5 words for "not" and one of the distinctions made is this one
< 1762634971 673678 :pool!~nathan@user/PoolloverNathan QUIT :Read error: Connection reset by peer
< 1762635095 841839 :pool!~nathan@user/PoolloverNathan JOIN #esolangs PoolloverNathan :nathan
< 1762635171 811287 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and yes, this is about partial proofs I think – it is easier to prove that a program obeys certain rules than to prove it entirely correct (especially as the latter needs to you have a spec, and somehow be confident that the spec is correct)
< 1762635207 538781 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :a program can be programmed, by a sufficiently skilled programmer (which may not exist in practice), to obey the rules even if nothing is enforcing them
< 1762635244 569714 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but it is better to have something that enforces the rules, ideally at compile time or even better library-check time, although runtime is better than nothing
< 1762635251 502195 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: Okay, so now I'm thinking about what a CHERI/Fil-C model for paths would look like. Absolute path access would have to be banned, I think. openat() and friends would work for passing around relative path fragments. Some sort of path importer might make sense; I think Fil-C has something like this, where an untrusted pointer (absolute path) can be runtime-checked (path-parsed) in the context of an existing cap (path prefix) to cast it
< 1762635265 403634 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :to a safe pointer (relative path + prefix).
< 1762635331 406655 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so Fil-C's basic primitives are the same as the ones that Rust provides, and a subset of CHERI's (CHERI has a capability narrowing primitive, Fil-C doesn't meaning that it can't catch allocation-internal buffer overflows, Rust currently sort-of does but only by accident and there are plans to remove it)
< 1762635364 718546 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :To prevent a program from trying to repeatedly reinterpret a path against multiple different caps, I think that a failed cast would mean exit(). This is basically what we do in Python or Apache against path traversal.
< 1762635388 569183 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :that reminds me, I meant to argue that Rust would benefit from a capability narrower even though the only thing it would do in present rust is to add undefined behaviour, because that allows sanitisers to take advantage of the undefined behaviour to catch internal buffer overflows
< 1762635443 12850 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: well, the brute-force approach only works against probabilistic defences – I prefer determinstic defences for other reasons, but they'd also help in that situation
< 1762635456 337588 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the issue with trying to block brute force with forced exits is that there are so many potential loopholes
< 1762635474 111469 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :like restarting the process, or spinning off daemons to do the brute-forcing, or the like
< 1762635497 300141 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(and you might not want to take down the whole process if it's, e.g., a web server process that serves tens of thousands of concurrent users)
< 1762635508 559111 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Monte doesn't have narrowing, but Monte has E-style auditing and transparent forwarding, so has other ways to attenuate caps. Vixen ought to have narrowing; I'm thinking of cribbing from zope.interface, which allows dynamic casting to an interface which can hide unrelated methods.
< 1762635536 719603 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think OpenBSD has some sort of rule along the lines of "if a setuid process hits a runtime security check, its effective user can't run setuid programs for 15 minutes" as an anti-brute-forcing measure
< 1762635560 807564 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Well, just like with pledge(), we want violations to exit() because they signify that a contract has gone horribly wrong. I'm mostly thinking of Windows programmers who will search fifteen different locations for DLLs.
< 1762635578 696793 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Oh wow, TIL. That is hilarious.
< 1762635700 591663 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :My system does not have "command-line arguments" (it has an "initial message" which is similar, though). The initial message is not text, and can include capabilities; you do not need to use text to grant capabilities, but instead can pass them directly.
< 1762635743 976203 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: Oh, I suppose E-style auditing is relevant. In E and Monte, and also OSs like KeyKOS and Genode, it's possible for one object to certify another object as having some structural property. This means that there's an auditing protocol which allows objects to consensually inspect each other.
< 1762635777 606971 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :zzo38: what is the interface for humans to start programs like?
< 1762635806 984935 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: now you've got me thinking about internal vs. external debuggers
< 1762635826 595765 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :KeyKOS has the most interesting one to me. A running "tenant" process can have an "apartment". If the "super" (superintendent? supervisor?) wants to inspect it, then the tenant receives a signal and gets some time to put their apartment in order before the inspection. They also have some limited rights during the inspection!
< 1762635828 875693 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :i.e. debuggers that try to work inside the capability system, versus debuggers that think in terms of VM internals and can just ignore capabilities
< 1762635865 747656 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: I'd be interested to know what the applications for that are
< 1762635876 967482 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :Multiple interfaces are possible, but the main one would be CAQL (Command, Automation, and Query Language). One part of the program file specifies the expected type of the initial message, so that the CAQL can do the necessary type checking and conversion as appropriate into the byte/capability sequence.
< 1762635915 480122 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :zzo38: Same idea in boot-to-Monte scripts that we never shared publically. Instead of starting a Monte REPL, start a Monte module; load the module into memory, start the JIT, and invoke the module's .run() method with argv, envp, all the usual goodies.
< 1762635955 418786 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :You could type an expression which evaluates to the appropriate capabilities and functions and files, or can copy them from other windows (using the mouse or using key combinations involving the [System] key or both), or a combination of these.
< 1762635972 591975 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :zzo38: OK, that's a bit different from what I was expecting but it does make sense
< 1762635985 481396 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :Microsoft have Powershell as a similar sort of interface
< 1762636025 268734 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: KeyKOS was very early on, and just like early cap machines (Burroughs S500 or whatever it was called?) there were a lot of skeuomorphisms that didn't make sense to carry forward. Back then, memory spaces were more uniform; the extreme of this was IBM's mainframe (390?) that structured *everything* as a relational database.
< 1762636046 886912 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :my plans were more along the lines of "when you install a program you specify capabilities that you are willing to grant it every time you run it, if you have them yourself" and then for any capabilities you don't grant it (but it needs) you have to specify them manually
< 1762636082 663024 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and also to make the manual specification as easy as possible, e.g. an "open file" dialog box would allow you to both choose the file and grant the program permission to access it (as you would always want to do both together it would be combined into a single button, with an icon showing that you were granting a capability)
< 1762636088 408959 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :...Sorry, that was an unhelpful history answer. Apartments make sense when you're running untrusted code. Think about how a modern cloud VM works; it has a similar inspection mechanism, usually delegated to the person renting the machine but also usable by the datacenter ops.
< 1762636123 134324 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: my cloud VM's equivalent of that is the serial console, but maybe it's old-fashioned
< 1762636126 962182 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Actually I suppose it has *two* layers! A cloud *machine* in the rack is like an apartment, and the *VM* on the machine is also like an apartment. They have the same super/tenant relationship.
< 1762636131 838163 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :You would be able to do that with my system too, and the package manager would probably include that function; e.g. you could create your own function that calls it with the appropriate capabilities, if the file that defines the alias contains those capabilities to be granted.
< 1762636139 329666 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(I assume the serial port is also virtualised)
< 1762636185 903988 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: A little. When I was working in a datacenter, we still had the idea of "pulling disks" on the hardware. We were just getting started with big VMs, we were doing Ganeti and Vagrant, and we didn't see the point of VMs. It was bare metal for customers all day.
< 1762636196 341073 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: it took a very long time for the world to settle on the current "flat memory model with an MMU enforcing permissions" design for CPUs
< 1762636203 831248 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and although it is consensus, I also think it's wrong
< 1762636225 371929 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :But even then, if we needed to go pull a machine from a rack, we'd first ping the owner on IRC to make sure that they were cool, give them some time to settle daemons and park disks and even $(shutdown), and *then* pull the machine for screwdriver time.
< 1762636241 902671 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think VMs only started making sense fairly recently
< 1762636261 362713 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :because the bottlenecks have changed over time
< 1762636293 716413 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :As Fred Durst memorably said, "It's all about the para-virt hyper-virt cloud shift".
< 1762636300 129555 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :a little over a decade ago, I was teaching a course in operating systems development (which was mostly writing Linux kernel modules)
< 1762636319 382702 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :we tested the students' programs on bare metal and reimaged the computers afterwards
< 1762636364 944614 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Lore is that Google was first to containers, figuring them about about a decade ahead of everybody else. (I'm allowed to share this.) Lore is that from 1998-2008 Google believed containers were a trade-secret competitive advantage.
< 1762636367 372160 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I'm not sure what decision caused that policy, rather than using virtualisation
< 1762636383 150552 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(I wasn't involved in it, there was probably a good reason but I don't know what it was)
< 1762636422 467600 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :IIRC there's a paper from like 1988, 1989, that has an explicit proof that a CPU only supports safe paravirt/hypervirt when its ISA's instructions cleanly decompose into one of several safe possibilities. I don't recall the authors or title but it's pretty influential in CPU design.
< 1762636444 283613 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it's kind-of shocking how much containers are like VMs in practice despite being almost entirely unrelated technologies implementation-wise
< 1762636482 263525 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :So lore is that during the 90s Intel slowly adopted the lessons from this paper and then Google implemented containers basically as soon as the ISAs could safely do it. Whether this is true or not, TBH sounds kind of extraordinary to me. But it *does* have good historical support.
< 1762636526 493139 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think of containers as more needing kernel support than hardware support
< 1762636548 664439 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :like, the only thing you really need from the hardware is a decent MMU, and maybe the ability to trap on a few problematic instructions
< 1762636560 391471 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: TBH it might just have been standard Linux practices. I did bare-metal for Linux driver development and VMs were never in the discussion. For GPUs, VMs were mostly involved because VMWare wanted to do GPU passthrough, and they had their own internal folks writing the VM drivers.
< 1762636567 82768 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :virtual machines need a bit more, but still not that much
< 1762636589 152999 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: now I'm wondering whether it was to make life easier for the students
< 1762636604 623098 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so that they wouldn't have to worry about whether they were inside or outside the VM
< 1762636635 791679 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :It certainly wasn't to make life easier for the TAs, sounds like.
< 1762636652 883312 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :oh no, it was actually pretty easy for me, especially as I didn't have to do the reimaging myself
< 1762636695 458870 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and I was already used to walking around computer labs, there are loads of reasons a computer science TA has to do that
< 1762636759 798310 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Datacenter theory on the ground definitely hasn't caught up with economics of the cloud. I remember a boss whose main standard for whether a machine was being used well was whether the CPUs were pegged; we had a two-wrongs-are-right situation where he thought that a Python script was efficient because it pegged multiple cores.
< 1762636801 897259 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :But the cloud wants us to think of compute as a time-based unit that comes in discrete parcels and which we generally want to minimize. Totally different paradigm.
< 1762636804 449327 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :this is a direction-of-implication fallacy, right?
< 1762636818 312777 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :an ideally efficient program would be both CPU-bound and I/O-bound at the same time and thus would be pegging all the CPUs
< 1762636836 83344 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but, just because a program is pegging the CPUs that doesn't guarantee that it's efficient
< 1762636854 123757 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Ha, for sure. I think that for them it was even simpler than that: they paid for the machine and therefore they are gonna *use* that machine.
< 1762636886 151549 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Especially when the university pays the power bill, in that situation.
< 1762636905 140602 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I still remember being depressed by looking at a big compile with proprietary software and seeing that all four of the computer's cores were at 25%
< 1762636925 619378 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :like it was trying to spread the workload among cores but wasn't very good at it
< 1762637018 523884 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :seL4 has separate system calls for send, receive, wait. etc. My idea is that send, receive, wait, yield, locking, and transactions, are all the same system call, which can do all of these things at once. (There might be a small number of other system calls, although there also might not be needed; it is not sure yet.)
< 1762637061 452495 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :(This way, you can avoid some problems with needing to wait or send or receive each before the other that the order cannot be resolved, by instead specifying all of them simultaneously.)
< 1762637089 717441 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :zzo38: Yeah. I wonder what io_uring might look like for seL4. The kernel could have a sort of return-to-uring semantics that looks like a little bytecode interpreter, repeatedly dispatching messages without actually letting user code run.
< 1762637579 15802 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :“ a ‘typed main()’ where the entry point to a program gets to choose its own arguments” => what the, did zzo38 infect you somehow?
< 1762637603 589703 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: I came up with this on my own! although I'm not so surprised that zzo38 feels the same way
< 1762637617 461535 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :not just for that line but the rest of what you said about operating system interface design I mean
< 1762637646 503209 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :last time this topic of conversation came up I was surprised how much everyone in the channel was agreeing with each other
< 1762637764 706836 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :Note that if a program expects a capability of a specified type, it is also possible to specify any capability with the same interface. (You can also specify the low-level representation directly, but in that case the program is unlikely to work if it is incorrect, and might even crash immediately (although this will not cause the rest of the system to crash).)
< 1762638023 299524 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: Well, we're all from the same Unix-y tribe here: syscalls are good, files are decent but not universal, processes are a reasonable unit of work for most purposes. If anybody from the Inferno/plan9 tribe were here, they might say that we're completely wrong.
< 1762638034 251662 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Well, maybe they'd have interesting things to say about paths even in that case, actually!
< 1762638059 770777 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: I care somewhat about progressively upgrading existing systems
< 1762638078 627240 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I'd love to be able to replace the whole thing at once, but realistically I am not going to be able to write all that code at once and nobody would adopt it
< 1762638087 900478 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so, whatever I come up with, it has to be able to mix with what we already have
< 1762638122 439486 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and processes make a good abstraction boundary for doing that, because the existing software already understands and respects them
< 1762638172 473309 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Yeah. That's basically why I stopped working on Monte. The E approach is too totalizing. It makes sense if you've heard of Toontalk or seen any of the virtual worlds that Disney has built; E was born from a hope that a single cap language would be the way that everybody negotiates smart contracts in the metaverse.
< 1762638181 143756 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :My own idea does not have file names and directory structures (although there are files), and reduces the number of syscalls, so there are these significant differences from UNIX. There are also differences with the user programs, such as it does not use Unicode, and the l10n and i18n is entirely different from existing systems, and the window management is different, etc.
< 1762638226 317789 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :likewise, whether or not files are a good abstraction, they're what we have and you need to be able to understand them to interoperate
< 1762638226 901819 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :And then, there would also be the hardware differences, such as tagged memory, a different keyboard than PC and Mac, a dedicated keyboard port (not using USB), connecting the mouse through the keyboard, etc.
< 1762638245 384060 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :“OpenBSD has some sort of rule along the lines of ‘if a setuid process hits a runtime security check, its effective user can't run setuid programs for 15 minutes’” => am I the only one who thinks that set?id programs are a historical thing that we should phase out and eventually start to forbid in our file system settings or kernel settings or something because they're a bad idea, and we should 
< 1762638247 538790 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :Implementation within other systems may be possible by the use of emulation, though.
< 1762638251 414703 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :replace it by the user sending a request to a process that's already running with the desired effective user, because an execed set?id program inherits all sorts of process state from its execer and it's hard to sanitize all of them?
< 1762638303 590790 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: I don't think so
< 1762638326 690871 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I have something of a pathological and irrational hatred of constantly-running daemons, though, so I'm biased
< 1762638327 542473 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :b_jonas: Yes. s6 enables this sort of thing. In particular, there's a Nix distro called "sixos" that has just one setuid binary, doas.
< 1762638330 783045 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :b_jonas: I think that setuid is not the best idea but you would have to change the rest of the system too. Existing systems don't help much because it is still POSIX
< 1762638344 437800 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(I find it hard to justify this and it may have been one of the things that indirectly caused the NH4 devteam to break up)
< 1762638391 429368 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :if you want to pass capabilities to the set?id programs, we now have a way to pass them to unrelated processes through a unix domain socket, which is much more precise then just having them inherit *every* obscure state that a process has in the operating system
< 1762638416 692038 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: Using the Smalltix convention, so that a long-running process is the stack frame for a long-running method activation, perhaps you'd be interested in E's "no stale stack frames" rule. It has other names, but that one stuck because it's so descriptive.
< 1762638441 637192 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :Yes, a unix domain socket is better, although some things are difficult due to the existing working of the system, which does not handle user permissions in that way.
< 1762638474 963794 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :E doesn't allow stack frames to be suspended. It doesn't have any way to generate a coroutine or iterator; users have to explicitly close over an iterator's state. So a stack frame can never be "stale"; it can never be in a state besides "active" or "about to be reaped".
< 1762638588 848228 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :“virtual machines need a bit more, but still not that much” => not that much in theory, but they need nested paging which is a performance nightmare for processors to implement I think
< 1762638604 750052 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :The obvious analogue is uninterruptible sleep, but maybe there's a more general concept of "no stale long-running processes" where a daemon has to be *doing* something in order to be resident. s6 has ways of parking FDs, and there's ye olde ipcd on basically any supervisor.
< 1762638674 838028 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :“the cloud wants us to think of compute as a time-based unit that comes in discrete parcels and which we generally want to minimize.” => yes, but only if by compute you mean mostly RAM allocated times time, because that seems the most expensive part in practice, more so than CPU use
< 1762638776 439479 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :b_jonas: No, I mean CPU. When a cloud orchestrator like k8s "allocates" a container, it's allocating CPU time on the scheduler. k8s promises to only use a certain amount of compute per node, but it really is allocated. RAM is also allocated this way, but it's a distinct resource.
< 1762638885 562730 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Oh, I see what you're saying. Yeah, the most expensive resource has depended on market phenomena. Bandwidth is always expensive. Disks were expensive for a while after that one tsunami on Thailand. GPUs and SSDs were both expensive when they were first rolled out.
< 1762638919 995814 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: they don't have to be constantly running demon*s*, this is the case where systemd or something like a traditional inetd or webserver is useful, you have one program running as root that users can configure to be able to invoke any demon, and that top-level program is in a clean process state
< 1762638922 914799 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: to me, "no stale stack frames" is kind-of the default because I don't have a lot of experience with langauges that do let you suspend them
< 1762638938 650573 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: ooh, I see, a sort of local inetd
< 1762638973 982892 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Trying to remember what you usually work with. Go, maybe? Anything with "segmented", "suspendable", or "copyable" stacks is suspect.
< 1762638997 482758 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: initially C and Perl, more recently Rust but generally synchronous and single-threaded Rust
< 1762639037 468970 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :And yeah, after doing so much Python and then learning E, I can't go back either. It's just...why would you call Somebody Else's Code, giving them *your* control of execution, and just *hoping* that it comes back to you?
< 1762639057 954827 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :Rust does have generators internally but hasn't figured out the interface to them or all the safety aspects yet; it also has async/await which gives you suspendable things that are vaguely like stack frames, but they're compiled into state machines and don't actually use the stack
< 1762639078 832912 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and this has been quite controversial and doesn't really integrate into the language well
< 1762639093 262470 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it's there because people needed it and the theory behind it is probably really interesting but hasn't been worked out yet
< 1762639095 949098 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :IIUC Rust async/await uses Pin under the hood? So it's not doing anything nasty. It's not any worse than lambdas.
< 1762639139 169490 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :yes, it's just sugar for a state machine, the only magic is that it can contain pointers to itself (which isn't normally allowed in Rust) and Pin is needed to make that safe
< 1762639185 387179 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I realised fairly recently that this could be used as a way of defining the semantics of a self-referential Rust object, via representing it as a state machine with only one state
< 1762639213 887500 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Closing over *values* is fine and safe, closing over *control flow* is probably not okay. E continuations are delimited; when their associated frame is reaped, they go inactive. They're also single-shot, so that they can only interrupt Somebody Else's Code *once* and can't forcibly make Somebody Else's Stack Frame go stale.
< 1762639244 294485 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ok, then at least I have one weird operating system design belief
< 1762639249 778824 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so one of the big problems with Rust async is that the state machine is an object, which means you can drop it
< 1762639255 363997 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :you all seem to have much more
< 1762639286 192571 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and this is similar to the stale stack frame problem but different in that it behaves more like an unwind than a leak
< 1762639371 747679 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :b_jonas: I got radicalized by capability theorists. Honestly it's a miracle that I'm not doing blockchains.
< 1762639428 143213 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :`addquote  ok, then at least I have one weird operating system design belief   you all seem to have much more
< 1762639432 926565 :HackEso!~h@techne.zem.fi PRIVMSG #esolangs :1337)  ok, then at least I have one weird operating system design belief   you all seem to have much more
< 1762639438 871659 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :oh wow, great quote number
< 1762639463 247576 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Monte has external iterators because internal iteration requires the user to trust Somebody Else's Collection.
< 1762639501 82168 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :sorry, I don't mean it as an insult, on a channel about esoteric languages people *should* get all sorts of strange operating system design ideas
< 1762639506 212729 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I'm not convinced that "the best iterator interface" has been figured out yet
< 1762639508 652322 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: I know you don't
< 1762639512 422909 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I thought it was an excellent summary
< 1762639516 734555 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and funny at the same time
< 1762639538 587466 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(out of interest, which weird belief is yours?)
< 1762639566 971195 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :b_jonas: I appreciated it! I *know* most of my beliefs are not mainstream, but I don't always have a good measurement for *how* radical they are.
< 1762639598 761342 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :the belief that unxi set?id programs are a bad idea because exec makes a process inherit too much state that is hard to sanitize
< 1762639620 493479 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: ah yes
< 1762639623 890575 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I don't tihnk that's that weird
< 1762639639 823488 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Like, in 2017 in https://corbinsimpson.com/words/globe.html I wrote a paraphrase of the standard reply that I got from people who *understood* caps fully: "That sounds like a very interesting project. It sounds too elegant and experimental to see much use, though." and "Your ideas are interesting and maybe you could find a professor willing to take on you and your project."
< 1762639650 633237 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :If a new computer is designed to have too much compatibility with others then this can limit any of the newer benefits that are added (and can also have other problems such as sexurity issues in some cases), which is one reason to avoid it; emulation can be used (in either direction) for cases where more compatibility is desired.
< 1762639678 775983 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Now less than a decade later these ideas are so mainstream that they are getting into CPU design for the first time in decades. I don't feel like I shifted much since then!
< 1762639739 598703 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I remember unexpected bugs because some parent process execed a program with a signal blocked. Many programs that want to exec on unix already pre-fork, make the child do all the real work and have the parent do the fork-execs, because it's hard to make sure that the fork-execed don't accidentally inherit the wrong state. There are multiple libraries to help you in this. 
< 1762639742 994896 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :one thing I have realised is that an "is this a pointer?" bit is actually really useful – I am less convinced of the value of shadow capabilities though
< 1762639763 648928 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but the pointer bit makes GCs much simpler and probably more efficient too
< 1762639807 631304 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :b_jonas: I think that your justification is a little weird, but consider that for distros the argument is more like "setuid is bad because it requires our installer to do extra steps" or "setuid is bad because our immutable distro is fundamentally incompatible with setuid semantics". At best it's like "setuid is bad because malware can Live Off The Land".
< 1762639829 763752 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :So maybe your justification is too sane for distro development!
< 1762639836 379827 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: OK, so I had a problem related to that – I was thinking about passing capabilities to child processes, and thinking of a model of "everything is opened CLOEXEC by default and we dup-as-non-CLOEXEC in the child after forkign"
< 1762639855 59120 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and then was trying to work out how to soundly combine this with vfork
< 1762639885 47014 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :and this doesn't seem to be a mainstream belief, because unixes are starting to use sudo, which is specifically a wrapper to centralize part the hard work of sanitizing the inherited process environment for a set?id program. not all parts of course, some have to be done in libc, and you can't *really* sanitize everything, for the same reason as you can't have a webserver plugin or antivirus remove the 
< 1762639891 495734 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :"unsafe" parts of requests, and if you try you just get those silly things like when you can't type a less-than sign into a webforum because the plugin thinks it's an XSS attack
< 1762639958 879439 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: "starting" is wrong, they're gradually moving away from sudo in favour of less ridiculous replacements
< 1762639978 959175 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :from my point of view, like the only security benefit of sudo is having each user use a separate password to elevate to root
< 1762639984 381272 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :
ACTION imagining: affine file descriptors

< 1762639997 202351 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(and needing to log in as a user first before becoming root)
< 1762640009 990303 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :all its other features are just security snares, and some of them are ridiculous
< 1762640028 903068 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: at least the part that everything is opened CLOEXEC by default and you explicitly fcntl them to non-CLOEXEC when needed is I think pretty normal. non-CLOEXEC is just the historical default that's hard to change.
< 1762640037 764331 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: that's true, that is a good thing about sudo
< 1762640045 759774 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think other people are noticing that too, there have been a spate of less featureful sudo replacements recently
< 1762640091 329725 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: so the problem with dupping in the child is that dup returns a file descriptor, which under POSIX rules you can't actually store anywhere after calling vfork
< 1762640173 908142 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :I would hope that a collaborative document and discussion can be made for the system I intended to design, and then it can partially or fully be made (and the parts might be made indpendendently, or similar ideas on other systems (which can be similar enough to be interoperable with some parts)), either as emulation or as FPGA or as hardware (or a combination of these), etc.
< 1762640180 108162 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: in theory posix_spawn is trying to solve this because a wrapper in libc can break that rule by using architecture-dependent magic,
< 1762640189 866423 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :but I'm still not sure if I like posix_spawn or not
< 1762640195 869920 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: that was my thought too
< 1762640228 172508 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :then I realised a) the reason I was stuck on this in the first place was for writing a libc alternative, so I wouldn't be able to use posix_spawn anyway and b) posix_spawn is really confusing
< 1762640248 321359 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :(A combination would be to e.g. make the keyboard and connect to GPIO or using an adapter to USB (or MIDI or Ethernet or whatever else), and use an emulator on the computer for other parts of the system; the parts could then also be used independently with an alternative implementation.)
< 1762640255 927349 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :interestingly, Rust's process creation API is basically a more Rust-idiomatic version of posix_spawn because it was hard to ensure safety otherwise
< 1762640273 646624 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :um so? if you're writing a libc alternative you can add a posix_spawn alternative into it, can't you?
< 1762640303 229400 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: yes but it doesn't solve the original problem of not really understanding what is and isn't safe under vfork
< 1762640399 703205 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :yeah, vfork is hard
< 1762640442 286989 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :at least on Linux vfork is fairly simple because it still does COW memory like regular fork does, it's just a change to the scheduling algorithm
< 1762640461 217745 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :but I at least appreciate the elgance of posix_spawn that it can solve two problems with the same interface: one that vfork is hard to use, the other is that it can be a portable interface that works on both unix-like operating systems and systems that can't fork
< 1762640494 305423 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :yes
< 1762640516 167315 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I like the idea of posix_spawn, it's just that C rather gets in the way
< 1762640531 978875 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the Rust version is quite nice to use just because the language makes that sort of API more reasonable
< 1762640532 213817 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :it's just that I don't want to use this because the system I use that doesn't fork is Win32, and it's different from posix-like systems in many other ways than just not being able to fork, which is why I don't need this specific portability solution
< 1762640571 639792 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :yeah, there's a python version too
< 1762640598 959434 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I did some amount of serious programming on DOS, which also doesn't fork
< 1762640610 619120 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but I'm not sure whether I tried to create processes there using any language other than bash
< 1762640628 950447 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :…I have just realised that "ais523 is the sort of person who uses a DOS fork of bash" says a huge amount about me
< 1762640635 216919 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :err, DOS port of bash
< 1762640744 554821 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I haven't used that, but I do have an old version of joe the text editor compiled for DOS which I found useful. I can even distribute its binary if anyone wants. my config file isn't very good so some of the bindings may need to be changed, but it does work me as a basic text editor that's not as bloated as most that I have access to on DOS are, which is why I inlcuded it in my one floppy sized DOS boot 
< 1762640750 561585 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :floppy 
< 1762640830 632773 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I'm trying to remember whether I used Emacs on DOS
< 1762640832 449235 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think I did?
< 1762640909 319476 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :the visual editors that I mostly used in DOS are DOS's edit, which is in the same binary as QBASIC and so is somewhat big but was on an earlier version of that floppy; the editors in the GUI development environment for turbo pascal and borland C, which are bundled with a whole development environment with a full GUI interactive debugger in both source and assembly level; and ncedit which would work well 
< 1762640915 397200 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :on the boot floppy because it already has norton commander but it's not capable enough
< 1762640948 589011 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: I don't know, but you did nethack on DOS so emacs on DOS doesn't sound too unbelievable
< 1762640966 312647 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :(Another way to provide some compatibility would be optional hardware modules, e.g. the processors (or FPGA) for MSX and other systems)
< 1762640983 902637 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: oddly I'm not sure I ever played NetHack on DOS myself
< 1762640996 929072 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the TAS is doing it on the DOS version purely for emulation accuracy reaosns
< 1762641005 359055 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(I even submitted a patch to the emulator to get it to emulate NetHack correctly)
< 1762641080 617823 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :exactly, that version is more canonical than having to pick from many unix version, and for a TAS you want a canonical version that behaves the same for everyone. canonical behavior is easier for games on old video consoles.
< 1762641137 755044 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :and the technology for efficient accurate DOS emulation was already available back when you all started the TAS
< 1762641174 782526 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :Deterministic behaviour is also one of the things I intended for my computer design; proxy capabilities can be used for situations where the I/O would otherwise be non-deterministic, in order to force it to be deterministic.
< 1762641210 518016 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :zzo38: deterministic behavior is harder in general than for just the nethack TAS
< 1762641274 587121 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :Yes, I know it is harder in general, which is why I thought to redesign the entire computer to support it
< 1762641307 431637 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :but I think this isn't only about deterministic behavior, but *canonical* behavior, that is, it's deterministic and we want to show our sleeves empty so we didn't rig the behavior in a way that unfairly helps our TAS
< 1762641359 671102 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :OK, that is also valid, and I think that proxy capabilities might be helpful for that too.
< 1762641408 33095 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :because I can specify deterministic behavior with a C interpreter that makes sure that dereferencing invalid pointers in the interpreted program doesn't cause UB in the interpreter, but I can do it in a way where I can cause any invalid memory access read the exact values that I want, and that would be an unfair advantage for a TAS
< 1762641434 519191 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :now admittedly this would be more powerful for some other games than for nethack, but even so it's a good goal
< 1762641440 150427 :tromp!~textual@89-99-43-152.cable.dynamic.v4.ziggo.nl QUIT :Quit: My iMac has gone to sleep. ZZZzzz…
< 1762641480 249030 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :It will not work with C in general unless it is a specific version with a specific compiler running on a specific system, I think.
< 1762641521 704703 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :sure, but you can make it good enough to support enough of C that you can build and run nethack with it
< 1762641592 348896 :ais523!~ais523@user/ais523 PRIVMSG #esolangs : because I can specify deterministic behavior with a C interpreter that makes sure that dereferencing invalid pointers in the interpreted program doesn't cause UB in the interpreter ← can't you just turn off ASLR?
< 1762641625 410496 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: I don't understand the context
< 1762641645 598937 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :I expect it will be possible with my system, although some parts of the program will probably need to be changed (because e.g. fopen is unavailable, so you will need to use fopencookie instead; and you will also need to make it work with the I/O, although you could just use a terminal emulator without the ability to automatically respond, perhaps)
< 1762641651 936830 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :turn off ASLR where? for the interpreter, for the interpreted program, for the program compiled and ran with a normal C environment, and why?
< 1762641658 549302 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: if you want deterministic UB in C you can just remove the random inputs, any given compile will generate a particular asm and the asm is deterministic
< 1762641671 957595 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so you turn off ASLR rather than using an interpreter
< 1762641685 899731 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :admittedly this wouldn't work so well with DOS, which has no MMU and so programs kind-of have to be relocatable
< 1762641730 393721 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: sure, but you can be much more subtle in how you rig the execution, because you can pick the compiler and compiler option and the libc and curses implementation, and even some of the operating system behavior might influence nethack
< 1762641763 88834 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :so I think it's very hard to get a canonical behavior for a unix version of nethack
< 1762641854 36724 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :whereas DOS has a canonical version, DOS 6.2, and a canonical minimal set of drivers that you load (it's not the *usual* set, the usual set is to use the windows 3.11 version of himem.sys rather than DOS's, but Windows have more than one version so it's less canonical)
< 1762641871 931993 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :DOS 6.22 sorry
< 1762641895 620193 :tromp!~textual@2001:1c00:3487:1b00:b9c6:2c55:4165:c029 JOIN #esolangs * :Textual User
< 1762641918 893737 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :more easier to agree on one environment that you use to run all DOS games for which this works for TASing purposes
< 1762641984 940494 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :like, the C behavior on unix will depend on at least how libc's malloc behaves
< 1762641996 603990 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :and probably on more than just malloc
< 1762642020 804043 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: so it becomes a bit less canonical due to the DPMI extender
< 1762642036 785824 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I see
< 1762642040 648194 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :which takes on some of the roles that libc+the kernel would normally be responsible for
< 1762642045 792202 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :and perhaps the BIOS
< 1762642048 792699 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the usual DPMI extender is Windows but it doesn't emulate well
< 1762642062 255170 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :and the DOS behavior can depend on how the file system is layed out,
< 1762642074 924359 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :for TASing, the decision is fairly simple: FreeDOS as the BIOS because we can emulate it legally, and HDPMI32 as the extender because it's the only one that emulates correctly
< 1762642086 164524 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :and may depend on what exact version of CPU you have if you can get the program to execute arbitrary code
< 1762642094 742933 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(and even then I had to add a feature to the emulator to make it emulate correctly)
< 1762642129 374545 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :tasvideos.org already has a standard "emulated DOS system" for TASing on so I didn't need to worry about things like the CPU version and frequency
< 1762642135 771723 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :oh, that actually makes more sense even if I didn't use FreeDOS for running emulated DOS games
< 1762642181 631367 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I always just used my DOS 6.22 installation that's derived from that first DOS installation that I started when I got my first own PC (as separate from the one PC from the family)
< 1762642213 62520 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :obviously it changed a lot since, but there's an unbroken line and the DOS and Windows 3.11 installation is the exact same
< 1762642296 290828 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :“tasvideos.org already has a standard ‘emulated DOS system’” => that's great, then DOS is even more of an advantage. do they have any standard Windows systems, or is that too hard because of licensing issues?
< 1762642312 2407 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :no, Windows TASing is actually really janky
< 1762642316 345531 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and keeps breaking all the time
< 1762642327 662100 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :oh sure, but that's for other reasons too 
< 1762642335 380485 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :because it isn't an emulator, it's basically done using the Windows version fo LD_PRELOAD
< 1762642340 421053 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :like delivering the inputs deterministically
< 1762642352 280513 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so you have to rely on whatever software+kernel setup the users happen to be running
< 1762642423 304620 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :yeah, and for that reason I'm so glad Celeste added a built-in reason to read game control input from a file
< 1762642430 944503 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :s/reason/way/
< 1762642466 590490 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :funnily enough, I kind-of invented TASing on my own before learning about it being a thing
< 1762642476 670530 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I had written my own computer game, and wrote a replay format for it
< 1762642487 79307 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but instead of recording player input, I created the replays by brute force
< 1762642505 716161 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :that sounds more of the "zzo38 infected you" thing
< 1762642516 804931 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :even if it's retroactive
< 1762642585 442438 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I wanted to see what an optimal level playthrough was like
< 1762642612 677598 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the thing is, I didn't know whether my computer had enough memory to hold all the possible states a game could be in (and I was brute-forcing basically via Dijkstra's algorithm, although I didn't know it at the time)
< 1762642632 896590 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so I stored the brute-forcing progress in the largest bit of memory I knew about, which was video RAM
< 1762642642 982344 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and so I got to see the brute-forcing in action on screen
< 1762642709 969958 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :The replay format is something I intend to make in Super ZZ Zero game engine, although it is something which is not currently implemented. (Hopefully this can be used for regression testing as well as for other purposes.)
< 1762642815 887447 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :hehe
< 1762642842 532724 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Maybe *that* is the biggest divide here. I'm an athletic speedrunner but not really a TAS'er.
< 1762642930 259133 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :hehe, I'm not sure if that counts as the *biggest* divide
< 1762643114 725216 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :I also wanted to know if the design of a VM code for a music file, I have some opcodes that have a variant that includes a wait and some opcodes do not have such a variant. The range of opcodes that have such a variant is not many unused left, and I put the ones for one, two, or three MIDI bytes in the waiting range and the one for arbitrary size data in the non-waiting range.
< 1762643120 26230 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :Is this the best way to assign them?
< 1762643133 183207 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :(You can see https://raw.githubusercontent.com/zzo38/superzz0/refs/heads/trunk/music.doc for the actual document, if you want to see it)
< 1762643276 535573 :tromp!~textual@2001:1c00:3487:1b00:b9c6:2c55:4165:c029 QUIT :Quit: My iMac has gone to sleep. ZZZzzz…
< 1762645788 771663 :pool!~nathan@user/PoolloverNathan QUIT :Read error: Connection reset by peer
< 1762645819 416126 :pool!~nathan@user/PoolloverNathan JOIN #esolangs PoolloverNathan :nathan
> 1762646398 22748 PRIVMSG #esolangs :14[[07Language list14]]4 10 02https://esolangs.org/w/index.php?diff=167715&oldid=167643 5* 03PrySigneToFry 5* (+40) 10