Anyone interested in resuscitating the Esoteric OS? Have a look at http://lilly.csoft.net/~jeffryj/programs/eso/catseye/catseye.html it's a small piece of what was previously discussed on the Esolangs mailing list.

My take on the matter is that implementing the whole thing from scratch is, well, hideously slow, time-consuming and not to mention complicated. Maybe we should use an existing platform (one that works on several architechtures, maybe?) and build the APIs, filesystem and virtual machine on top of it. Or maybe just implement the whole deal inside a virtual machine to begin with? Emulating http://www.clifford.at/bfcpu/bfcpu.html might be a good (ie. esoteric) start.

I don't know much about these things, but I assume implementing the whole thing inside a virtual machine would be the best. Afterall, it's guaranteed that there will be thousand of errors during the design phase, and I wouldn't like to be the designer whose all data on hard drive gets accidentally replaced by 0-bytes. :D

So, a virtual machine would be the best, probably. It should be safer.

Here's a rough sketch for the New And Improved Esoteric Operating System.

The Brainfuck Esoteric Virtual Machine (abbreviated as ZARDOZ). Interprets Binary Brainfuck (BF translated into binary form to conserve space)

• Esoteric File System (MUNG) . The internal representation of files. Stored in a single file in the host OS's file system.
• Device Abstraction Layer for Esoteric Kernels (DALEK). How programs running in ZARDOZ access different devices.

Now, I know everybody enjoys writing Brainfuck by hand (if BF is to be the language the whole shebang is based on), but if the project is ever going to advance it will need a higher level language (like Clifford's BFC and BFA). BFC and BFA are quite non-esoteric, so we might want to look into selecting a language to use to generate the Binary BF for us. Or just ask Clifford if we can gratuitously use and modify his tools.

We could start out with just one Binary Brainfuck compiler (maybe based on BFC and BFA), and then when the project progresses we could implement more languages.

Anyone interested? If we get enough momentum, we could Wikify the project and get more people on board.

I don't understand how these work.. :) But anyways; if making EsoOS, we could design something bizarre computer thing (although not building it for real, but in software) that wouldn't have the traditional bits and bytes as memory or such. Possibilities are almost endless. :)

When I designed MISC, I deliberately constructed it so as to make it just about possible to write an operating system (or other sophisticated software) in it:

1) All the jump addresses are relative, so code can be executed anywhere in memory - all you have to do is overwrite the return address, and if necesary pass the code its location (so that it can access absolute memory address to call standard code or access IO).

2) The address/number flags are stored in the top two bits of the fourth word (in the draft specification they were in the bottom two bits) - this makes it far easier write a disassembler is MISC, as checking the top two bits can be done with far fewer operations than checking the bottom two bits.

Furthermore, writing a virtual machine is really easy, and constructing a real MISC machine shouldn't be too difficult.

Hmm... I might climb on, as soon as there's something obvious to do. Seems like we'll need ZARDOZ first, but that should be easy enough to write.

As I see it, the first step would be writing the portable binary Brainfuck interpreter (ZARDOZ as I abbreviated it) and a BF -> BBF compiler. Think of it as a bytecode.

This step should be simple enough.

But how to implement ZARDOZ? It'd probably be best to split it into kernel- and userspace, with the rudimentary userspace containing a couple of built in tools like a command like (hmm... wonder what that's going to look like).

Unfortunately I have no experience whatsoever in leading software projects, so I don't have a clue how to break this down into manageable bits.

I don't understand why it needs to be binary brainfuck..
And in which language the portable binary brainfuck interpreter should be written in? In brainfuck?

What about graphics? A graphical screen would be cool.

Anyways, this project sounds interesting.

Note that my BOS operating system is a BF based OS (with special function calls). Although it was fun to write, it was very familiar, and also felt dirty, because I tampered with BF to get the needed functionality. It just didn't seem "pure", and it definitely didn't feel esoteric anymore. BF is a well understood language these days. I agree with Keymaker. Perhaps we should get away from bits, bytes, and BF and come up with something new. Moving away from BF, is IMO, a step in the right direction.

The reason I say this is because BF is just a few steps removed for assembly language. That's not very interesting.

