summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorEkaitz Zarraga <ekaitz@elenq.tech>2024-04-20 16:44:25 +0200
committerEkaitz Zarraga <ekaitz@elenq.tech>2024-04-20 16:44:25 +0200
commit5ab6c0d2dd041becef6915469f493c87b5d16d77 (patch)
treebff73aa35bb5a0d636df3508d7a0b5f2a63ac681
Start with some ideas and some bibliography
-rw-r--r--Proposal.md151
-rw-r--r--bibliography.bib20
2 files changed, 171 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.
diff --git a/bibliography.bib b/bibliography.bib
new file mode 100644
index 0000000..ebb9957
--- /dev/null
+++ b/bibliography.bib
@@ -0,0 +1,20 @@
+@inproceedings{ LionsOs:Heiser,
+ address = {Gladstone, QLD, AU},
+ author = {Gernot Heiser},
+ booktitle = {Everything Open},
+ month = apr,
+ organization = {Linux Australia},
+ title = {{Lions OS}: Secure -- Fast -- Adaptable},
+ year = {2024}
+}
+
+@article{ Threads:Lee,
+ author = {Lee, Edward},
+ year = {2006},
+ month = {06},
+ pages = {33 - 42},
+ title = {The Problem with Threads},
+ volume = {39},
+ journal = {Computer},
+ doi = {10.1109/MC.2006.180}
+}