*rolling around on the floor holding head* language runtimes are so interesting… operating systems are so boring… why are operating systems so much more useful than language runtimes. It's not fair
Someone replied to this with "C# OS" and DON'T PUSH ME, I MIGHT FUCKING DO IT. I AM BETTER EQUIPPED TO DO THIS THING THAN I AM TO DO ANYTHING USEFUL
@bob I AM ALWAYS THINKING LISP MACHINE THOUGHTS. AND I DON'T EVEN LIKE WRITING LISP. I JUST LIKE IMPLEMENTING LISP
@poetaster @bob essentially the one-sentence summary of my goal is "i want retrocomputing without the retro".
@secretasianman In a lot of ways they are the exact same thing except the language runtime gets to skip the boring parts. Because the OS team did it for you.
@mcc maybe we can bring back FoxNet and the Hello operating system
@cdrichards imagine writing ML but without a garbage collector. Oh no we just invented Rust again l
@poetaster @bob the part where it's old. the part where you root in the assumption of less RAM than the lowest-end RAM chips available on the market and less CPU clockrate than a Cyclone V can handle
@poetaster @bob i want a retrocomputing that is based in the embedded commodity parts of this and the next decade instead of based in the embedded commodity parts of the 1990s. they stopped making new Z80s, like, last year.
@mcc I have not implemented an OS kernel. Sufficiency for an OS kernel aside, you don’t need to go all the way to Rust. You could go in the MLKit direction and use arenas/regions. Sadly you cannot use MLKit without forking it because of AGENTS.md.
@mcc I sense I have failed to add value.
Let me just say I share your goals and hope you find the time and the people to make them happen.
@cdrichards If you could explain "regions" to the extent I finally understand them that would be fantastically useful actually because I know MLKit uses those but I still don't know exactly what they are, LOL
(to be more serious, i *very* much like MLs, but if i were to drop someone else's language runtime direct atop UEFI, the .NET CLR is more likely due to its greater versatility and its more formal efforts to replace the functions of an operating system)
@cdrichards @mcc I'm working on a project right now to run Idris code more easily atop the seL4 microkernel. Advantages being that Idris has an anti-LLM stance and a clean interface for compiling down to different intermediate languages, along with a rich type system, and that seL4 is fairly stable and has formal proofs of compliance to spec; this would seem to render remaining at the "tip" of development less relevant. (Said "tip" is an extension applying capabilities to CPU time.)
@cdrichards @mcc (Relevant because Idris is one of those ML-like languages.)
@lykso @cdrichards That's very interesting. Do you (I can already say you know more about microkernels than I do) have any sense of how close running atop the seL4 µkernel gets you to running atop the Redox µkernel?
@mcc we neeed project Midori, MS binned so much cool research
@mcc @cdrichards Redox is far, far ahead in terms of utility. However, I don't consider it a viable long term solution, in part because it is built on LLM-infested foundations, and in part because of the difficulties inherent to bootstrapping Rust from anything but the one official compiler. It's really not in a strong position.
@lykso @cdrichards yeah, i'm familiar, i've yet to write a program with it but it's on my list. one problem is i'm not sure i have the abiilty to write idris, it might be Too Much for me.
otoh, before "rust sitting in a big puddle of Slop?" I was thinking about making a garbage-collected interpreted Rust as a ladder down to people for whom Rust is Too Much. so maybe i could build a relaxed Idris as a ladder up from where I am to Idris?!? (this paragraph may not make sense.)
@lykso @cdrichards "Edit: Also, the memory model is left up to the intermediate language"
Do you know, has anyone tried a memory model like Rust ownership? Or uh… r… "regions"? MLKit regions? That's a thing if you want exact pauseless memory management right?!
@LunaDragofelis microsoft has not yet demonstrated an equivalent willingness to sue someone for reimplementing software they had previously released as an open standard
/Cinny
@LunaDragofelis @mcc iirc jazelle comes with a lot of asterisks that make it not worth it (which is ultimately why it was removed)
for example: a valid jazelle arm chip can just defer to the software implementation for all instructions
also loving this citation needed on wikipedia
The most prominent use of Jazelle DBX is by manufacturers of mobile phones to increase the execution speed of Java ME games and applications.[citation needed]
@mcc @cdrichards Sorry, I must've misunderstood. I don't know what the Redox microkernel's interface looks like, but I see there's a POSIX userland already running atop it. I don't know how much of that POSIX interface is a part of the kernel versus part of the userland.
seL4 gives you very little. Conceptually there are three system calls: send, wait, and yield. There are a handful of kernel objects in addition.
@mcc @cdrichards The primary attractions for me, from a technical standpoint, are the strong guarantees about memory and process isolation and the integrity of the capabilities system. The low impact that these protections seem to have on the kernel's speed is also nice.
@lykso @cdrichards what does one do [in Sel4] if one wants to do input/output of some form?
like i assume there are kernel servers for keyboards and something for a terminal emulator. are framebuffers part of what that community does? mice? asking because i'm curious.
@secretasianman @mcc yes and no; they overlap but not completely. At least, the way I use the terms, the operating system coordinates access to hardware, including providing drivers and APIs to expose functionality, without necessarily translating that into an API that’s convenient or consistent for a programmer. A language system provides notation and APIs that are consistent with eachother, and a translation layer to at least one OS’s APIs, but (usually) no drivers
@secretasianman @mcc modern OS’s provide enough abstraction and language systems have enough shared concepts (files, networking, having to agree on a character encoding, etc) that there’s a substantial shared “middle”, but the OS exclusively handles the “bottom” (hardware) and the language handles the “top” (app programmer).
(I’ve thought about this a lot because of how deeply it annoys me when I want a feature from one language’s builtins in another language and it isn’t there)
@charlotte @mcc @LunaDragofelis this reminds me of how Transmeta CPUs demonstrated "native" (in the same sense they ran x86 "natively") support for running Java bytecode.
@LunaDragofelis @mcc Hadn't heard of that. That basically makes them modern Java machines then? Huh.
That's more of an "upstream" OEM kind of work (and it seems very badly documented if the wiki page is right, explicitly for abusive OEM shenanigans, at that) though (with all the downsides it implies; hardware LispMs died for a reason, though perhaps they could work with truly Libre hardware), downstream would be JVMs running on bare ARM64.
@lispi314 @LunaDragofelis I'm not so sure about the "modern" part. I think this might have been like, 2008
@lispi314 @LunaDragofelis (until the slop gets so dense the pipe clogs up and new edits stop working, of course)