Start with some ideas and some bibliography

1 files changed, 151 insertions, 0 deletions

diff --git a/Proposal.md b/Proposal.md
new file mode 100644
index 0000000..d1a5bc7
--- /dev/null
+++ b/Proposal.md
@@ -0,0 +1,151 @@
+# A computing platform that embraces the language
+
+## UNIX's influence
+
+> Applicants must also have extensive knowledge of Unix, although they should
+> have sufficiently good programming taste to not consider this an achievement.
+>
+> -- Hal Abelson
+
+### Von Neumann's heritage
+
+Leaks permission issues
+
+### FileSystem
+
+- folder-based
+- Everything is a file
+
+Other options: mobile OS's approach (they hide the filesystem under an index),
+RelFS...
+
+#### UGO?
+
+### Text as a universal interface
+
+Text has no structure, forces you to parse things all the time. 1 parser per
+program...
+
+### Processes & threads
+
+They don't exist. It's a person that decided they should.
+
+One(or multiple?)-thread-asynchronous system à la JavaScript can be good.
+
+### Virtual Memory
+
+Needed for the binaries to be run directly in CPU but with some protection.
+It's a broken model but it was born for the right reasons:
+
+- (virtual) infinite memory => we can use garbage collection for that instead
+- Correct permissions => Capability based security?
+
+### System Calls (kernel is king)
+
+Interrupt based. Monolithic vs Microkernel.
+Thinking about the kernel as a resource manager.
+
+System calls are passed via registers and a very-low-level ABI (everything as
+integers).
+
+Why not embrace the language and its structures and make them be "Just" a
+function call.
+
+### Interpreters
+
+Each language has its own interpreter. The interpreter is a resource manager
+for the language (allocates memory, uses sockets, files...) but using kernel's
+resources: Two layers of the same stuff.
+
+    Language -> interpreter -> kernel -> cpu
+
+Do we need all?
+
+#### We add layers, but all is an Integer in the end
+
+We have tons of layers but in the end we have a Kernel that is an
+integer-interpreter. This leaks too many details to the user/developer.
+
+
+### Shell (fork+exec)
+
+Metion "a fork in the road" paper.
+We can do better. Fork+exec embraces the Unix model, not the language.
+
+### Users (now used for permissions)
+
+Users as persons using the computer, not as programs. I'm the only user of this
+machine.
+
+### Permissions
+
+They are a concern, so bad, it appears everywhere in different ways:
+
+- Memory
+- Processes and threads
+- Filesystem (ugo)
+- Users
+
+Why not a unified permission system?
+
+
+## A different world
+
+### Capability Based Security
+
+seL4 => uses identifiers as keys for the capabilities
+
+Use an interpreted language and give capabilities as functions in an
+environment: they can be mocked! Or manipulated! Or executed remotely in a
+distributed fashion!
+
+## No interpreter-kernel-CPU distinction
+
+Everything is a function/value
+
+## No fixed ISA
+
+We can extend the language as the base of everything and be able to rebuild the
+CPU live, using the same language we use to manipulate it.
+
+## No processes/threads
+
+Event loop maybe?
+
+## Am I taking the ideas of a browser??? Hehe
+
+## Scheme as the heart (R7RS Small)
+
+Lambda calculus approach: everything is a function
+
+It's not text, but Lists.
+
+It's dynamic.
+
+Garbage collection for infinite memory (maybe in hardware). Hardware-assisted
+interpreter.
+
+
+
+## Developers
+
+Developers understand what a function call is. We are NOT adding more
+constructs, but removing some that have nothing but historical sense.
+
+No need to think in Integers anymore. Functions are king now.
+The Kernel is a lambda calculus interpreter.
+
+## Possible usages
+
+Small computing / field device.
+
+> Remember, it's not a personal computer if you can't just paint a line in the
+> screen
+
+It could delegate some complex functionality to a server (remote interpreter)
+installed in a conventional machine.
+
+## Personal computing
+
+Oberon, TempleOS... Computing for one person. That one person can totally
+manipulate, alone.