mirror of
https://github.com/20kdc/OC-KittenOS.git
synced 2024-11-23 19:08:05 +11:00
128 lines
5.1 KiB
Markdown
128 lines
5.1 KiB
Markdown
# KittenOS: A graphical OpenComputers OS that runs light.
|
|
|
|
## Why?
|
|
Because OpenOS needs *two* Tier 1 memory chips to run a text editor,
|
|
in a basic console environment that reminds me of DOS more than a Unix,
|
|
despite the inspirations.
|
|
This OS only needs one Tier 1 memory chip - that's 192KiB...
|
|
|
|
## Couldn't save a file from a text editor on a 192KiB system.
|
|
|
|
Switch to Lua 5.3 - Lua 5.2 has a nasty habit of leaking a big chunk of memory.
|
|
|
|
Given this hasn't happened with Lua 5.3, I can only guess this is an issue with 5.2.
|
|
|
|
(Tested on OpenComputers 1.6.0.7-rc.1 on Minecraft 1.7.10.
|
|
Judging by the "collectgarbage" call in machine.lua,
|
|
they may have the same problem???)
|
|
|
|
## Why the complicated permissions and sandboxing?
|
|
|
|
Because I wanted to try out some security ideas, like not letting
|
|
applications access files unless the user explicitly authorizes access
|
|
to that file. Aka "ransomware prevention".
|
|
|
|
Yes, I know it uses memory, but I actually had *too much* memory.
|
|
|
|
## Why is the kernel so big and yet in one file?
|
|
|
|
File overhead is one of the things I suspect caused OpenOS's bloat.
|
|
(It helps that writing the kernel like this reduces boot time -
|
|
only one file has to be loaded for the system to boot.
|
|
More files are required to use some functions which are used relatively
|
|
rarely - like the file manager - as a tradeoff on memory.)
|
|
|
|
## Why does get_ch exist? Why not use a window buffer?
|
|
|
|
Because memory.
|
|
This way, 80x25 and 160x50 should use around about the same amount of memory.
|
|
It also fit nicely with the way only sections of the screen are drawn.
|
|
|
|
## Why do the window titlebars look inverted on Tier 3 hardware, but not Tier 2?
|
|
|
|
There was a bit of value trickery required to get the same general effect on all 3 tiers.
|
|
|
|
## Why do I have to return true in so many functions if I want a redraw?
|
|
|
|
Because if you redraw all the time, you use more energy.
|
|
|
|
(Though energy's really a secondary priority to memory, costs resources
|
|
all the same.)
|
|
|
|
## Why aren't (partial redraws/GPU copys/GPU copys for moving windows) supported?
|
|
|
|
They didn't seem to be a requirement once I optimized the GPU call count.
|
|
|
|
If the system had still been running slow after that, I'd have done it.
|
|
|
|
## Why does the text editor use up so much (energy/time)?
|
|
|
|
The text editor is probably one of the bigger windows in KittenOS.
|
|
Try making it smaller with the controls it gives.
|
|
|
|
## What's "lineclip"?
|
|
|
|
A poor excuse for a clipboard.
|
|
You don't need to interact with it,
|
|
though *Shift-C* on it kills it (thus clearing the clipboard).
|
|
|
|
## Why is *Shift-C* used everywhere to safely close things?
|
|
|
|
Because Enter is used as an action button, Escape's right out,
|
|
Delete's probably missing on keyboards by now,
|
|
*Ctrl-C* is also copy, and anything with Alt in it
|
|
is supposed to be a Window Manager trap.
|
|
|
|
## Why is there no "kill it" button?
|
|
|
|
I'm sticking it here so that people don't make using this a habit -
|
|
so that application developers can do something before app death.
|
|
|
|
If you must ask, *Alt-C* will kill the currently focused app.
|
|
|
|
## An app infinite-looped / ate memory and the system died.
|
|
|
|
Yep. There isn't much of a way to protect against memory-eaters.
|
|
On the other hand, you do know not to start that app again, and it
|
|
didn't get a chance to do harm.
|
|
|
|
## Isn't building a window manager into the OS kind of, uh, monolithic?
|
|
|
|
Given the inaccuracies relative to real computers anyway,
|
|
I think of it as that OpenComputers itself is the kernel,
|
|
but it can only handle a single task, written in Lua,
|
|
so people build on top of it to make an interface.
|
|
|
|
(And given the memory limitations, having a cooperatively multitasking
|
|
microkernel which then gives all it's capabilities to the window
|
|
manager would succeed only in complicating things and then using all
|
|
memory, in that precise order.
|
|
This way accomplishes the same thing, and it's simpler.)
|
|
|
|
## How's multilingual support?
|
|
|
|
Multilingual support exists, but the languages are Pirate and English.
|
|
Most applications are bare-bones enough that they don't have any strings
|
|
that need to be translated - I consider this a plus.
|
|
|
|
The infrastructure for a system language exists, but is not really in use.
|
|
(This includes the installer copying language files for the selected language,
|
|
but the only thing with a language selector at the moment is the installer.
|
|
Language selection is performed by editing the "language" file
|
|
at the drive root and rebooting, or switching language during install.)
|
|
|
|
The infrastructure is quite minimal so as not to bloat the system too badly -
|
|
it's up to the applications to decide how to implement multi-language support,
|
|
but the system can load files from lang/<language>/<pkg>.lua to aid in this.
|
|
(Why loading files? To avoid having every single language loaded at once.
|
|
Why loading Lua files? To avoid making this feature bloat the system.)
|
|
|
|
As for the issue of wide characters (Chinese/Japanese/Korean support):
|
|
|
|
Wide characters are supported in all supplied apps that handle text,
|
|
including the text editor -
|
|
the helper API function unicode.safeTextFormat should make these things easier.
|
|
|
|
(safeTextFormat is allowed to rearrange the text however it needs to for
|
|
display - this leaves the possibility of RTL layout open.)
|