One thing that I'm not sure we ever resolved in the original project is that if the underlying language isn't exposed, the OS becomes purely a function of the shell or interface. In that case, it would be easiest to write the OS in C or such, as the choice of language then doesn't really affect the user at all. How can the choice of language be exposed so that the user can't get away from it? The OS language should affect everything they try to do so that they cannot simply bypass it. In other words, I believe that interacting with the OS needs to be in the form of writing a program, rather than some obfuscated shell. If we want only an obfuscated shell, that can be done on top of Linux.

Having the user interact with the system in terms of a programming language doesn't eliminate the possibilities of obfuscating memory or file activities. It will actually give new possibilities for furthering the obfuscation.

Ideas I hope that can be incorporated:

• avoid bits, bytes as Keymaker suggests

• avoiding memory and arrays of memory, in the traditional sense. Perhaps some nonstandard data structure modified to be even worse.

• avoid traditional files or sectors. I don't mean forcing the use of disk sectors either. It should be necessary to write an algorithm to reconstruct old data. And that algorithm should be able to change to inflict extra pain.

• avoid devices that all work the same (for example the unix device as a file model). I think every device should intentionally be different than the others, with its own API (and there shouldn't be a central API entry point). Also, blurring what a device is should be a priority (perhaps entangling devices so that multiple API's would have to be dealt with to separate, say outputting to the screen and beeping, then after that, have the API change somehow). Having things like stdout or /dev/audio is just too easy.

• Program flow should (IMO) not be linear. What I mean by that is languages like Befunge where even if it's two dimensional, it's still easy to trace a path. I really like the idea of C-Intercal's COME FROM. I think there has been some work in this area lately. Glass is OO, for example (not that ZARDOZ should or shouldn't be).

To sum up my vision: an OS where the user has to type in a program to get done what they want to get done: such as reading data from a disk, running an "app", having the api specs change over the course of that program, and not being able to write the program that does this in a logical order. Apps should be similarly afflicted. There could be more than one way to do a thing, but each should be equally painful, so that the choice of one path makes you wish you had the features of the other. Also, the OS would of course be modified as things are done, so that each command would require relearning. Thus, each person's ESO would necessarily start the same out of the box, but quickly become unique as they used it.

Thoughts?

<GregorR> I think in the last para you got a bit overzealous.
<GregorR> I don't know if I agree that it should change with time :P
<calamari> well, the idea is that it's not an os and shell, they are one
<calamari> so whatever you do in the "shell" directly affects the os
<GregorR> I agree with that part.
<GregorR> But the way you put it it seems like you couldn't do an ls command (whatever that may be) twice ...
<calamari> well, you couldn't, because the api would change and you'd have to write a new program to run ls
<GregorR> See, that's where I stop agreeing :P
<calamari> Might be difficult for them to learn the new api :)
<calamari> actually it might be impossible, as each probe to try to determine how the new api worked would change the api
<calamari> unless the api changed in a predicatble way
<calamari> hehe
<calamari> you're probably right
<GregorR> :P

"The OS language should affect everything they try to do so that they cannot simply bypass it."

Yeah, otherwise someone could just copy there the binary code of some virus and the program would just let it to execute its own code. In other words, everything that can be executed must be in some esolanguage the OS supports (naturally new ones can be programmed within), and no external code can be executed.

As calamari (and I) said, we should try something entirely new, not have bits and bytes and such. Something entirely new, but bizarre.

Sound great. But getting away from bits and bytes is seriously impeded by the fact that the VM is running on bits and bytes :)

Oh, and on API design:
The API should be designed so that the underlying structure can change but the interface stays the same. For example, the doXyzzyFryzzy() function name and parameters should remain the same, but what happens under the hood can and should change. Sometimes, of course, this is not possible.

Here's another viewpoint:

• I don't like making the system deliberately painful to use. Think of INTERCAL, for example. It's not designed to be a pain in the gluteus maxima (think Malbolge...), it's just very very different.

• The constantly changing API is a real nightmare. Having to rewrite programs after every time they're run doesn't sound like fun to me.

• I do like the idea of changing every paradigm available, though. Like instead of linear memory, make it a "stream", so instead of letting the user move the memory pointer like in Brainfuck, it's just automatically incremented every time memory is accessed. Here's an example with some C-ish pseudocode:

In this example, the "memory stream" starts out containing the text "qwertyuiopasdf".

