commit abe6c96d76fe941dcb5565404b6de0c57da76676
parent 985fd9c948c59494f1f1193430d699179476050c
Author: Ville-Matias Heikkila <viznut@low.fi>
Date: Tue, 14 Jun 2022 12:07:40 +0300
add some pages
Diffstat:
4 files changed, 111 insertions(+), 0 deletions(-)
diff --git a/Gemini.mdwn b/Gemini.mdwn
@@ -0,0 +1,23 @@
+**Gemini** is an application-layer [[WWW]] protocol created by Solderpunk in
+2019. Gemini and its document format (Gemtext) are somewhat similar to
+[[Gopher]] but add some features from modern WWW, such as mandatory
+encryption, hyperlinks and URLs. Due to the simplicity of Gemini, there is
+already a large amount of fully compliant client software.
+
+It is of course possible to use [[HTTP]](S)/[[HTML]] in a simple and
+restricted way along with limited [[web browser]]s to get similar technical
+characteristics. However, a separate protocol makes it possible to have a
+separate [[Smallnet]] space, **Geminispace**, where users are guaranteed to
+only encounter things that are compatible with their simple Gemini browsers.
+
+Relationship to permacomputing:
+
+* Low bandwidth, low complexity, low system requirements. These are partially dictated by the design of the format (no support for inline media, etc.)
+* Coexistence with Gopher and HTTP/HTML with no intentions to replace either.
+* The lack of inline media makes it easier to have [[local copies|file collection]] of Gemtext documents.
+* Solderpunk has written about permacomputing, and at least one of the Gemini clients (Ariane) explicitly refers to permacomputing.
+* However, Gemini does not address what can be thought as one of the basic problems of [[WWW]]. Documents are primarily addressed by referring to their servers, so impermanence and broken links can be expected especially as the typical Gemini server is small and private.
+
+See also:
+
+* [[Project Gemini FAQ (HTTPS/HTML)]](https://gemini.circumlunar.space/docs/faq.gmi)
diff --git a/Uxn.mdwn b/Uxn.mdwn
@@ -0,0 +1,23 @@
+# Uxn
+
+**Uxn** is a simple [[virtual machine]] platform geared towards graphical
+applications, with features reminiscent of classic home computers and game
+consoles.
+
+Unlike most "fantasy platforms" such as [[TIC-80]], Uxn is simple to
+implement, and implementations ("emulators") exist even for "obscure"
+devices such as the Gameboy Advance. UxnVM is about 100 lines of [[C].
+Another difference is that there is (currently) no Uxn-based programming
+environment, so development depends on a Unix-style command-line compiler
+(Uxnasm).
+
+Relationship to permacomputing:
+
+* Simplicity of implementation may make Uxn usable as a [[bedrock platform]] for the kind of programs that are small enough to run in it. Uxn applications are released as "roms" that have no [[dependency|dependencies]] other than the VM itself.
+* The design characteristics call for small applications that use little computing power.
+* The author of Uxn, Devine Lu Linvega, has written about permacomputing and explicitly refers to it in relation to Uxn.
+* The general issues with [[virtual machine]]s apply: running a virtualized program takes much more processing power than an equivalent native program would. It is therefore advisable to only use VMs for computationally simple applications.
+
+See also:
+
+* [[Uxn at 100r.co]](https://100r.co/site/uxn.html)
diff --git a/character_terminal.mdwn b/character_terminal.mdwn
@@ -0,0 +1,55 @@
+# Character terminal
+
+**Character terminals** have been a prominent way of using computers since
+the early years. At first, paper-based [[teleprinter]]s were the most common
+computer terminals, but CRT-based video terminals started to replace them in
+the 1970s. In the 2000s, the character terminal is most often a **terminal
+emulator** program running on a graphics-capable computer.
+
+Character-based terminals and interfaces from a permacomputing point of
+view:
+
+Advantages:
+
+* A VT100-compatible terminal emulator is quite simple to implement and its basic hardware requirements are quite low (a couple of kilobytes of RAM are enough for representing the screen contents).
+ * Even simpler terminals can be usable in the Unix world provided that a Terminfo/Termcap entry is available. For "VT100-only" software, Screen or Tmux can be used as a compatibility layer.
+* The hardware requirements for a server are even lower than for a client. It requires very little from a computing device to send and receive characters over a serial connection; even the smallest microcontrollers can do this.
+* The simplicity (no long packets etc.) makes all the possible failures relatively easy to notice and diagnose. Even a bad physical connection will show up as random noise characters unless there's an error-correcting layer.
+* Nearly any device with a keyboard and a display can be used as a terminal emulator as long as it has some kind of a serial or network connection. VT100-compatible terminal emulators are also available on just about any classic or modern personal computer platform.
+* The basic bandwidth requirements are very low (you mostly send and receive individual characters as individual bytes).
+* The limited nature of the character-based screen sets a practical upper limit to the fanciness of the interface, and this helps keep the bandwidth and system requirements low. The simplicity and manageability of text terminals make many people prefer terminal-based software even when working on powerful graphical workstations.
+* Simple interactive programs are more straightforward to program for character terminal I/O than e.g. [[web browser]]s.
+
+Problems:
+
+* "Dumb" remote terminal connections set quite high requirements for the responsivity of the network and the remote computer. The user feels uncomfortable if there's even a slight delay between the keypress and the visible response. Even WWW is far more tolerant to network lag.
+ * Local echo used to be a common terminal feature that could be used to reduce this discomfort. Seeing the typed character immediately also made it easier to spot and correct mistakes. Local echo is useful for simple and rudimentary command line interfaces, but more complex features (such as tab completion) reduce its usability.
+ * Mosh is a protocol that extends SSH with some more tolerance for unreliable and laggy network connections by trying to predict how the typed text will look like on the terminal before the server sends its actual response.
+ * Block-oriented terminals such as the IBM 2260 and 3270 addressed these problems already in the 1960s. In a sense, web browsers can be thought of as successors of block-oriented terminals.
+* The potential of the hardware used as a text terminal is nearly always underused. Even "dumb" terminals are usually not so dumb on the inside. The VT100, for example, is basically a 8080-based microcomputer with far more potential than just running the ROM-based terminal program.
+ * Unlike many later terminals and terminal emulators, the VT100 does not have features such as client-side copying, filling or highlighting, or even arbitrary scroll zones (only full-width zones are supported). Since the VT100 became the "gold standard", even today's terminal-oriented software such as Tmux are forced to implement their fancy windowing features by constant character-by-character refreshes.
+ * In general, a lot of relatively basic stuff requires far more bytes than it ideally should. When using a text editor over SSH over TCP/IP, every single keypress translates into quite many protocol bytes. Even a website with a text edit box may be much easier for the network.
+* Textmode rendering comes from a world where pixels are cheap but memory is expensive. It is therefore not very good for small screens that could be used more efficiently with direct pixel addressing and non-monospaced fonts.
+* Many terminal-based programs make the assumption that the screen is at least 80 characters wide. This makes them impractical on small displays.
+* Since keypresses are transmitted as individual characters, it is generally not possible to create UIs that depend on the arbitrary pressing and depressing of keys (e.g. cursors that move constantly when an arrow key is down and stop moving exactly when the key is released).
+* Likewise, it is not possible to support arbitrary combinations of keys (ctrl+A and ctrl+shift+A both transmit the same byte). The limited key combination support has made it difficult to implement some common CUI/TUI standards (such as using shift+arrows to mark blocks of text) on VT100-compatible terminals.
+* Nearly all ways to display even rudimentary graphics have been somehow crippled in mainstream text terminals:
+ * Unlike many contemporaries (such as Teletext, Videotex and many early personal computers), the VT100 has no pseudopixel characters, only box-drawing and curve-drawing ones. Some pseudopixel characters have been adopted into Unicode, but their support in fonts has been unreliable.
+ * VT220 and later VTs support user-definable characters but this feature has been rarely implemented in emulators (no surprise, since the character matrix size varies by terminal model and display mode).
+ * Some special-purpose VT terminals feature bitmap and vector graphics ("Sixel" and "ReGIS"), and some terminal emulators (xterm) actually support them. However, Sixel graphics was defined so that each individual color needs to be separately transmitted (no proper bitplanes), so it makes sense only for very low-color images.
+
+Some technical vocabulary:
+* ANSI X3.64 is a ~1976 control sequence standard for character-based video terminals. It was criticized for being too complicated for "dumb" hardware and thus requiring a microprocessor. One of the complications was the use of ASCII decimal numbers as command parameters (earlier terminals had used single bytes instead).
+* VT100 and VT102 are physical, microprocessor-based text terminals manufactured by Digital Equipment Corporation in around 1978-1983. They became the de-facto reference implementation of the ANSI standard.
+* ANSI.SYS on the [[IBM PC]] is another influential implementation of the standard. Notably, it supports the cell-specific foreground and background colors of the CGA-compatible display controllers. "Ansi art" therefore usually refers to art made for the IBM PC textmode, including the non-standard pseudographic characters featured in the IBM PC character set.
+* ECMA 48 (the last version is from 1986) is a later standard that extends on the X3.64. It defines ANSI.SYS-style colors but also some potentially useful features that are very rarely supported in today's terminal emulators (such as a support for multiple pages and editable areas).
+* Text mode is a hardware feature of a display controller, allowing the representation of the screen as character indexes rather than individual pixels. The pixel matrices of each character are fetched from a separate character memory (which can be ROM or RAM or both). Physical text terminals, most 8-bit microcomputers and IBM PC compatibles have a hardware textmode. In the game console world, equivalent display modes are referred to as "tile-based".
+* CLI (command-line interface) is based on typed commands. CLIs have been around since the teleprinter days.
+* CUI and TUI (character-based UI, text-based UI) are a more graphical type of character-based interface. They may have things like status bars, cursor-navigable menus and even windowing or mouse support. A lot of work and standardization on CUI/TUI took place in the [[IBM PC]] world. Unfortunately, many of the common CUI/TUI approaches are somewhat prohibitive on low-bandwidth character terminals.
+* Telnet is a protocol for non-encrypted terminal connections over a TCP/IP network. SSH is a protocol for encrypted ones (and therefore recommended in nearly all circumstances). The easiness to sniff the network for Telnet passwords was the major reason why SSH was adopted.
+* Pseudographics refers to characters that have been intended for drawing crude graphical images rather than representing text. Some of these are intended for drawing of box frames (e.g. U+2500..U+257F in Unicode), while others are for simulating low-resolution pixel framebuffers (e.g. U+2580..U+259F). [[UNSCII]] is a font that attempts to implement Unicode and legacy pseudographics as completely as possible.
+
+See also:
+* [[Character sets]] (-> ASCII, Unicode etc)
+* [[ANSI X3.64]]
+* [[BBS]]
diff --git a/projects.mdwn b/projects.mdwn
@@ -0,0 +1,10 @@
+# Projects
+
+This is a list of projects that share goals and/or values with
+permacomputing. Also those projects that explicitly refer to permacomputing
+can be included here.
+
+* [[Uxn]]
+* [[Gemini]]
+* [[Collapse OS]]
+* [[Civboot]]
