💾 Archived View for bbs.geminispace.org › s › permacomputing › 11717 captured on 2024-09-29 at 03:32:04. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2024-08-31)
-=-=-=-=-=-=-
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 binary, so one might create a BIOS or a ROM in it.
2023-11-14 · 11 months ago · 👍 norayr
👻 mediocregopher [...] · 2023-11-14 at 09:50:
the Unix model of files, streams, and processes has yet to be topped
Excel begs to differ :) when the entirety of the world's financial system is supported by a piece of software it's hard to overlook that
@mediocregopher but stocks run mainly on linux, not excel
🐉 gyaradong [OP/mod] · 2023-11-14 at 20:35:
The differentiation I'm trying to make is between command line and GUI in the context of permacomputing. GUI software needs to constantly be tweaked and updated and take on the features of other software. Efficiency matters and it is tackled through complexity. GUIs don't have a model for composability, but a system based on text? You could probably create 5 different composable text oriented systems without any issue. So, is text more fundamental than GUI? Is symbolic manipulation the only way to build on top of logic gates?
🐵 cquenelle · 2023-11-15 at 04:37:
You can also think of this in terms of programming languages. There have been attempts at a visual programming language, but I don't think any of them really took off. Although I remember being impressed with the Self programming environment a while back. I think there's something fundamental about language wired into our brains by evolution.
🐉 gyaradong [OP/mod] · 2023-11-15 at 07:38:
assuming this is true, a keyboard really is the fundamental input device for computers. all the other form factors aren't really going to be scalable.
🐉 gyaradong [OP/mod] · 2023-11-15 at 10:53:
could one get to a notebook with free form writing and drawing but "self hosted" software from the firmware through bios and to OS and apps?
🐙 norayr · 2023-11-17 at 14:16:
in traditional oberon system there are no processes that run in parallel or pseudo-parallel. the task switching occurs when one function finishes its work and the other function takes over.
they consider that the commandline concept is outdated, since it was about printing on the paper and the text printed on the paper would become immutable. that concept came from the time when we didn't have yet crt monitors.
still, traditional oberon system is text based. it is modular, and the module named Texts is one of the base modules of the system.
everything is text in oberon system.
the manuals are text files with extension .Tool.
they contain ready to use commands: module.procedure
🐙 norayr · 2023-11-17 at 14:21:
let's say the compiler command is there in two ways:
Compiler.Compile ^
Compiler.Compile *
you can write Compiler.Compile somefile.Mod everywhere, in any place you can find in the Oberon tiling ui.
however if you have the manual (the abovementioned .Tool file) opened in one of the viewers (windows are called viewers there) and then you select the file name to compile in any other viewer, then click with the mouse middle click on
Compiler.Compile ^
then instead of ^ the Compiler.Compile function will pickup the file which name you selected.
🐙 norayr · 2023-11-17 at 14:25:
or maybe you wrote some test code in an editor in one of the viewers but didn't save it to the file system.
you just navigate the mouse over that window and press F1 button. then the viewer will be marked with the asteriks sign.
after that click on
Compiler.Compile *
and the code in the marked viewer will be compiled.
some of these concepts are borrowed in ACME text editor of plan9 by rob pike. however it feels much more consistent in the oberon system text oriented system.
🐙 norayr · 2023-11-17 at 14:30:
i think our 'monolite' gui programs are what the capitalism and marketing produced to sell us software.
even in unix (and unix is still a government funded research project, it is not a startup) we have window managers, then we have terminals, we have text editors, compilers, debuggers etc.
each of the programs in this chain can be replaced. twm can be replaced with dwm or fvwm or windowmaker.
emacs can be replaced with vim or nano or whatever.
xterm can be replaced with rxvt or mrxvt or st or whatever.
everything is replacable.
on the contrary in the capitalistic software we have IDE's that replicate the functionality of everything below.
IDE's have own window managers - but we already
🐙 norayr · 2023-11-17 at 14:31:
but we already have window managers.
plus we could use other window manager instead of this one, but we cannot when we are in IDE. IDE has its own window manager and you should deal with that.
IDE has its own editor.
oh, you don't like it? MS VSCode will support vim mode, but it is still MS VSCode. MS VScode will make everything possible for you to use it and not understand the taste of underlying interchangable interoperable system.
🐙 norayr · 2023-11-17 at 14:35:
i think it was possible to find another path.
swiss found, as i presented in previous comments.
and i can imagine a modular ui program. you have a chat program pidgin? what it consists of? a window to show contacts. you don't like it? why cannot you replace it with other window that can show contacts?
you have window divided in to two field? on the topper one you see what was written to you and in the bottom you write your text?
why cannot you replace it with other window like that?
and those both can communicate with each other and with the service that implements the protocol.
oh you have a video call viewer? why cannot you replace it with other one?
🐙 norayr · 2023-11-17 at 14:38:
or why pidgin doesn't communicate with the program like mplayer with pipes to pipe the video stream to mplayer so that you could watch the person you are talking with?
why pidgin has to implement it again?
well - we have shared libraries - you would say.
and then i'll come back to the oberon ideas. they don't have shared libraries. the module is compiled to the object file.
each object file can have multiple entry points, there is no main(). as in case with Compiler.Compile there can be Draw.Curve and Draw.Line.
there are no linked 'programs' that contain one entry point.
everything is a library or a program - why should be there a difference?
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.
🐉 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.