num = mem_pos() // returns 0
char = get_mem() // returns 'q'
num = mem_pos() // returns 1
char = get_mem() // returns 'w'
...etc etc etc

Or how about incrementing the pointer when any access to memory, so even the mem_pos-ish functions would cause the pointer to be incremented as a side-effect.

This is all very low-level of course, but that's how I think OSs should be implemented anyhow :)

I'm not sure was it dream or just morning, but I got one idea for the life system; all the files would be like stacks. And when reading from one you start from the end instead of beginning.
There was some other idea as well, but now I've forgot it.

Okay, this seems... confusing. Should we base this on a functional language or an imperative one, or something else entirely?

My suggestion is that the "baseline" language of the system is very low-level (like brainfuck or befunge), and we should implement a higher-level language using the aforementioned language.

Other than that, all I can say is that I'd like the whole thing to be different. Not just a BF compiler with a twist, but something that's completely new. Something that requires a whole lot of lateral thinking.

(Keymaker, nyt vasta tajusin että oot suomalainen :)

Okay. Let's make the language as referentially transparent as possible... like a list of function primitives that apply themselves to each other, and have the primitives be such that evaluation order doesn't matter.

I'm sorry but I have no idea whatsoever what you just said :)

Well, suppose you have a program like "ei4", and "ei" evaluates to "5" and "54" evaluates to "n". Then, if "i4" evaluated to "T", "eT" would also have to evaluate to "n". Evaluation order just wouldn't matter, and it couldn't in this little paradigm.

I'm not sure I quite grasp what >>17,19 has in mind exactly, but I do like the idea of using functional programming concepts. They increase the esotericness level.

Man do I feel stupid. I can grasp the ei4->54->n evaluation, but how did i4->T->eT->n happen?

Forgive my meager brain, I've been forever crippled by imperative languages.

Man do I feel even stupider. Took me a while to understand that one...

But how would something like that be implemented in practice?

Hmmm, I guess that would be something like Thue.

ORBAT -- you're Finnish too? Cool! :)

Yeah: A deterministic subset of Thue.

Hum de dum dum.

Anybody got any Turing-complete deterministic half-Thues? Or maybe we could run back to a functional language with esoteric primitives?

What's a half-Thue?

I'd guess half-Thue meant the rules were read from the beginning to the end instead of randomly picking them up.

I meant languages defined in Thue.

Well, I guess nobody has one. Why don't you take a stab at it?

xy -> (x*y)%k

Is this both deterministic and Turing-complete for any values of k? It seems deterministic for k=10, but I doubt it's Turing-complete here...

Can you write an infinite loop in it? If not, it's not Turing-complete. For k=10, and assuming x and y can only be the digits of base 10, it's not possible to write an infinite loop.

Hmm, I suppose it's not possible there.

{x,0} -> {x,x,x}
{x,y} -> {x,x%y}

But this isn't deterministic. {1,0,0} can evaluate either to {1,0,0,0,0...} or to {1,1,1,1,1}, or maybe even something else entirely.

As well, there's no way for a loop to exit: {1,1,1,1,1} up there simply evaluates to itself an infinite number of times.

Well, after noticing that most posts in this thread were done by people with Fibonacci numbers of characters in their names, I decided to try something based on Fibonacci numbers. If we define "fib" to be [1,2,3,5,8,13...], then we can have that {a,b,c} -> {a,a,a,a...c} where there are fib(b) a's.

Now, all I have to do is prove that this is nondeterministic and start over again.

Well, I propose that we go back to some other paradigm and work on a design for MALEK: the Memory Abstraction Layer for Esoteric Kernels. Why would anybody ever want memory abstraction? Because that makes it more esoteric-er! :-)

Well, suppose we have a program written in Anonymous Referentially-Transparent Functional Language #1. The MALEKifier is applied to our program, thus tossing the program into memory space. The program is then applied to the remaining memspaceifier. Since this program of ours has to fit inside the memspace currently allocated to it, it should have the identity function applied to itself a few hundred times, or something like that, for up until we get a chance to use this remaining memspace. (If the memspace allocator is ever used as the third argument to an S or W combinator, it's actually split into two memory blocks.) Now, applying another memspacer to a function will put that function into its own bit of memory space, then apply that function to the leftovers: all this again and again until we finally decide to throw some precious memory in Ye Olde K-Trash.

The details are left to you guys >:-)