drummyfish/less_retarded_wiki
5
1
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Update

Browse source
This commit is contained in:
Miloslav Ciz 2023-07-13 12:19:07 +02:00
parent e89960bcfb
commit 5cb3296fc9
11 changed files with 63 additions and 22 deletions
Download patch file Download diff file Expand all files Collapse all files

4
operating_system.md
View file

@ -51,9 +51,9 @@ Let's keep in mind that true LRS computers would be different from the current c
The system might likely lack features one would nowadays call essential for an OS, such as multiple user support (no need if everyone has his own computer and [security](security.md) is not an issue), [virtual memory](virtual_memory.md), complex [GUI](gui.md) etc. There might even be no [multitasking](multitasking.md); a possibility to make a multitasking OS exists, but let's keep in mind that even such things as programs interacting via [pipes](pipe.md) may be somewhat implemented without it (using temporary buffer files into which one program's output is stored before running the next program).
The universal OS would assume well behaved programs, as programs would likely be given full control over the computer when run -- this would greatly simplify the system and also computing in general. Doing so would be possible thanks to non-existence of malicious programs (as in good society there would be no need for them) and eliminations of [update culture](update_culture.md). Users would only install a few programs they choose carefully -- programs that have been greatly tested and don't need to be updated.
The universal OS would assume well behaved programs, as programs would likely be given full control over the computer when run -- this would greatly simplify the system and also computing in general. Doing so would be possible thanks to non-existence of malicious programs (as in good society there would be no need for them) and elimination of [update culture](update_culture.md). Users would only install a few programs they choose carefully -- programs that have been greatly tested and don't need to be updated.
**On user interface**: the basic interaction mode would of course be the text interface. Programs would have the option to switch to a graphical mode in which they would be able to draw to screen. There would be no such [bloat](bloat.md) as [window managers](window_manager.md) or [desktop environments](desktop_environment.md) -- these are capitalist inventions that aren't really needed as users practically always interacts with just one program at a time. Even in a multitasking system only one program would be drawing to the screen at a time, with user having the option to "alt-tab" between them. This would also simplify program greatly as they wouldn't have to handle bullshit such as dynamically resizing and rearranging their window content. If someone REALLY wanted to have two programs at the screen at the same time, something akin a "screen splitter" might be made to create two virtual screens on one physical screen.
**On user interface**: the basic interaction mode would of course be the text interface. Programs would have the option to switch to a graphical mode in which they would be able to draw to screen. There would be no such [bloat](bloat.md) as [window managers](window_manager.md) or [desktop environments](desktop_environment.md) -- these are capitalist inventions that aren't really needed as users practically always interacts with just one program at a time. Even in a multitasking system only one program would be drawing to the screen at a time, with user having the option to "alt-tab" between them. This would also simplify programs greatly as they wouldn't have to handle bullshit such as dynamically resizing and rearranging their window content. If someone REALLY wanted to have two programs at the screen at the same time, something akin a "screen splitter" might be made to create two virtual screens on one physical screen.
**A bit more technical details**: the universal OS could simply be a program that gets executed after computer restart. This program would offer a [shell](shell.md) (textual, graphical, ...) that would allow inspecting the computer, configuring it, and mainly running other programs. Once the user chose to run some program, the OS would load the program to memory and jump to executing it. To get back to the OS the program could hand back control to the OS, or the computer could simply be restarted. If the program crashes, the computer simply restarts back to OS. The OS could also contain functions, kind of an [API](api.md), as part of its code that "userland" programs might call, e.g. for drawing to the screen, reading input etc. (just as e.g. a BIOS usually offers similar functions). Note that shell [scripting](script.md) that executes other programs could still be possible, e.g. by remembering the state of script execution in a file on disc. Same thing could be used for communicating between the OS and programs (e.g. clipboard), i.e. there would still be no need for multitasking.