💾 Archived View for bbs.geminispace.org › u › zzo38 › 19574 captured on 2024-12-17 at 15:16:04. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Re: "When it comes to arbitrary, "realtime" composability, the..."
I think gyaradong's and norayr's complaints are valid. However, composability with both command-line and GUI together would be possible in a better way, if the system were designed better; I will describe some of my ideas below.
One issue is that many modern UIs are badly designed, in my opinion (some older programs had some good features, such as: the "Reveal Codes" feature of WordPerfect, block selection in WordStar, the ability to send attachments to pipes in Heirloom-mailx (which I still use as my email program), Xaw scrolling, etc). I use popen in some of my programs, and often using user-specified commands; however, this is uncommon and the sandboxing systems that I have seen do not seem to be designed for this usage.
FOSS programs can be changed, but this requires changing the programs even in cases where it shouldn't need to be changed. If the program is very large then changing and recompiling it can sometimes be difficult (I try to avoid these things when possible in my own programs).
I had many of my own ideas of operating system design, which I had written about elsewhere, but I wrote some of them on here too, now.
It does not use text for everything; it uses a binary format called Common Data Format, and there is some similarity with ASN.1, although the data types are different, and data can also contain inherent links and capabilities. (A system does not need to be based on text for composability; actually I think this "Common Data Format" would do it better than plain text.)
The character set is Extended TRON Code, although arbitrary code pages of 8-bit characters are also possible (and are often useful, for programming and other uses). Control codes are possible to implement a limited rich text in the Common Data Format, too.
It uses capability-based security; all I/O uses capabilities. A program can send a message (which can contain bytes and/or capabilities) through or receive a message from a capability, and a program can create its own capability called a "proxy capability".
The possibility to use proxy capabilities allows many things, including: restricted access, revocable capabilities, network transparency, simulation of error conditions, changing input sources and output targets (e.g. when a program would request a video stream from a camera, it can also be a video file or whatever else you want it to be), logging, etc.
The kernel does not need to know about any of this stuff; all of these things can be implemented in user programs that other user programs do not need to know about.
You could also be able to replace some of the windows in a program with your own, programs that implement protocols with other ones, etc; since the program and UI are controllable by messages.
It would have a command-line interface as well as GUI, and they would be able to work together much better; in existing systems they don't work that well together, but there are ways to improve it. (Common Data Format is one thing, too.)
I have other ideas for the operating system design too, such as: "hypertext file system", "Command, Automation, and Query Language" (the command shell), "space age time keeping", "window indicators", improved i18n, emulation, etc.
Sep 10 · 3 months ago
🐉 gyaradong [OP/mod] · Sep 12 at 10:17:
zzo38: OMG this is exactly along the lines that I've been thinking. The idea is: Programs operate on files, the files use a common data format (I was thinking RDF but it seems the Open Semantic Framework ties CDF and RDF together anyway). The files can be transferred between programs, either a subset of what the program operates on, or the whole "database". This file manipulation and streaming is then the UI paradigm.
EDIT: Also, this kind of gives you a similar model to the PalmPilot: You can "sync" by just transferring files which all parties can understand (common data), and you can share subsets of data through a common interchange.
Perhaps not quite exactly, but it is similar.
My idea involves a custom file format for the Common Data Format, which is not RDF (which has many problems in my opinion). Perhaps it can be: the command code (one bit indicates constructed or primitive), the length, and the data; if it is constructed then the data is zero or more Common Data Format items but if primitive then it is plain data. There will be many commands for common data but also extension commands are possible too.
About the file system design: There are no file names and no directory structures. It is a transactional file system. Files have multiple forks/streams (labeled by 32-bit numbers), and a file stream can contain both byte sequences and links to other files.
One of the forks of a file might be used for the data type of the initial message. So, instead of just text for passing command-line arguments etc, it can specify the expected data type of the message, including any capabilities it should contain (which can themself have types), and tagged unions are also possible as well as structures and other types. This is a convention used by the command shell and other programs and is not something that the kernel knows about, and nothing stops you from sending a message that does not conform to the specified types if you really want to do (although it won't do so by default; if you are using the command shell then you must explicitly tell it to send a raw message).
Command, Automation, and Query Language is used in the command shell and it can be used for composability, hopefully better than UNIX does, and with command-line and GUI composing together. However, many functions of the GUI will not need the command shell to allow them to be composed together, but the command shell is still very useful for advanced uses and can do much more than the GUI does (and you can use both together).
The composability is possible by Common Data Format, by proxy capabilities, and by message passing, rather than just by text like UNIX is doing (although SCM_RIGHTS is something UNIX has which is similar than the capability passing that I have). Neither text nor GUI is more fundamental; capabilities and messages are more fundamental, in my system.
When it comes to arbitrary, "realtime" composability, the Unix model of files, streams, and processes has yet to be topped. GUIs are vey rarely composable, and also hard to script. It makes me think maybe composability has to be one dimensional, and textual. This idea that a keyboard is fundamental to a computer but a different pointing device doesn't feels slightly off. I wonder if there is an elegant multi dimensional method of composability which simplifies down to simple compute models and...
💬 gyaradong [mod] · 16 comments · 1 like · 2023-11-14 · 1 year ago