commit a7961769f96543de7591472d7efa107f8d377d58
parent 8f8c5dab67b29ab05e1934e207666f5c4fa31a96
Author: Ville-Matias Heikkila <viznut@low.fi>
Date: Tue, 14 Jun 2022 15:16:33 +0300
new pages
Diffstat:
3 files changed, 139 insertions(+), 2 deletions(-)
diff --git a/BBS.mdwn b/BBS.mdwn
@@ -0,0 +1,55 @@
+Bulletin Board System
+=====================
+
+A **Bulletin Board System** (**BBS**) is an online community service based
+on [[character terminal]] connections – traditionally over landline
+telephone modems, but currently most BBSes use Telnet or SSH over the
+Internet instead. There are also packet radio ([[AX.25]]) BBSes used by
+radio hams.
+
+BBSes came to existence in the 1970s but were preceded by [[time-sharing]]
+services of the 1960s. A major difference between a BBS and a time-sharing
+server (such as a public Unix system) is that BBS software is usually
+user-friendlier and specifically designed for messaging and file-sharing.
+Also, BBSes have generally been run on much smaller computers, usually
+microcomputers with a single modem. Multi-user BBSes were not uncommon in
+the "golden years", but most BBSes only allowed only one online user at a
+time. In many places, BBSes declined quite rapidly especially when broadband
+Internet connections became available.
+
+Some notable features of the BBS culture from the permacomputing
+perspective, especially in contrast to the Internet:
+
+* Locality. Since long-distance telephone calls are more expensive than
+ local calls, most modem users have preferred servers that are
+ geographically close to them. This helped create local variation to the
+ BBS scene and prevent excessive centralization.
+* Personality. BBSes generally look and feel like their owners, and visiting
+ a BBS feels more like visiting someone's home than a public service. On
+ the Internet, small messaging forums and [[personal servers|Smallnet]] may
+ sometimes create the same kind of feeling.
+* Limited availability. There used to be much more BBS users than BBS nodes,
+ so it was quite common to get a BUSY signal instead of a connection.
+ Automatic dialling lists that repetitively called several BBS numbers
+ until a connetion was made were common. Also, BBSes could become
+ temporarily or permanently unavailable due to various personal reasons.
+ So, BBS users generally felt joy on succesful connections, something that
+ does not happen on the Internet where everything is expected to be
+ constantly available at all times.
+* Intensity. When online time is limited (and possible even charged per
+ minute), it needs to be used actively instead of "just idling around".
+ Non-multitasking operating systems amplify this. Offline is the default
+ state of mind, and online is an exception.
+* Scarcity and sharing. When connection time is a limited resource, users
+ are generally expected to contribute to the systems by message-based
+ discussions and/or uploads instead of just passively "leeching" files.
+ Most BBSes implemented an upload/download ratio system where files were
+ used as "currency".
+* [[File collection]]. BBSes typically host all kinds of software and other
+ files useful for computer users. Also, before the broadband Internet, it
+ was not feasible to redownload the same files every time they were needed,
+ so it was also important to curate local, personal file collections.
+
+Even though BBSes in general are stand-alone systems, there have been ways
+to network them. [[Fidonet]] is a prominent networking system for creating
+shared messaging forums between several BBSes.
diff --git a/bootstrapping.mdwn b/bootstrapping.mdwn
@@ -1 +1,32 @@
-**Bootstrapping** has quite many meanings in the computer world.
+# Bootstrapping
+
+**Bootstrapping** has many meanings in the computer world. The most common
+meaning is now more commonly referred to as **booting** (i.e. the process of
+starting a computer). Bootstrapping a software or a programming language,
+however, generally means making it available on a computing platform
+starting from a very elementary level.
+
+Bootstrappability is important for permacomputing for ensuring that
+arbitrary software can be run in an indifenite future where computing
+environments can be very different.
+
+Bootstrappability is often a problem with programming languages that have
+been implemented with theirselves (like, a C compiler written in C, or a
+Rust compiler written in Rust). Usually, a language is made available on a
+new processor architecture by cross-compiling its compiler to it, but if
+that option is not available, bootstrapping is needed.
+
+In case of ordinary software, bootstrapping means not only compiling the
+program itself but also compiling/bootstrapping all of its software
+[[dependecies|dependency]] from the lowest level, including the [[operating
+system]]. The amount of computing resources (especially storage space and
+computing time) required for bootstrapping can be used to measure
+**bootstrap complexity**.
+
+Binary executables compiled for simple [[virtual machine]]s can be used to
+help bootstrapping. A good idea might be to have a simple, easily
+retargettable [[C]] compiler available as this kind of executable.
+
+Classical, bare-hardware [[Forth]] environments have often been created in a
+bootstrapping-like way, where a simple memory editor gradually gains more
+vocabulary.
diff --git a/virtual_machine.mdwn b/virtual_machine.mdwn
@@ -1 +1,52 @@
-A **virtual machine** is an implementation of a computing platform on top of another.
+# Virtual machine
+
+A **virtual machine** is an implementation of a computer on top of another.
+An **emulator** is specifically a virtual machine that simulates a different
+type of computer that also exists as real hardware. If the "emulated"
+computer is similar to the one that runs the emulator, the commonly used
+term is **virtualization**. Virtual machines that have no real-hardware
+counterpart (such as the Java Virtual Machine) are usually just called VMs,
+but their machine languages are usually referred to as **bytecode** rather
+than machine code.
+
+Virtual machines can be used to ensure compatibility of a software – both
+across different types of hardware and in constantly changing software
+environments (i.e. to avoid [[software rot]]). Very simple virtual machines
+(ones that may be very slow but can be implemented in a very short time) are
+sometimes suggested as a means for very-long-term software preservation.
+
+Virtual machines designed to run applications usually have the same kind of
+[[dependency]] and obsolescence problems as modern computer platforms in
+general. So, instead of ensuring compatibility, things like the Java Virtual
+Machine are more likely to add just another unreliable layer of
+dependencies. In order to avoid this, the design of the VM should be frozen
+and discourage software dependencies.
+
+A general problem with virtual machines is the virtualization overhead,
+especially if the instruction set differs from that of the host computer. An
+emulated program may require several times the computing resources of an
+equivalent native program. JIT translation can be used to reduce this
+overhead. [[Static binary translation]] could be used to remove (nearly) all
+of the overhead, but is far more difficult to implement automatically.
+
+**Fantasy platforms** are a class of virtual machines designed to be
+superficially similar to classic home computers, including immediate and
+worriless programmability with a simple programming language. A common
+design mistake in otherwise constrained fantasy platforms (such as
+[[TIC-80]]) is **uncapped speed** that allows the host computer to run the
+programs as fast as it can. This encourages programs that "push the limits"
+of the VM while actually taking advantage of the speed of the host computer
+and wasting a lot more energy for doing the same thing.
+
+Virtual machines:
+
+ * [[Uxn]]
+ * [[TIC-80]]
+ * [[WebAssembly]]
+
+Languages that are usually compiled into virtual machine bytecode instead of
+native code:
+
+ * [[Forth]]
+ * [[Java]]
+ * Most scripting languages ([[Lua]], etc.)
